On 10:18 pm, [EMAIL PROTECTED] 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).
_______________________________________________
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
