[EMAIL PROTECTED] schrieb:
> 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?
Yes. People are more likely to classify the file as "no extension",
which more likely meets the user's expectation. Also, it won't happen
that splitext gives an empty file name, which otherwise may cause crashes.
> It clearly isn't going to help any old code.
That's not at all clear. Instead, old code will suddenly work correctly
(in the user's point of view), where it before gave nonsensical results
(which users have likely ignored).
For example, from the standard library:
py> import pydoc
py> pydoc.importfile("/Users/loewis/.pythonrc")
<module '' from '/Users/loewis/.pythonrc'>
This is non-sensical: the module isn't an empty string. Instead, it
should be '.pythonrc' - just as it would be 'pythonrc' if the file
name was 'pythonrc'.
So old code in the standard library will be improved.
> 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.
Maybe you aren't grounded so much in Unix history. It really feels
wrong that a dotfile is considered as having an extension.
> 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.
All of these apply here.
> 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).
I disagree. The current behavior is incorrect (and always has been);
the new behavior is clearly correct.
Regards,
Martin
_______________________________________________
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
