The relevance of the use case isn't the problem. Even if people had been using it wrong for all this time, the update is still going to break their code if they did use it this way. And if it was possible, of course many people did.

3.7 already broke a few packages by choosing to not do the True/False dance again and make async/await keywords. I took a lot of people by surprise, not because of the issue itself, but because of the change of philosophy compared of what Python had been in the past.

Do we really want to make a habit of breaking a few things at every minor release ?

It's fair to expect, as a user, that any 3.x will be aiming to be forward compatible. This was the case for Python 2.X and was part of the popularity of the language: a reliable tech.

I'm advocating that any breaking change,, even the tiniest, should be behind a __future__ import or a flag, with warnings, and then switched on for good on Python 4.0.

Python is a language, not a simple library. Stability is key. Like Linus Torvald use to say: "do not break user space"

The fact this change is easy to fix and migrate is not a proper reason to ignore this important software rule, IMO. So many people and so much code rely on Python that the tinest glitch may have massive impact down the line.

Not to mention that after a decade of healing from the P2/3 transition, the community needs a rest.

Le 21/10/2019 à 13:26, STINNER Victor a écrit :
>
> STINNER Victor <vstinner@python.org> added the comment:
>
> What is the use case for having a relative sys.argv[0]?
>
> > Isn't that change breaking compat ?
>
> Right. It has been made on purpose. The rationale can be found in the first message of this issue.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue20443>
> _______________________________________
>