[Python-Dev] When should pathlib stop being provisional?
Nick Coghlan
ncoghlan at gmail.com
Wed Apr 6 00:49:33 EDT 2016
More information about the Python-Dev mailing list
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 ]
More information about the Python-Dev mailing list