On Thu, Mar 15, 2007, "Martin v. L??wis" wrote: > > I'm not quite sure what "it" is, here. If "it" is that there be no > incompatible changes in Python: this is not policy, and not even > consensus. Instead, policy (as enforced by the release manager), and > consensus is that bug fix releases (2.x.y) must not show incompatible > behavior. For feature releases (2.x), incompatible behavior is > acceptable (at least this is what I thought consensus is, but > apparently I'm wrong).
You are not wrong on one level, but you are wrong on another: if a change that may not be a bugfix gets any legitimate objections, the bar for the change becomes much higher, and that goes double or triple if the change will result in silent breakage of existing programs. If this discussion had occurred three years ago, I would be more inclined toward your position, but right now we have another outlet for silent incompatible changes: Python 3.0. I'm not opposed to extending the splitext API in 2.6 as one solution for this problem, but I still believe that pushing the change to 3.0 is best (assuming we make the change at all, because the people arguing against any change do have a point about Windows -- and in the end, Windows is the largest CONSUMER of Python programs). I do agree with the surprise expressed about your claim that extending the API isn't backward compatible -- the point is that any code using pre-2.6 splitext() API will work the same across 2.x regardless of whether the code is written after 2.6 is released. Of course anyone who uses the extended API is backward incompatible, but that's a much different kind of problem. Because this discussion has gone on so long, it seems to me that a micro-PEP would be good for summarizing. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM _______________________________________________ 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