[selcuka]

> Even now, I dread new python versions because some dependency would start using those features

If a dependency breaks compatibility with earlier Python versions because the author wants to use a fancy new feature is not really the fault of Python, is it? Library authors should target the earliest supported Python version they can.

Being backwards compatible (at which Python has been doing a good job since the 2->3 fiasco) is one thing, but trying to be forwards compatible is something else.

Are you suggesting that Python developers should only ship bug fixes so that Python 3.0 can still run code written for Python 3.11?

[forgotusername6]

This isn't a general problem, but I have been seriously burnt by a change from a minor version upgrade.

In 3.8 someone decided that they didn't like the way people were excepting the Exception for cancelled asycnio tasks. So they changed the cancelled task exception to inherit from base exception instead of exception. This meant a bunch of well used libraries immediately had a load of subtle bugs that in normal operation just didn't happen. I can't remember the exact details but I think when the bug did happen the task queue would just continue to grow until we ran out of memory.

This change wasn't a bug fix, more an optimization or an attempt to get people to code a certain way.

I'm all in favour of bug fixes, but Devs shouldn't have to worry about minor upgrades breaking everything.

See https://bugs.python.org/issue32528

[SPBS]

It doesn’t mean it’s Python’s fault, but it fosters a culture where Python developers who regularly follow the language and are some of the ecosystem’s biggest authors are enticed to trying out the fancy new features (even if the old way still works) because “this is cleaner, this is how I want to do things from now on”.