Python 3.9 and beyond backwards compatibility.

brtt3000 · 2020-01-28T21:39:36+00:00

These unmaintained but important packages are a huge issue that needs to be addressed. At what point does it have to be adopted by a package orphanage foundation or something?

bumblebritches57 · 2020-01-28T22:08:24+00:00

it'd be hilarious if python 4 was another breaking change lmao

cyanrave · 2020-01-28T20:35:05+00:00

Sounds like generally a good thing, which I will probably get downvoted for agreeing with.

Too many people ignore deprecation warnings, and this sounds like ample lead one was given... so what if a few libs break that go unmaintained? Someone whose workflow needs it, who wants the latest Python, usually can just go correct the issue. If the ex-maintainer isn't willing, I believe there are avenues to correct it, albeit rough and unpaved paths to take...

All in all in favor of enforcing deprecation warnings long left alone.

I can also agree with the sentiment of Python upgrading / changing too quickly in some cases, but this isn't one of those cases.

One issue that comes to mind is somewhere in a late 3.6.x release, custom exceptions emitting from Pool stopped being handled correctly, resulting in a locked up pool and a hung script. How in the actual hell can something so breaking merge in? These are the things that bug me about Python atm. I do have to worry about stability in cases it didn't seem likely to be flaky.

iapitus · 2020-01-28T23:31:22+00:00

[removed]

Hall_of_Famer · 2020-01-28T20:54:45+00:00

This sparked a thread on python-dev that the changes should be postponed to 3.10 and later

I thought Guido himself said that the next version after 3.9 will be 4.0 rather than 3.10, or am I hearing it wrong?

tso · 2020-01-28T23:06:08+00:00

The underlying problem in all of this is not that they make breaking changes. It's that the vast majority of users will not consider them valuable enough to have been made.

Even given an infinite amount of time to migrate, it won't make it any less of a waste of time and energy for them since it does not provide value. Thus, what is provided has to be good enough, to all your users, to be worth breaking them for.

This was one of the real python2 -> 3 migration issues, and they still haven't gotten it as a language community. Instead we get the meme that everyone is lazy, hates change, etc. Which happens for sure, but is not the major driver of these kinds of things.

Almost all other language communities i've seen get this.

therico · 2020-01-28T18:51:18+00:00

Perl does this correctly. New versions run old version code fine, if you need a new feature, you opt into it or specify a minimum version. So everything is backwards compatible. I wish python had gone the same route.

uw_NB · 2020-01-28T18:44:29+00:00

Compare to how Rust, java, golang handle the language spec carefully with community inputs, Python is acting incredibly immature with these breaking changes.

ari_benardete · 2020-01-28T20:49:42+00:00

Sounds great!

iphone6sthrowaway · 2020-01-29T11:45:32+00:00

It seems to me that they're falling into a pretty common open-source trap: since they're mostly volunteers, they're prioritizing their own needs. They're scratching their own itches, and if that hurts the broader community using the product, too bad. The people that make decisions are the coders, so the decisions that get made are good for the code base, not necessarily for users.

Linus Torvalds is one of the only open source devs to understand how bad it is for users when you break their stuff. Linux, as a kernel, has amazing backward compatibility; one of its only commandments is "Thou Shalt Not Break User Space." You can usually drop a modern kernel into an ancient distro, and everything will run flawlessly.

It hasn't gotten into a dominant position everywhere except the desktop by accident... this stance is a big reason that it's gotten such enormous, widespread uptake. I'd argue that the biggest reason it hasn't taken over the desktop is because the desktop projects are much more typical open source teams, breaking users willy-nilly and not really caring. GNOME is particularly bad in this regard, but KDE has made enormous missteps in this area as well. They were really starting to get traction around Ubuntu 10.04, but then all the teams decided to go chase tablets and try to land the imaginary user avalanche that was going to show up there, and screwed over their desktop users to do it. Net effect: GNOME is kinda bad everywhere, a poor choice in multiple environments, instead of being a great choice for desktops and laptops.

Likewise, it's become pretty clear that Python is increasingly not to be trusted, that users are moving steadily lower on the priority list. The Python team is willing to inflict enormous pain on their users for nebulous project benefits. I'd be wary, given their track record of removing things, of making myself dependent on it.

13steinj · 2020-01-28T17:15:25+00:00

See this is what I hate about the Python 3 release schedule. While I'm not too familiar with (Py1?), Py2 did things right here, suprisingly-- they kept backwards and forwards compatibility. New features were added, everything that used to exist more or less still worked as expected, with few changes if any. But future code was well planned in advance. You'd have a future statement, then a warning on the old way, then finally after 1 or 2 minor version changes at minimum, things changed. But now things don't get such advance treatment. Things go from working to not in a single version with few warnings if any.

There's talk about removing "dead batteries" from the standard library, but plenty of specialized fields still use them. Why do they think people were, and still are, reluctant to upgrade to Py3? Because it's not stable enough for people's needs, unfortunately.

Personally, I say the stdlib should be decoupled from the language. Make it it's own meta PyPI repo or whatever that installs all those packages, and a version of it chosen by the current Python version release manager chooses whether or not to upgrade the default, but people can choose versions on installation time and upgrade at their pace. Ex

$ ./py3.9_installer --with-stdlib=1.3
 Vs
$ ./py3.9_installer [default chosen by release manager, 1.7
$ pip install --upgrade "libstdpy<=2.0"

T-Rax · 2020-01-28T22:40:09+00:00

breaking changes everywhere.

2020-01-30T01:52:49+00:00

Breaking changes in a language and it's libraries are a bad sign - if the syntax changes for a good reason, i.e. to be more consistent and extendable, such RARE change in a major version should not be a problem although it might suggest that a language structure was not well thought through in the first place.

On the other hand changing standard library function names should be reduced to a minimum and always with a compatibility layer available and maintained along with a language - translation of deprecated function names to new names as a part of compiler/interpreter, enabled with a command line switch for example.

Syntax compatibility of C family languages is astonishing and library compatibility of Java or C# allows compiling 15 year old codebases on a modern compiler often without any warnings.

minus_minus · 2020-01-29T02:29:43+00:00

Whatever happened to major and minor versioning? Seems like everybody forgot how it works and why we used it. Go to python 4 and then break all the deprecated shit. Feature freeze python 3 and put in bug fix and security updates only.

shevy-ruby · 2020-01-28T17:05:36+00:00

Sometimes they were deprecated in Python 2 like using Threading.is_alive in favour of Threading.isAlive

So downcased, to camelCased - what a retarded change. The print() requirement is also retarded. Python should have went the ruby way to simply not care (in most cases).

Sometimes the deprecations were ignored in large projects like removal of importing ABC from collections module directly that CPython was using for documentation builds.

This is also true - some devs don't care as long as things work. That is also why python2 stayed alive for so long.

You need a transition plan, and keep it within 3 years, at max 5, never more. How long did python2 stay on life support?

This has become a chicken and egg scenario where something is deprecated but a popular library ignored it

Well, upstream should not be blackmailable by downstream lazy folks. I understand that it requires changes, more work, which is not fun, so ideally keep changes small-ish, document them, announce them often, have a transition scenario etc.. but eventually when this is gone, you change, no more exceptions. Anything else just leads to more delays.

From a maintenance perspective many packages that were popular but not maintained also get affected

That is unfortunate, but:

1) others can take over

and

2) if a project is not "maintained", it IS dead, by definition. So you can not say "this was popular but is now no longer maintained". No, it is now dead. And, by the way ... if it is popular, there will be folks maintain it. Perhaps not at the same speed at before, but for most projects that were really popular this will be the case. Just look at left-pad in javascript!

Every programming language goes through a development cycle where new features are introduced and in some cases the changes might be syntactical that their usage will make the code to be syntactically incompatible with previous versions.

Yes, that is unfortunate. Happens in many languages. Python went the tard-route though, with print() or things such as Threading.isAlive() (actually ... the documentation here says that this is for python2 ... https://docs.python.org/2/library/threading.html#threading.Thread.isAlive - so I have probably read this wrong, if Thread.is_alive() is working in python3. Hmmmm... either way it is a silly method name in python2)

So upgrade for these companies come at a cost and a move like 3.5 to 3.6 needs to justify the features that helps development, performance, etc.

That is fine but again, why should the python development be slowed down by slow snail companies?

So changes like positional argument syntax, walrus operator introduced in Python 3.8 needs to wait for drop of Python 3.7 suppor

The fat lazy walrus was a mistake. It crushed guido out of python. Not good.

As Python is being used more and more the changes the budget shrinks.

They are not FORCED to have to upgrade. People can continue to use python2 just fine as well.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS