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). Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4