Phillip J. Eby schrieb: > 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?
I'm still wondering what policy you think I have violated. If we both agree that the old behavior was erroneous, then I cannot understand why you want to see the patch reverted. Nobody has so far proposed any alternative fix (not even as a specification, let alone as a specific patch - just with some hinting), and the majority of the people polled thought that it ought to be fixed. > 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. So you would agree to the change if a warning was generated at run-time? Notice that there is already a warning there: the documentation clearly states that the behavior has changed, and, of course, Misc/NEWS lists it as changed behavior. So you can certainly discover *now* that the behavior has changed: read the documentation. If you want to discover it without reading documentation, we can discuss that. > 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? This is highly theoretical. > If a majority of > people want braces and required type declarations, will we add them? PEP 3099 explicitly rules out the introduction of braces. As for type declarations: it would require a PEP, being a major feature. It then depends on the details. PEP 245 was rejected by BDFL pronouncement. This is how things are ultimately decided: by BDFL pronouncement. > 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. In this specific case, it seems that people had agree on "right" for a long time, and had just accepted that the current implementation is "wrong". You also agree to that, and many other long-time Python contributors have agreed. So as long as those people are around, it is unlikely that they change their minds again on this specific question. >>> 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? No, unlike that. See above, plus the people contributing to Python believe that the current behavior is right (although the view on using tabs-vs-spaces has changed over time). In this case it's different: all long-time contributors seem to agree that the new behavior is the desirable one, on a green field. > 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. No. I firmly believe that even with this change, Python provides "some form of stability". All the alternatives that had been proposed, except for the "never" variant, provide less stability. This is the most stable patch to solve the problem that I could think of. Regards, Martin _______________________________________________ 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
