<html><body>On 10:18 pm, martin@v.loewis.de wrote:<br />>Phillip J. Eby schrieb:<br />>> At 10:01 PM 3/6/2007 +0100, Martin v. Löwis wrote:<br />>>> It's unfortunate, of course, that people apparently relied on<br />>>> this behavior<br />>><br />>> I was going to say it's the *documented* behavior, but I see that the<br />>> documentation is actually such that it could be interpreted either way.<br />>><br />>> However, since it's not documented more specifically, it seems perfectly<br />>> reasonable to rely on the implementation's behavior to resolve the ambiguity.<br /><br />Despite the generally quite good documentation, I've learned about how quite a lot of how the standard library works by messing around at the interactive interpreter.  This is one cost of the "incompatibility" - having to re-train developers who thought they knew how something worked, or are continuing to write new software while experimenting with older VMs.<br /><br />>Sure, it is an incompatible change, no doubt. However, incompatible<br />>changes are "ok" for feature releases (not so fo bugfix releases).<br /><br />Incompatible changes may be *acceptable* for feature releases, but that doesn't mean they are desirable.  The cost of incompatibility should be considered for every change.  This cost is particularly bad when the incompatibility is of the "silent breakage" variety - the change being discussed here would not be the sort of thing that one could, say, produce a warning about or gently deprecate; anything relying on the old behavior would suddenly be incorrect, and any software wishing to straddle the 2.5<->2.6 boundary would be better off just implementing their own splitext() than relying on the stdlib.<br /><br />>So this being an incompatible change alone is not a reason to reject<br />>the patch. Significant breakage in many applications might be, but<br />>I don't expect that for this change (which is really tiny).<br /><br />Software is a chaotic system.  The size of the change is unrelated to how badly it might break things.<br /><br />More to the point, we know the cost, what's the benefit?  Is there any sort of bug that it is likely to prevent in *new* code?  It clearly isn't going to help any old code.  It seems there are people who see it both ways, and I haven't seen anything compelling to indicate that either behavior is particularly less surprising in the edge case.<br /><br />In cases like this, historical context should be considered, even for a major overhaul like 3.0.  Of course, if the newly proposed semantics provided a solution to a real problem or common error, compatibility might be determined to be a less important issue.<br /><br />The use-cases being discussed here would be better served by having new APIs that do particular things and don't change existing semantics, though.  For example, a "guess_mime_type(path)" function which could examine a path and figure out its mime type based on its extension (among other things).<br /></body></html>