Andrew Bennetts <andrew-pythondev at puzzling.org> wrote: > Glyph's proposing that rather than risk breaking existing code (and in the worst > possible way: silently, giving wrong answers rather than exceptions), we examine > what benefits changing splitext would bring, and see if there's a way to get > those benefits without that risk. I don't think that's an idea to dismiss out > of hand. 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. 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 . - Josiah
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