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

Steve Holden steve at holdenweb.com
Thu Mar 15 19:35:39 CET 2007

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

More information about the Python-Dev mailing list