[Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

["Martin v. Löwis"]

glyph at divmod.com schrieb:
> The real issue I have here is one of process.  Why is it that PJE (or 
> any python user who wishes their code to keep working against new 
> versions of Python) must frequent python-dev and convince you (or 
> whatever Python developer might be committing a patch) of each use-case 
> for old functionality? 

Because this is the way free software works. I'm the one contributing
(actually, merely integrating changes proposed by others, Larry Hastings
in particular), so I get to make decisions. This patch had been open
for three years. If pje had any problems with it, he could have rejected
it. If you had problems with it, you could have commented that it should
not be applied. Nobody did, so I decide.

> I would think that the goal here would be to 
> keep all the old Python code running which it is reasonably possible to, 
> regardless of whether the motivating use-cases are understood or not. 

Exactly: which it is reasonably possible to. In this case, I found no
reasonable way to keep it running while still fixing the bug, and not
breaking too much other stuff in order to keep that particular code
running. So the only alternative would have been to reject the change
and live with the bug forever, something that many people here
considered bad.

> My understanding of the current backwards-compatibility policy for 
> Python, the one that Twisted has been trying to emulate strictly, is 
> that, for each potentially incompatible change, there will be:
> 
>  * at least one release with a pending deprecation warning and new, 
> better API
>  * at least one release with a deprecation warning
>  * some number of releases later, the deprecated functionality is removed

If you want to contribute a patch that changes splitext to follow this
policy, please go ahead and submit one. I personally consider a
deprecation warning unacceptable in this specific case.

> I was under the impression that this was documented in a PEP somewhere, 
> but scanning the ones about backwards compatibility doesn't yield 
> anything.  I can't even figure out why I had this impression.  *Is* 
> there actually such a policy?

There is PEP 5, which is not followed, since it requires 
backwards-incompatible behavior to go through the PEP process.

> If there isn't, there really should be. 

So submit a PEP. Or better, take over maintenance of PEP 5 (or better,
cooperate with the author of the PEP on maintaining it).

> Perhaps policy isn't the right way to solve the problem, but neither is 
> asking every python application developer to meticulously follow and 
> participate in every discussion on python-dev which *might* affect their 
> code.

And there is no need to. If they find that their code breaks, they
can submit bug reports, or, better, contribute patches. This is what
alpha releases are for, and the trunk is buildable all the time,
so you can test your code against the new release even before it
happens. If you want to study the changes, you can read Misc/NEWS
from time to time.

> If Python is not going to have an extremely conservative (and 
> comprehensive, and strictly enforced) backwards-compatibility policy, we 
> can't rely on those mental models as a way of determining what changes 
> to allow.  One way to deal with the question of "how do people really 
> use python in the wild" is to popularize the community buildbots and 
> make it easy to submit projects so that at least we have a picture of 
> what Python developers are really doing.

I was going to say that. Now, if "the community" doesn't pick up the
concept of community buildbots, "the community" has no right to
complain (IMO, and I put that deliberately into quotes, knowing that
"the community" doesn't exist as such, but is made up of individuals,
some interested in the buildbots, stability, and so on, and others
being less conservative).

> In the past I've begged off of actually writing PEPs because I don't 
> have the time, but if there is interest in codifying this I think I 
> don't have the time *not* to write it.

If you think it needs codification, I think you will need to write it
yourself - nobody else will do it for you. Depending on what it will
say, I might disagree. I do disagree with the requirement that
every incompatible go through the PEP, and I understand "incompatible
change" as "programs only relying on document behavior might break".

In the case that triggered the discussion, the change implemented
was not an incompatible change, because the new implementation still
met the old specification (which, of course, was underspecified).

Regards,
Martin