[Python-Dev] splitext('.cshrc')

[glyph at divmod.com]

On 10:18 pm, martin at v.loewis.de wrote:
>Phillip J. Eby schrieb:
>>At 10:01 PM 3/6/2007 +0100, Martin v. Löwis wrote:
>>>It's unfortunate, of course, that people apparently relied on
>>>this behavior
>>
>>I was going to say it's the *documented* behavior, but I see that the
>>documentation is actually such that it could be interpreted either 
>>way.
>>
>>However, since it's not documented more specifically, it seems 
>>perfectly
>>reasonable to rely on the implementation's behavior to resolve the 
>>ambiguity.

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.
>Sure, it is an incompatible change, no doubt. However, incompatible
>changes are "ok" for feature releases (not so fo bugfix releases).

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.
>So this being an incompatible change alone is not a reason to reject
>the patch. Significant breakage in many applications might be, but
>I don't expect that for this change (which is really tiny).

Software is a chaotic system.  The size of the change is unrelated to 
how badly it might break things.

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.

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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070306/dab58ede/attachment.html