4 ms·

Compatibility is great if you're building on solid, or at least good enough foundation. But that's not Python, the foundation is dubious, or even bad. Extensive

Compatibility is great if you're building on solid, or at least good enough foundation. But that's not Python, the foundation is dubious, or even bad. Extensive C API which prevents advanced JIT efforts, tons of dead libraries in standard library. Also, even having solid foundation and big company backing, Java is also regularly deprecating and removing things. Full, unquestionable compatibility is good only if you're committee wizard in your tower and don't care about users beyond big corporate at all, aka C++ model. Oh, and one thing about Python: it's very understaffed. They have like 3 fully paid devs at all? For a project of this impact, it's really bad. Compare this to tens of thousands of man-years spend on JS.

BiteCode_dev 6y ago
I agree, and I'm not advocating to freeze the python language, nor don't understand how understaffed the python core devs are. But there are strategies that are in used or have been in used that we could draw inspiration from: - async/await didn't need to become keywords so fast. True/False were not for 15 years. - changing the default encoding is behind env var flag. - changing the way the c api is done is currently made doing the separate HPy project. It's not breaking anything. So there were instances where people intelligently decided to move the language forward, but stopped and remembered Linus wisdom of "we don't breaking userland". And they did improve things without breaking others. Guido used to be very strict on that too. But after so many years, we can't expect him to spend all his energy still policing every aspect of the project, especially after he stepped down as a BDFL.
mixmastamyk 6y ago
I looked at the psf budget last normal year, iirc it was like five million in income. They choose to spend most profits on outreach and teaching. That’s their decision but then they also complain about being under resourced, leading to compat breaks on minor versions. I don’t believe it is necessary, compatibility should come before most other activities.
- williamsmj 6y ago
  1. 3.x to 3.x+1 is referred to as a major version change in Python. It's the same in Go, where 1.x to 1.x+1 is also a major version change (https://golang.org/doc/devel/release.html#policy https://golang.org/doc/devel/release.html#policy). Python does not use semantic versioning, which may be why your expecations do not align with reality. And they do not introduce breaking changes without two major version bumps (i.e. two years) of public warnings about their plans (in that sense they are more conservative than semver). 2. This breaking change has not happened yet. 3. If it does happen, it won't be because the PSF is under-resourced. It will be because a long formal process occurred in back in 2017 to ratify PEP 563, and that processes success started a timer on its incorporation into python 3.9 or later, consistent with Python's deprecation policy. You can argue that this was a bad decision, but "spending most profits on outreach and teaching" is not the reason it happened. 4. The reason resources are a problem is because the original link here is someone encouraging his users to harass the small (too small!) group of uncompensated volunteers who manage python releases, three weeks before the release, behavior for which he has since apologized.
  - mixmastamyk 6y ago
    > why your expectations do not align with reality My expectations align with industry practice, and so should yours. Python is welcome to play games with their version numbers, it doesn't change expectations however. That they made mistakes with unicode at 3.0 doesn't mean there should be breaks every X.Y release instead.

BiteCode_dev 6y ago

I agree, and I'm not advocating to freeze the python language, nor don't understand how understaffed the python core devs are. But there are strategies that are in used or have been in used that we could draw inspiration from: - async/await didn't need to become keywords so fast. True/False were not for 15 years. - changing the default encoding is behind env var flag. - changing the way the c api is done is currently made doing the separate HPy project. It's not breaking anything. So there were instances where people intelligently decided to move the language forward, but stopped and remembered Linus wisdom of "we don't breaking userland". And they did improve things without breaking others. Guido used to be very strict on that too. But after so many years, we can't expect him to spend all his energy still policing every aspect of the project, especially after he stepped down as a BDFL.

mixmastamyk 6y ago

I looked at the psf budget last normal year, iirc it was like five million in income. They choose to spend most profits on outreach and teaching. That’s their decision but then they also complain about being under resourced, leading to compat breaks on minor versions. I don’t believe it is necessary, compatibility should come before most other activities.

williamsmj 6y ago
1. 3.x to 3.x+1 is referred to as a major version change in Python. It's the same in Go, where 1.x to 1.x+1 is also a major version change (https://golang.org/doc/devel/release.html#policy https://golang.org/doc/devel/release.html#policy). Python does not use semantic versioning, which may be why your expecations do not align with reality. And they do not introduce breaking changes without two major version bumps (i.e. two years) of public warnings about their plans (in that sense they are more conservative than semver). 2. This breaking change has not happened yet. 3. If it does happen, it won't be because the PSF is under-resourced. It will be because a long formal process occurred in back in 2017 to ratify PEP 563, and that processes success started a timer on its incorporation into python 3.9 or later, consistent with Python's deprecation policy. You can argue that this was a bad decision, but "spending most profits on outreach and teaching" is not the reason it happened. 4. The reason resources are a problem is because the original link here is someone encouraging his users to harass the small (too small!) group of uncompensated volunteers who manage python releases, three weeks before the release, behavior for which he has since apologized.
- mixmastamyk 6y ago
  > why your expectations do not align with reality My expectations align with industry practice, and so should yours. Python is welcome to play games with their version numbers, it doesn't change expectations however. That they made mistakes with unicode at 3.0 doesn't mean there should be breaks every X.Y release instead.