[Python-Dev] When should pathlib stop being provisional? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Apr 6 01:44:41 EDT 2016

On 6 April 2016 at 15:03, Guido van Rossum <guido at python.org> wrote:

On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan <ncoghlan at 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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list