LWN: Comments on "Shortening the Python release schedule"

Work required for new major releases

azumanga — Fri, 25 May 2018 12:15:40 +0000

The problems with new Python releases aren't the wrapping and that type of thing, that is all automated.

It's that inevitably a whole bunch of programs that use Python are going to get broken in obvious, or subtle, ways, and they all need testing and debugging. That's harder to automate.

Shortening the Python release schedule

smurf — Thu, 24 May 2018 23:04:31 +0000

You forget "feature present, but saddled with random pain points which require arcane workarounds, yet are set in stone for the next three releases".

Shortening the Python release schedule

smurf — Thu, 24 May 2018 23:00:52 +0000

"Experimental" is meaningless when you have no way to find out whether the version you're talking to implements a feature or not. HTML's client browser identification is mostly meaningless for well-known reasons, there is no sane way to do "if FOO is implemented [reasonably correctly], use it, otherwise use this entirely different other method" in CSS, and don't get me started on the still largely abysmal state of end-to-end testing.

No such problems exist with Python versioning.

Shortening the Python release schedule

jhoblitt — Thu, 24 May 2018 18:13:10 +0000

That's one possible interpretation... another is that when a project says a feature is unstable/experimental/beta it should mean it.

Shortening the Python release schedule

excors — Thu, 24 May 2018 18:00:35 +0000

Vaguely related to this: Around the time of HTML5, web browser developers realised that standards were good and it was a bad idea to pollute the global namespace with their own proprietary experimental features, so they used vendor prefixes to make it clear they were non-standard and not safe to be relied on by web sites, with the idea that eventually they'd be improved and standardised (based on experience from the experimental implementations) and have the prefixes removed. But it turns out that many web developers are irresponsible and will happily rely on those prefixed features in real production web sites, because all they care about is that it works today on their favourite browser, and then users of other browsers (or other versions of the same browser) blame their browser when sites look broken. That situation ends up with e.g. Firefox implementing webkit-prefixed features.

I guess the conclusion is: don't give developers a useful feature and then tell them not to use it, because they'll use it anyway, and either you'll have to support it forever or you'll go through the same pain as with any other compatibility-breaking change. "Experimental" and "deprecated" are meaningless.

Shortening the Python release schedule

willy — Thu, 24 May 2018 01:46:41 +0000

You might like to read https://www.joelonsoftware.com/2012/07/09/software-invent...

Shortening the Python release schedule

Cyberax — Wed, 23 May 2018 22:30:46 +0000

Doesn't matter. As long as it's out there and easily enabled, people are going to depend on it.

It's far better to have two distinct states: "feature present" and "feature not present" rather than a plethora of "present", "present, but broken", "present, but incompatible with the next version".

Shortening the Python release schedule

cyperpunks — Wed, 23 May 2018 21:25:01 +0000

What is this?

It should slow down, at least a 3 years cycle.

Work required for new major releases

jhoblitt — Wed, 23 May 2018 19:09:51 +0000

Are there any statistics on vendor supplied vs 3rd party interpreter usage?

My experience, in a scientific computing environment, has been that the system python is primary used by the system itself and perhaps a few small user scripts but anything 'serious' uses a 3rd party interpreter. In my $day_job env that is mostly a mix of miniconda (lightweight default package set version of anaconda) and the rh-python36 scl.

In fact, its often the same pattern for node, ruby, and even perl5. Distro versions either move too slowly or are excessively disjoint between major distros.

Shortening the Python release schedule

jhoblitt — Wed, 23 May 2018 18:55:05 +0000

Experimental features could be hidden behind a cli switch, some sort of pragma statement, or even adding `alpha` or `beta` on the keyword, module name, etc. as long as its not a parser change.

Shortening the Python release schedule

tlamp — Wed, 23 May 2018 18:23:54 +0000

> I'd rather see less frequent stable releases, with usable betas and features that see real world testing before they are set in stone. That means fewer versions to think about when e.g. wanting to support a large set of distros until their EOL.

The problem with this is: once people start using it in the wild it's more or less set in stone, you cannot really break with production stuff.
If you argue that they simply shouldn't not guarantee any API/Functional stability then I'd say that no one will really use it at a scale where it would become obvious if the new features and changes do actually well, it's a catch 22.

Work required for new major releases

smurf — Wed, 23 May 2018 16:56:12 +0000

True, getting a new major release of Python into, say, Debian, is a whole lot of work. However, I'd assume that most of this work can be automated rather easily, if it isn't already – and the motivation to get that automation actually up&running increases when Python is released more often.

Shortening the Python release schedule

smurf — Wed, 23 May 2018 16:52:02 +0000

The problem with setting new features in stone is that they frequently need to be refined by real-world usage. I'd rather see a release every year with more features that are explicitly marked as provisional, then frozen in the next release.

Shortening the Python release schedule

Otus — Wed, 23 May 2018 16:07:45 +0000

What's the point of frequent major releases? It's not like I can use features from release 3.X when it is released, but when 3.X-1 and earlier no longer have to be supported. And that's often years after the release of 3.X anyway, so half a year makes little difference.

(Unless it's a personal project in which case I can use them even while 3.X is still in beta.)

I'd rather see less frequent stable releases, with usable betas and features that see real world testing before they are set in stone. That means fewer versions to think about when e.g. wanting to support a large set of distros until their EOL.