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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com