Live data from Hacker News

Sunsetting Python 2

python.org

221–230 of 733 posts

Re: Sunsetting Python 2

#221
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…

>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.

You could work on porting them or be part of that effort?

Re: Sunsetting Python 2

#222

Thank God. It's been really annoying having to add parenthesis to all the print statements when I accidently download a python 2 script.

I've found that the 2to3 script will do this. The real pain is finding everything that now has to be bytes instead of string.

Re: Sunsetting Python 2

#223
post #158
post #121

Earlier quoted context omitted.

Did we read the same document? It seems fine and a perfectly normal explanation of what’s going on and why, like any software with a defined lifecycle would have.

I guess it depends what lens you are reading it through. If you're used to reading documents from open source projects it seems perfectly normal. If you're used reading documents from Oracle and SAP explaining changes to their long term support contract, then this will sound completely alien.

If they had put “Pay x USD to continue using python 2 till 2020” in the document, I bet it would have been less alien to oracle customers [1].

[1] https://www.businessinsider.com/oracle-customer-explains-aud...

Re: Sunsetting Python 2

#224
post #112

I long for the day when typing "python" into a shell will bring up a python 3 prompt

Switch to Arch Linux and live the dream. It has had python3 as /usr/bin/python since 2010. https://www.archlinux.org/news/python-is-now-python-3/

My mint 19.2 installation does the same. To run a python 2 script I have to run my conda python 2.7 install now.

Re: Sunsetting Python 2

#225
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…

>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. You could work on porting them or be part of that effort?

Some people have full-time jobs and other obligations already that don't include time for this kind of effort.

Re: Sunsetting Python 2

#226

Earlier quoted context omitted.

The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now". If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.

If the only way your organization can prioritize this is either “drop everything and update” or “completely ignore and do no work to prepare,” then it sounds like Python versioning is not your biggest problem.

Unfortunately, I think this type of thing actually is the case for many organizations. Trying to explain the business case for paying off technical debt to a non-technical person can be very difficult when "right now everything works."

Re: Sunsetting Python 2

#227
post #128

Earlier quoted context omitted.

They are effectively both dead or moribund. Jython has had a py3 experimental branch for ages but the entire project is basically starved of money and effort. To be honest, the whole “Python on other runtimes” movement, as a concept, is more or less over. It’s just too much effort for too little reward, now that CPython has good libraries for pretty much anything you can think of.

Does that view include PyPy? I'm not deep into Python (aside from the Monty kind) but it seems to be maintained and makes performance claims.

PyPy is a python-focused project that builds a python-focused runtime. My comment was more about projects trying to retrofit Python on top of runtimes that were built for very different languages, typically because of some constraint that has now disappeared.

Re: Sunsetting Python 2

#228

I long for the day when typing "python" into a shell will bring up a python 3 prompt

And I would add - symlinking or shell aliasing does not count! I want a linux system without a single python2 binary anywhere on the disk!

How many more decades must we wait??

Re: Sunsetting Python 2

#229
post #140
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.

There is Tauthon[1] which backports Python 3 features to 2 and seems to do the "actual work". It has been around a while. It was also posted in this thread below by the current maintainer of the project but for some reason that comment was downvoted to [dead]. By reading a bit around about it, i do get the impression that the Tauthon developers face a bit of hostility from the Python community, so i'm not sure how vi…

It wasn't downvoted to dead - the author has been banned, they've copied dang's comments to their profile.

(Unlike other forums, banned users can still post, but their posts require someone with showdead on to vouch for it before it can be seen).

Re: Sunsetting Python 2

#230

Earlier quoted context omitted.

The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now". If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.

If the only way your organization can prioritize this is either “drop everything and update” or “completely ignore and do no work to prepare,” then it sounds like Python versioning is not your biggest problem.

I get this, though: porting code affects all parts of the code base, so it generates git conflicts all the time. It's way more of a pain to do than routine feature development or refactors. It gets difficult to have part of the team work on features while another group works on the port to a new version, because that generates a ton of conflicts. It's easier to get the entire team working on the port.

I had to manage a mature codebase upgrading Ruby versions, and it was painful. And that is fairly mild by comparison; not the big jump from Python 2 to 3.

Post reply on HN