On 6 April 2016 at 15:03, Guido van Rossum <gu...@python.org> wrote:
> On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> Option 4: define a rich-object-to-text path serialisation convention,
>
> Unfortunately that sounds like a classic "serious programming"
> solution (objects, abstractions, serialization, all big important
> words :-).
Yeah, my choice of phrasing made the idea sound more complicated than
it is. The actual change would be to add the following to some Python
standard library APIs that accept a filesystem path as an argument:
arg = getattr(arg, "path", arg)
and the C API based equivalent to some C modules.
(With the main bike-sheddable part being whether to use the generic
"path" or something more explicit like "__fspath__" for the property
name, since pathlib can readily support either/both of them, and
"__fspath__" would be in line with the "os.fsencode" and "os.fsdecode"
abbreviations)
The key goal of this approach would be to make it so that most third
party libraries would "just work" with path objects if they were
already using os.path and other standard library APIs for path
manipulation (rather than using string methods directly), while still
avoiding the type confusion that comes from inheriting directly from
str.
>From a testing perspective, it would arguably make sense to tackle it
as a separate "test_path_protocol" test case that checked pathlib
compatibility with the APIs of interest, simply to avoid adding a
pathlib dependency to all those module tests.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
