Shortening the Python release schedule [LWN.net]

Shortening the Python release schedule

Posted May 23, 2018 18:55 UTC (Wed) by jhoblitt (subscriber, #77733)
In reply to: Shortening the Python release schedule by tlamp
Parent article: Shortening the Python release schedule

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.

to post comments

Shortening the Python release schedule

Posted May 23, 2018 22:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

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

Posted May 24, 2018 23:04 UTC (Thu) by smurf (subscriber, #17840) [Link]

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

Posted May 24, 2018 18:00 UTC (Thu) by excors (subscriber, #95769) [Link] (2 responses)

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

Posted May 24, 2018 18:13 UTC (Thu) by jhoblitt (subscriber, #77733) [Link]

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

Posted May 24, 2018 23:00 UTC (Thu) by smurf (subscriber, #17840) [Link]

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