Comment by yingw787 | Hacker News Reader

Comment by yingw787 | Hacker News Reader

Parent Full thread

This seems like a vast swath of things to deprecate with one PEP, but it looks like the author of the PEP talked with a large number of core developers about issues that they had with the stdlib and decided deprecated packages that way, which I think should be good for approval of the PEP.

I have a couple of questions:

- I realize there may not be a fork with this PEP implemented, but how might this impact Python's local relative build time, and how might that convert over to the build pipelines? Drastically faster build times would be really nice.

- Are Python 2 -> 3 migrations for stdlib packages mostly rewrites or mostly tacking on compatibility layers like `from __future__ import unicode_literals`? If stdlib packages were updated with Python 3 syntax, it might indicate sustained demand for said package going forward. I'm not sure.

> Are Python 2 -> 3 migrations for stdlib packages mostly rewrites or mostly tacking on compatibility layers like `from __future__ import unicode_literals`?

Packages in the stdlib don't need compatibility layer since they are always used with the Python version they were written for, it's motly incremental rewrites.

Regarding the build time, I don't think most of the time is spent testing those parts of the stdlib.

I'm not the OP, but I suspect that what was means was backporting features to py2.7, which presumably use some new Python 3 which haven't been built in the old language version.

I don't think that back porting features to 2.7 it's in anyone's radar anymore given that it goes end of life in just over 7 months. Anything that isn't already there is likely not going to benefit many people

Lots of people are on python 2, and if they didn't already migrate then an EOL notice isn't going to be a big motivator.

You'd be surprised I think. In my job, EOL noticed are all it takes, often, to push people onto the next version, even reluctantly. I imagine many situations where Python 2 is still used are not developer driven but, rather, business value propositions. Many of my clients wouldn't understand a discussion about upgrading because of Unicode strings, but if I were to mention to my clients that Python 2 is no longer receiving bugfixes and officially has reached EOL status you can bet they would all throw money at it.

> how might this impact Python's local relative build time

stdlib usually written in Python, not in C. So I guess it won't affect the build time much. It will reduce test time but I'm not sure.

Reply on news.ycombinator.com