On 3/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 05:51 pm, [EMAIL PROTECTED] 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? > > Hear, hear. Python is _not_ stable as a language. I have Java programs > that I wrote almost ten years ago which still run perfectly on the latest > runtime. There is python software I wrote two years ago which doesn't work > right on 2.5, and some of the Python stuff contemporary with that Java code > won't even import.
I think the problem has less to do with bug fixing than with lack of any clear specifications or documentation about what developers can depend on. You could probably make a case that any change that doesn't fix a crash bug is likely to cause some particular program to behave differently. Take bug 1504333 which lead to a change in sgmllib behavior for angle brackets in quoted attribute values. Did the sgmllib documentation explain that the fixed behavior was incorrect? Might a programmer working with sgmllib have written code that depended on this bug? Do you object to this bug fix? For many of these bugs, some people will have written code against the documentation and some people against the implementation or behavior. (In this case, the documentation is vague or conflicting.) I don't think I know how to balance the important of these two classes of users. Some code is going to break the first time they run into the under-specific edge case, some code is going to break when the specification and implementation are clarified. You have to weigh which you think is more likely and which will benefit users the most. I think everyone wants to do the "right thing" by Python's users, but it's not clear what that right thing is. > >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. > > And indeed it is. Python's advantages in terms of rapidity of development > have, thus far, made up the difference for me, but it is threatening to > become a close thing. This is a severe problem and something needs to be > done about it. Could you point out a few such programs that people on python-dev can look at? I think it would be useful to gather some data about the kind of migration pains real users are having. I believe Martin and others are trying to do the right thing. Real data is more likely to convince them than passionate arguments on python-dev. > >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? > > And, in fact, there is not even a majority. There is a *perception* of a > majority. There isn't even a *perception* of a majority of Python users, > but a perception of a majority of python-dev readers, who are almost by > definition less risk-averse when it comes to language change than anyone > else! I think you missed the point here. The hypothetical question was not about any particular majority, but rather that regardless of which group you poll, the majority decision may not be the right one. Even a majority of Twised users :-). Jeremy > If we actually care about majorities, let's set up a voting application and > allow Python users to vote on each and every feature, and publicize it each > time such a debate comes up. Here, I'll get it started: > http://jyte.com/cl/python-should-have-a-strict-backward-compatibility-policy-to-guide-its-development > > According to that highly scientific study, at this point in time, "Nobody > disagrees" :). (One in favor, zero against.) > > _______________________________________________ > 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/jeremy%40alum.mit.edu > > _______________________________________________ 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
