[Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

Nick Coghlan ncoghlan at gmail.com
Fri May 5 00:46:19 EDT 2017


On 4 May 2017 at 08:25, Victor Stinner <victor.stinner at gmail.com> wrote:
> If you start to backport support for the fspath protocol, be prepared
> to have to backport it *many* places. I expect that slowly in the near
> future, many functions will be patched to support the fspath protocol.
>
> I suggest to only do that in master. It's not that hard to cast
> manually to a string: it's just str(path), no?

For 3.6+, "os.fspath(path)" would be more robust - unlike str(), it
will still error out immediately if you pass it something completely
inappropriate.

That improved casting mechanism and the implicit support in the low
level APIs is the main benefit I see in PEP 519, and if we were
talking about an os module API that was missing os.path support, I'd
be more likely to be on the "it's a bug" side of things.

It's only higher level APIs like shutil that I put into the same
category as third party libraries for now: Python 3.6 users shouldn't
expect implicit use of the fspath protocol to be universal yet, so
they may still need some explicit calls to os.fspath() in their own
code to get different APIs to work well together.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list