[Python-Dev] Proposal to revert r54204 (splitext change)

[Aahz]

On Thu, Mar 15, 2007, "Martin v. L??wis" wrote:
>
> I'm not quite sure what "it" is, here. If "it" is that there be no
> incompatible changes in Python: this is not policy, and not even
> consensus. Instead, policy (as enforced by the release manager), and
> consensus is that bug fix releases (2.x.y) must not show incompatible
> behavior. For feature releases (2.x), incompatible behavior is
> acceptable (at least this is what I thought consensus is, but
> apparently I'm wrong).

You are not wrong on one level, but you are wrong on another: if a change
that may not be a bugfix gets any legitimate objections, the bar for the
change becomes much higher, and that goes double or triple if the change
will result in silent breakage of existing programs.

If this discussion had occurred three years ago, I would be more inclined
toward your position, but right now we have another outlet for silent
incompatible changes: Python 3.0.

I'm not opposed to extending the splitext API in 2.6 as one solution for
this problem, but I still believe that pushing the change to 3.0 is best
(assuming we make the change at all, because the people arguing against
any change do have a point about Windows -- and in the end, Windows is
the largest CONSUMER of Python programs).

I do agree with the surprise expressed about your claim that extending
the API isn't backward compatible -- the point is that any code using
pre-2.6 splitext() API will work the same across 2.x regardless of
whether the code is written after 2.6 is released.  Of course anyone who
uses the extended API is backward incompatible, but that's a much
different kind of problem.

Because this discussion has gone on so long, it seems to me that a
micro-PEP would be good for summarizing.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"I disrespectfully agree."  --SJM