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

[Phillip J. Eby]

At 07:45 AM 3/15/2007 +0100, Martin v. Löwis wrote:
>I apparently took the same position that you now take back then,
>whereas I'm now leaning towards (or going beyond) the position
>Tim had back then, who wrote "BTW, if it *weren't* for the code breakage, 
>I'd be in favor of doing this."

If it weren't for the code breakage, I'd be in favor too.  That's not the 
point.

The point is that how can Python be stable as a language if precedents can 
be reversed without a migration plan, just because somebody changes their 
mind?  In another five years, will you change your mind again, and decide 
to put this back the way it was?

Speaking as a business person, that seems to me... unwise.  When I found 
out that this change had been checked in despite all the opposition, my gut 
reaction was, "I guess I can't rely on Python any more", despite 10 years 
of working with it, developing open source software with it, and 
contributing to its development.  Because from a *business* perspective, 
this sort of flip-flopping means that moving from one "minor" Python 
version to another is potentially *very* costly.

The process of having warnings at least ensures that I can *discover* 
whether my programs depend on some behavior that has changed - rather than 
having something that used to work and now doesn't.


>I now believe that this should be done *despite* having been
>documented and tested (which, as you can see, was documented
>and tested only match the implemented behavior). That it keeps
>popping up is proof that the old behavior is deemed incorrect
>by many people.

But as you are so fond of pointing out, there is no "many people".  There 
are only individual people.  That a majority want it one way, means that 
there is a minority who want it another.  If next year, it becomes more 
popular to have it the other way, will we switch again?  If a majority of 
people want braces and required type declarations, will we add them?

After all, there is *substantial* support for some proposals along those lines!

Yet, one of the appeals of Python is that it has some sense of what is 
"right" or "wrong", and some explanation for that rightness or wrongness 
that doesn't change with the ebb and flow of popular opinion and the 
current population of a mailing list.

IMO, Python is not -- or at least should not be -- a popularity contest.


>>So reject it, or propose to add a new API.
>
>Neither is a solution. Rejecting it means it will keep popping up
>forever.

Like requests to remove whitespace sensitivity and add braces?

That a request may keep popping up forever is not an argument for changing 
it NOW.  As Tim put it, "Never is often better than *right* now," and it 
seems to me that this is *exactly* the sort of change for which that saying 
was coined.


>The amount of Python code yet to be written is hopefully larger
>than the code already written (paraphrasing Guido), so in the long run,
>it should show the right behavior, not the historical one.

Sure - but by that argument, the amount of code that will be written in 3.0 
or 3.1 is larger still, and if this behavior's been mostly okay for 9+ 
years, then fixing it in a year or two should be quite prompt, if you want 
to look at the historical scale.

In any case, my main concern about this change isn't whether it's right or 
wrong -- it's about whether Python provides a stable platform for software 
development with reasonable migration paths.  *This* change won't actually 
hurt *me* -- but what will the next change be?  Must everyone who wants 
some form of stability maintain a constant watch over Python's source changes?

I gather that your answer is "yes", and that's what disturbs me here.