[Python-Dev] When should pathlib stop being provisional? (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Wed Apr 6 00:49:33 EDT 2016
- Previous message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Next message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 6 April 2016 at 13:06, Alexander Walters <tritium-list at sdamon.com> wrote:
I think the naysayers would be satisfied with an object that... while not str or bytes or a derived class of either... acted like str when it had to. Is that possible without deriving from str or bytes?
Only if the consuming code explicitly casts with "str()", and that's too permissive for most use cases (since str and the repr fallback are completely inappropriate as a "convert to a text representation of a filesystem path" command).
A "text" protocol for non-lossy conversions to str would arguably be feasible, but its scope goes way beyond what's needed for a "rich path object" conversion protocol.
Implementing that model in the general case would require something more akin to https://www.python.org/dev/peps/pep-0357/, which added index as a guaranteed-non-lossy conversion from other types to a builtin integer, allowing non-builtin integers to accepted for things like slicing and sequence repetition, without inadvertently also accepting non-integral types like builtin floats.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Next message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]