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

311–320 of 733 posts

Re: Sunsetting Python 2

#311

Post by Kaiyou »

mffnbs wrote: post #270
ofibrvev wrote: post #267

Earlier quoted context omitted.

> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg,…

Your argument ignores that 2.7 was held onto for a decade. Legacy applications did not hold back adoption.

Which still seems like a short period of time, considering timelines in engineering are to support a version for 60 years.

Re: Sunsetting Python 2

#312

Post by radlad »

lvh wrote: post #268
ken wrote: post #240

Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Dependenc…

One of the easiest compared to what? Certainly not a Python point release. A couple of points: 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. 2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining. (I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came…

> Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.

I would expect any stable release of software to be "good and ready." Can you explain what was wrong with Python 3.0 and 3.1?

> core dev did not listen to any of the problems people pointed out for _years_

What problems were those?

Re: Sunsetting Python 2

#313

Post by WilliamEdward »

ofibrvev wrote: post #267
ken wrote: post #240

Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Dependenc…

> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. Good for you. Some of us had code bases of considerable size and complexity though. The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg,…

You've managed to say their analogy is bad in two paragraphs without even explaining why it's a bad analogy. You even admit you don't really understand what they were trying to say. Poor explanation, or poor understanding?

Re: Sunsetting Python 2

#314

Post by em500 »

bigiain wrote: post #234
PeterisP wrote: post #107

Earlier quoted context omitted.

As we see from the python3 switch motivation, the key support people need is support for their favorite libraries. In that regard, maintenance for python 2.7 would involve backporting security fixes also for popular 2.7 third-party opensource libraries and frameworks even if those libraries themselves have already switched to python 3 only.

I wonder how many 3rd party Python2 libraries RHEL ships with? I wonder if Redhat have left themselves enough weasel words in their contracts to say "Oh Python2? No security updates to the interpreter! Oh, you wanted explioted-library-de-jour updated? Well that's not covered in your support contract here. Left me put you through to our professional service division. Please have your contract ID and credit card number…

> I wonder how many 3rd party Python2 libraries RHEL ships with?

Workstation: https://access.redhat.com/documentation/en-us/red_hat_enterp...

Server: https://access.redhat.com/documentation/en-us/red_hat_enterp...

Search for "python"

> I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...

If course they don't do fixes for all of pip / PyPI, nobody does/can be reasonably expected to do. They explicitly only cover what they ship (which does includes numpy and scipy, but not pandas). If you can demonstrate an exploit with just "yum install numpy" I'm pretty sure they'll work on it.

Re: Sunsetting Python 2

#315

Post by gjm11 »

normalhuman wrote: post #235
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…

> For my personal use case at least, this timeline worked out well for me. Hint for Hacker News commenters: 99% of the time, if your phrase includes the term "use case", you can safely just delete it and lose no meaning. It's just a way to say "for me" or "for them" that sounds more technical but really isn't. In this case, you could say "This timeline worked out well for me".

To me, "for me" and "for my use case" mean subtly but genuinely different things.

"For me" highlights the fact that my preferences, character, skills, etc., are different from other people's. Something might work well for me but badly for someone else because I happen to be good at working around its quirks, or bad at noticing its faults, or just not interested in the things it doesn't do.

"For my use case" highlights the fact that the things I need to do are different from other people's. Something might be good for my use case but bad for others' because I don't need very high performance but they do, or because I need the gostak to be able to distim the doshes backwards but they don't.

If I move on to doing different work and someone else takes my place, I expect something that works well "for me" to continue being useful for me but not for them, and something that works well "for my use case" to be useful for them but not for me.

Re: Sunsetting Python 2

#316

Post by marcthe12 »

pelario wrote: post #174
drej wrote: post #159

What surprises me about this is that the documentation for Python 2 does not explicitly say that the language version is about to be unsupported, see e.g. https://docs.python.org/2/library/zipfile.html Contrast this with the Postgres website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html Are there plans to add a banner t…

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.

I keep forgetting how have python one liner of a http server. And always when Google the python2 version will appear and always to play with the search term to get it.

Re: Sunsetting Python 2

#317

Post by kortilla »

sdoering wrote: post #250
ken wrote: post #240

Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Dependenc…

> If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often. > Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. D'accord. Exactly. I had very fruitful d…

Well it’s a shitty analogy because a swap to torx is basically a single API change.

The switch to py3 is more akin to using a new building material. Easy to start with once you know the differences, but it’s a bitch to retrofit if you depend on a method of construction incompatible with it.

“Go change the dependency” is a naive ideal. Most non-tech businesses have no budget for that kind of tech debt work.

Re: Sunsetting Python 2

#318

Post by collinmanderson »

mantap wrote: post #165
shakna wrote: post #124

Earlier quoted context omitted.

Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes. Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.

You couldn't switch to Python 3 until the middle part of this decade unless the stars aligned with your dependencies, the library support wasn't there. And the first releases of Python 3 were glorified betas, the first "usable" version of Python 3 is often considered to be version 3.3 released in 2012.

I feel like there were 3 steps:

- 2008-2012 Python 3 becoming usable (byte formatting, six library)

- 2012-2016 Libraries (Django, etc) becoming compatible

- 2016-today Applications (Trac, Ansible, Chrome[1], etc) becoming compatible.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=942720

Re: Sunsetting Python 2

#319

Post by shpx »

richardwhiuk wrote: post #56
mrweasel wrote: post #5

Earlier quoted context omitted.

I honestly don't believe that many will step up and take over. Many will complain, but few will do the actual work. Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.

Ubuntu 18.04 has support for Python 2.7 til 2028 I think.

There's a list of some enterprise Linux distros and their default python versions and their end-of-life dates on the Wikipedia article for CPython

https://en.wikipedia.org/wiki/CPython#Distribution

Re: Sunsetting Python 2

#320

Post by kortilla »

radlad wrote: post #312
lvh wrote: post #268

Earlier quoted context omitted.

One of the easiest compared to what? Certainly not a Python point release. A couple of points: 1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. 2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining. (I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came…

> Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't. I would expect any stable release of software to be "good and ready." Can you explain what was wrong with Python 3.0 and 3.1? > core dev did not listen to any of the problems people pointed out for _years_ What problems were those?

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.
Post reply on HN