Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 2.7 Retirement Countdown

pythonclock.org

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Python 2.7 Retirement Countdown

#61

Post by nerdponx »

iconjack wrote: post #56
nerdponx wrote: post #51

Earlier quoted context omitted.

As someone who learn Python 3 first, I'm amazed that people really think Python 2 is better. After so many years, why the resistance?

I hope you didn't read my comment as saying Python 2 is better. Personally I don't have an opinion on that. But as you can see from this thread and many, many others, a lot of people are disappointed with Python 3's choices. You're right, it's been a lot of years, but if adoption has been as slow as some are suggesting, maybe we could cut our losses and put our beloved Python on a different path, as a community.

Maybe, but at the same time I haven't yet seen a criticism of py3 that wasn't just a litany of complaints about backward compatibility. Even in this thread, I don't see a whole lot of substance behind the discontent.

Re: Python 2.7 Retirement Countdown

#62

Post by dalke »

CJefferson wrote: post #4

No, I'm getting sick of my code being broken. My C code from 15 years ago works fine, but code in other languages can end up breaking within a year. I've moved much of my development back to C++ just so I can have reasonable confidence my code will work when I come back to it in a couple of years. I don't care if Python 2.7 never gains another feature, as long as my code will still work in Windows 13 and Mac OS X 10.…

How is a language supposed to make backwards incompatible changes, when it's eventually found that the original style contains substantial flaws?

Would you want the world to still be using K&R C? Because I remember the transition from that to ANSI C, and the special macros to make function prototypes work across both languages. The Python transition is little different.

Re: Python 2.7 Retirement Countdown

#63

Post by Bromskloss »

bionsuba wrote: post #38
StavrosK wrote: post #20

Earlier quoted context omitted.

This again indeed, because Python 2.7 is going away. Python 3 is the future, and we've been resting on our "eh, python 2.7 is convenient enough" mindset for too long. We should just bite the bullet and move to 3, which isn't even that bad of a migration. Also, "supporting legacy code for money" is already everyone's job, unless you're implying that there are as many Python programmers as there are COBOL ones.

That's incredibly naïve. Python 2 will be around and have new software written with it for at least a decade to come. Keep saying "Python 3 is the future", that will surely make companies invest in switching. Meanwhile ford still uses 40 year old IBM mainframes with COBOL, and will continue to do so until they are physically unable.

> ford still uses 40 year old IBM mainframes with COBOL,

What are they using it for?

Re: Python 2.7 Retirement Countdown

#64

Post by shadowmint »

asdfologist wrote: post #54
shadowmint wrote: post #53

Earlier quoted context omitted.

https://hg.python.org/cpython/graph I guess you can decide for yourself if the 'official support' of python is a massive drain on resources that could be used else where. (The red line with a few commits now and then is the 2.7 branch)

That's a lot of commits. You just disproved your own argument.

Oh please. It's a handful of backports and bugfixes. Actually read the commits.

Re: Python 2.7 Retirement Countdown

#65

Post by jgalt212 »

scrollaway wrote: post #42
jgalt212 wrote: post #13

Most everything good from Python 3 has been back-ported to 2.7. Except for built in parameterized tests in unittest. Python 3 has the subTest context manager (which looks great) https://docs.python.org/3/library/unittest.html#distinguishi... In 2.7 you must use pytest, ddt, nose-paramemterized or dynamically add test methods to a TestCase class at runtime.

Most everything good? Like high quality unicode support and async def?

Some[1] have argued that unicode is better in 2.7 than 3.X. Async looks very useful, though, so I'll add that to the list including the subTest context manager.

http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/

Re: Python 2.7 Retirement Countdown

#66

Post by wink »

underyx wrote: post #60
unlinker wrote: post #21

3 Years 10 Months 13 Days 20 Hours 54 Minutes 31 Seconds until a community fork occurs.

Actually, it seems to me that everyone who is active in the community is already on Python 3 and is heavily in favor of upgrading. The people who are still using Python 2 are the 'lazy' ones, who don't really care about the community at all; the ones who keep making comments like 'I just use whatever the `python` command starts.' I'm pretty sure these people couldn't maintain Python 2 by themselves.

I have a reasonably large project that was started in late 2013 (so only 2.5 years ago) when 2.7 was already long "to be deprecated" but some of the key libraries used were not yet python 3 compatible.

I haven't actually checked, it could probably be ported now - but why would you do that now - everything can change in the next 3 years.

Re: Python 2.7 Retirement Countdown

#67

Post by DasIch »

sandipc wrote: post #10
DasIch wrote: post #2

There are enough large organizations using Python that no doubt at least one will find it to be cheaper and more convenient to continue maintaining a 2.7 interpreter. Dropbox is working on one just to increase performance. PyPy also has due to how it works fundamentally a huge interest in maintaining Python 2.7 support for the forseeable future. You've to be quite naive to believe that Python 2.7 will retire in 2020.…

Guido van Rossum (Python BDFL) himself works for Dropbox, so I'm not sure I believe that... See also: https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.p...

He does but how much influence does he really have there? I doubt it's enough to push them to 3.x just because. Pyston 0.5, the interpreter developed at Dropbox, was also just released a few days ago.

They're going to do what's pragmatic and cost efficient. Making everyone stop improving the product and porting the code base, is probably more expensive than just having one team maintaining and improving the interpreter.

Re: Python 2.7 Retirement Countdown

#68

Post by Avernar »

scrollaway wrote: post #42
jgalt212 wrote: post #13

Most everything good from Python 3 has been back-ported to 2.7. Except for built in parameterized tests in unittest. Python 3 has the subTest context manager (which looks great) https://docs.python.org/3/library/unittest.html#distinguishi... In 2.7 you must use pytest, ddt, nose-paramemterized or dynamically add test methods to a TestCase class at runtime.

Most everything good? Like high quality unicode support and async def?

High quality unicode? Where every string with even a single emoji takes 4 times the memory. They should have used UTF-8 for their internal representation.

Putting that aside, my issue with 3.X is that I have to use the unicode type even when I'm manipulating byte strings.

Re: Python 2.7 Retirement Countdown

#69

Post by fallenshell »

shawkinaw wrote: post #35
fallenshell wrote: post #33

Earlier quoted context omitted.

It's called "moving forward". The technology sector moves fast, and you need to keep up. Nothing is ever going to get better with that sedentary mindset.

Well, if you ask me, backward compatibility should only be broken with extreme reluctance, because it's a huge waste of time to be rewriting things that already work. See also Angular 2.

This was a major release. 2 to 3.

Re: Python 2.7 Retirement Countdown

#70

Post by forgottenpass »

altano wrote: post #41

I just recently started learning Python for the first time, and at some point I switched from playing with 2.7 to 3.x, and my uninformed opinion is that I'm shocked at how many seemingly completely unnecessary breaking changes there are. Did the parameter names to open()d really need to change? Why did I have to change from io.open() to open() for a stream? Did str.lowercase really need to become string.ascii_lowerca…

Python 3.0 was basically a line in the sand to throw in all these "unnecessary" breaking changes. At the end of the day, no changes are actually necessary.

But to keep Python improving without weighing itself down, some changes couldn't just be slipped into the 2.x series. Because they're fundamental enough changes to even effect toy programs.

So, yes, I'd say that the default string type did need to change from bytes to unicode. And not only do I not miss str.lowercase, that kind of vestigial feature is exactly the type of thing that should be purged with the unicode transition.

Post reply on HN