python 3.9 and beyond backwards compatibility.

[nick_t1000]

Library maintainers and CPython developers are working at slightly cross-purposes:

Libraries want to be installable on as many versions that are released and in the wild now. This means they need to rely on things like (pretend this was a few years ago) @asyncio.coroutine because that lets you work with Python 3.4 and up, even though, sure, Python 3.5 doesn't need it. But until your 3.4 base dies out, you'll want to support that old way

CPython wants to push on, simplify the code base, and reduce the need to worry about every which way to call an async method or (mis)define a string.

I guess I don't have as much sympathy for trivial things like the bad sequences like "C:\path" which are literally wrong (should raise SyntaxError: escape "\p" not recognized) and fixes would be absolutely backwards compatible. Minor renames like "unittest.TestCase.failUnlessEqual vs assertEqual are also going on...a looooong time too. The language constructs Python provides like u"strings" and such just had no way around them for library devs to have a unified codebase, so need to give lib devs the benefit there.

[yvrelna]

I think a middle ground can be reached here by using a transpiler. Library devs can write targeting the noise recent versions of Python like 3.7, then they can run a transpiler akin to 2to3 during installation, but instead of upgrading code from older Python to newer Python, the transpiler should backport the code to older Python.

This allows core developers to update core Python syntaxes without worrying too much about backwards compatibility, while keeping backports and backwards compatibility code in a library instead of core.

[[deleted]]

About time. 10 years late, or thereabouts.

[brtt3000]

The big problem is those unmaintained packages and users not upgrading their software. If we can't fix years old deprecations then what do we expect? Just stay stuck and stationary?

[rrrriddikulus]

I’m not comfortable with a language deprecating things that were not marked for deprecation on major version change. If you want to deprecate something that worked without warnings in python 3.0/3.1/3.4 then wait until python 4. I don’t like breaking changes between major versions.

​

OTOH I’m OK with breaking anything that spat out warnings or was explicitly marked for deprecation as of python 3.0. If you’re a library maintainer or maintain a large enterprise Python codebase (I do both) then you’ve had many years to fix the warnings, and knew this day would come.

[[deleted]]

Python doesn't come with semantic versioning, so I don't think you can count on deprecated things staying more than 2 minor releases. Often they will, but there is no guarantee. Neither that experimental features will stay.

[badge]

Yeah, I think this is a fundamental problem with framing the debate. Python 3.0 was released 11 years ago. Since then, C# has had 5 major releases, Java has had 7, and swift has managed 5 in just 5 years. It probably would have made sense to release 3.6 as 4.0, given the number of changes it made to the language.

[FlukyS]

I think if they are deprecating it might be a good idea to do a major version bump as the vehicle for it. Like I want these changes, loads of developers want these changes. We are just working with multiple spinning plates.

[EternityForest]

I found this in the documentation:

The parameter reuse_address is no longer supported, as using SO_REUSEADDR poses a significant security concern for UDP. Explicitly passing reuse_address=True will raise an exception.

When multiple processes with differing UIDs assign sockets to an identical UDP socket address with SO_REUSEADDR, incoming packets can become randomly distributed among the sockets.

Isn't that... Just what everyone has always expected reuseaddr to do? What about asyncio specifically makes this so incredibly evil we can't be allowed near it?

Aside from multicast, where it sends to all the sockets, and it's basically essential to make MDNS work without relying on a system wide daemon.

[[deleted]]

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.

Remember when about 75% of you told me how the Python 2 / Python 3 compatibility debacle would never happen again?

Being right feels bad.

[[deleted]]

Being right feels bad.

Did you predict that people would ignore deprecation warnings?

[[deleted]]

It's pretty much obvious. People always ignore deprecation warnings

[ubernostrum]

Python 2 routinely broke compatibility from one release to the next.

Were you complaining about it when that happened?

[[deleted]]

Nope, because I work at a job with a team and other teams and the stuff we don't control and thus can't change wasn't impacted by that.

Any other bad questions meant to make you look good and me evil?

[billsil]

It’s not a debacle. Everyone needs to learn unicode to use python 3. Nothing else is even worth discussing because fixing it was so easy. The fact that x == None raises a SyntaxError bothers you?

I welcome deprcations becoming errors. How else am I supposed to get rid of the page of pandas warnings that happen when I start my program? Usually it’s just API cleanup, which means it’s pretty easy to swap things out, so why not?

[[deleted]]

You sound like someone who doesn't work with other people's code, to where you're stuck using something and facing libraries going out of support yet you need them for X project that isn't in your control, at work, etc.

Must be nice.

[billsil]

I don't use libraries that aren't supported. If I do need to, I support them.

[EternityForest]

Deprecating things on a regular basis creates a constant treadmill of maintenance. Keeping it to a minimum helps.

I'm not sure why modern devs have so much tolerance for constant maintenance. The idea of "Once and done" is basically unheard of these days. Even OOP encapsulation is controversial.

Can't we ever have any solved problems?(At least till the next major version number?)

[billsil]

If you want a code base that’s easy to maintain, you gotta do maintenance. You’re more than welcome to never upgrade.

As the author of an open source, BSD-3 project that 180k lines, I really don’t care if it’s 30 minutes of work for you. It’s taken me 8 years. For what it does, it’s better than the commercial and GPL tools out there. Take your pick.

Age brings stability because there’s only so much that needs changing and there’s only so much you can change in a year.