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

Sunsetting Python 2

python.org

Post reply on HN
Print view View original

631–640 of 733 posts

Re: Sunsetting Python 2

#631

Post by loeg »

zurtex wrote: post #358
kortilla wrote: post #320

Earlier quoted context omitted.

Strings in python3 were terrible for memory well into mid-3. Raymond Hettinger is a core dev and he recently stated on Twitter that he didn’t feel py3 was a clear upgrade win until this most current release.

Raymond has been consistent in saying Python 3.6.1 was the release where Python 3 became better than Python 2. That was March 21, 2017, and we're now in Python 3.7.4. I appreciate the general point that that's far more recent than Python 3s initial release but it's also a large exaggeration to say "until this most current release". Also to understand why it took so long is because Python 2 kept improving after Python…

2017 is a lot more recent than 2008 (Py 3.0).

Re: Sunsetting Python 2

#632

Post by loeg »

vegwarecompody wrote: post #419
skywhopper wrote: post #401

Earlier quoted context omitted.

As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users. Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that…

>Instead, I spent my time moving to languages that had more respect for their invested users. I’m not sure what more they could have done. Python 2 was released almost two decades ago, with an original planned sunsetting that got pushed back to 2020. That’s plenty of time and respect for their users. >All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4. You’r…

> I’m not sure what more they could have done.

Not broken 2? None of the breaking changes in 3 were necessary.

Re: Sunsetting Python 2

#633

Post by afiori »

mypalmike wrote: post #579
brians wrote: post #287

Earlier quoted context omitted.

I found some Unicode bugs in porting—and I get continued free security updates. Seems fair to me, and certainly not “no benefit”. I can keep on 2.7 as long as I like; nobody’s forcing me to port. Compare the situation with Java!

I like Python. But it loses in the upgrade comparison to Java. Existing Java code almost always just keeps working with new compilers and JVMs. And new JVMs tend to increase performance of your code for relatively little upgrade effort.

In my uninformed opinion not including a python 2 interpreter in python 3 was the first mistake

Re: Sunsetting Python 2

#634

Post by afiori »

ttraub wrote: post #203
pelario wrote: post #174

Earlier quoted context omitted.

I cannot agree enough. As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.

Me three! It happens all too often that an example Python script fails in one, then succeeds in the other. I'm also a casual Python user, trying to ramp up because of its obvious popularity and utility. I wish that the basic syntactical changes could have been designed to be more backward-compatible. But, eventually I suppose, python2 will just be a footnote in history.

I'm afraid it will forever remembered as a cautionary tale of a bad transition.

Re: Sunsetting Python 2

#635

Post by loeg »

ueiuestu wrote: post #260
jedberg wrote: post #62

In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet. In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now. For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backi…

This makes me wonder, are there any software frameworks and languages that are specifically built for multi decade use? Where they only release security updates and no breaking changes?

C18 is basically backwards compatible with C89. That's 30 years. The only function removed from stdlib is gets(), which was deprecated in C99.

Re: Sunsetting Python 2

#636

Post by sametmax »

gridlockd wrote: post #578
sametmax wrote: post #544

Earlier quoted context omitted.

The science stack is also the one that starting migrating the earliest. Hell, numpy started supporting Python 3 eight years ago, while five years ago people were still complaining so much they got the EOL delayed. Not saying there are not some specific things that were late or never happened, but again, they are about a minority of projects. The thing is this minority is making all the noise. Given the reach and popu…

> The science stack is also the one that starting migrating the earliest. ...but the last to actually finish migrating. In fact, it's still ongoing. > Given the reach and popularity of Python, of course you will always find plenty of testimonies saying they suffered Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase. Everyone had to use an inferio…

> Everyone suffered. Everyone had to deal with Python2 versus Python3 bullshit. It's not just about migrating some codebase.

Updating software version is part of the job. Like creating tests, writing documentation, training newbies and dealing with customers. It's not hard just because we don't like to do it. Porting to Python 3 was not hard for most people. They just really, really didn't want to do it.

I get it. I didn't want to add that on my plate too. Like I didn't want to migrate from my Centos 7, I didn't want to move from mysql to postgres and I didn't want to learn the entire setup of Webpack. 3 times. But "suffering" is a big word that has no place for the vast majority of projects.

Re: Sunsetting Python 2

#637

Post by ptx »

cortesoft wrote: post #499
djsumdog wrote: post #404

Earlier quoted context omitted.

You have a dependency rot problem. Are you missing unit tests? Because having a ton of unit tests can reduce dependency rot, breakage and overall make engineering upgrades just a lot easier to deal with. They don't catch everything of course, but they can catch a lot. If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. It's not just about Py2/3.…

> If you haven't put in the priority to update your Py2 to Py3 apps by now, I really think your shop has the wrong priorities. I am not sure how you could possibly know this. You have no idea what else they were working on instead.

Because no matter what you're working on, you won't get very far without eating, sleeping and at least once a decade putting in some maintenance work.

Re: Sunsetting Python 2

#638

Post by price »

flukus wrote: post #594
sametmax wrote: post #508

Earlier quoted context omitted.

By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones.…

> Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy. In my very brief experience with python over the last few weeks this is very common. Half of our dependencies were abandoned before python 3 existed, when mercurial shuts off the hg we'll even lose the source to some of them. Python 3 get's the blame but the real problem is that the company has ignored maintenance fo…

> when mercurial shuts off the hg we'll even lose the source to some of them.

Are you perhaps thinking of when Atlassian removes the Mercurial repositories hosted on Bitbucket?

Mercurial isn't going anywhere or shutting down anything; it's open-source software with some very large users and committed developers.

(The majority of engineers at Facebook all work in one enormous Mercurial repo. Facebook naturally employs a few people to work full-time on Mercurial, and I don't think they're the only ones.)

Atlassian's decision about Bitbucket is regrettable. Especially regrettable is to actually delete repos for so many open-source projects that may not have active maintainers (rather than keep them online but read-only.) To my mind it marks a stain on their reputation that should make anyone think twice about relying on Atlassian for years to come.

But you should be able to avoid losing the source to any of your own dependencies. Between now and May 2020, go through all your dependencies and make sure you make your own clone of all the source repos.

Re: Sunsetting Python 2

#639

Post by afiori »

carapace wrote: post #612
kstrauser wrote: post #559

Earlier quoted context omitted.

One very high cost to staying on 2 will be that the pool of 3rd party modules you can draw from will continue to shrink as projects drop support for it. Sure, you can stay on Requests v.whatever, but eventually the SSL certs that it includes will expire, and then you'll have to maintain your own patched Requests with the new certs you want to use. Or eventually someone will find security problems with Django 1.11 LTS…

I get what you're saying and I think you're pretty much describing what it will be like. But honestly, I'm kind of looking forward to it. To me it's like maintaining a favorite model train set or something. A labor of love. (Going forward I'm more likely to use Julia, Haskell or Prolog than Python 3 for new code.)

I am interested in your opinion on an idea.

What do you think it would have happened if python 3 included a python 2 interpreter (as a command line flag or even a library) so that everyone could switch to python 3.

I understand they where almost incompatible as runtimes so it would have doubled size but it would make easier to propagate the diffusion of python 3.

Do you think a project such as Bladders would have been still possible had this happened?

Re: Sunsetting Python 2

#640

Post by price »

loeg wrote: post #630
sametmax wrote: post #505

Earlier quoted context omitted.

Ordered dicts and f-strings are also very sweet!

https://docs.python.org/2/library/collections.html#collectio...

I expect sametmax was referring to the new feature in Python 3.6 that plain old `dict` now preserves the insertion order of its elements. See docs here: https://docs.python.org/3/library/stdtypes.html#dict.values

(Or in language-lawyer terms: CPython 3.6 introduced this behavior and documented it as an implementation detail, and for Python 3.7+ it's guaranteed a feature of the language proper.)

Post reply on HN