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

[Steve Holden]

Phillip J. Eby wrote:
> 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.
> 
The impact of this one little change certainly isn't the only issue at 
stake here. But as Mr. Creosote knows, even one little "wafer thin" 
change can lead to a chaotic transformation. Since 2.0 serious efforts 
have been made to maintain, and even promote, the stability and 
backwards compatibility of Python. This has benefited the language.

This particular change looks like gratuitous breakage, no matter how 
sound the reasons for it, and putting it in to 2.6 with 3.0 "just around 
the corner" (though not for production purposes) is guaranteed to upset 
some people and cause adverse reaction.

Now, you might feel (as Guido does) that it doesn't matter what people 
write in their blogs, but I personally want people to perceive Python as 
a language whose development is carefully managed. Consequently I am 
disturbed when a change of this nature is made and it becomes apparent 
that there is no consensus for it.

This is not "prevarication", it's a serious discussion about how such 
issues should be managed.  The current glaring lack is of a sound 
decision-making process. Such breakage-inducing change should be 
reserved for major versions (as was the fix to the socket addressing wart).

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb     http://del.icio.us/steve.holden
Blog of Note:          http://holdenweb.blogspot.com
See you at PyCon?         http://us.pycon.org/TX2007