Josiah Carlson schrieb:
> Because we should refuse the temptation to guess, what about:
> Rename the posix splitext to X (for some X), and offer a function with
> identical functionality to the posix variant under win32, also available
> as X for that platform.
> Rename the (current) win32 splitext to Y (for some Y) and offer a
> function with identical functionality to the posix platform as name Y.
> Offer a new splitext that uses X on posix and Y on win32, but causes a
> DeprecationWarning with pointers to the two renamed functions that are
> available on both platforms.

See my comment to Andrew. This would cause severe harm: there are many
applications of splitext which work just fine and won't see any
behavior change; there are those which actually got fixed; and then
there are those that break. With the change, you are putting a burden
on all three cases, and more so, on the users of the software.

In addition, splitext should not be deprecated. It is a fine function,
and I really don't see a conceptual need for two versions of it: you
will only ever need the current one.

> For people who want the old platform-specific functionality in previous
> and subsequent Pythons, offer the ability to disable the
> DeprecationWarning via a module global; at least until the function is
> removed in some future Python, at which point path.splitext would cause
> an AttributeError .

That assumes there is a need for the old functionality. I really don't
see it (pje claimed he needed it once, but I remain unconvinced, not
having seen an actual fragment where the old behavior is helpful).

Python-Dev mailing list

Reply via email to