[Python-ideas] tweaking the file system path protocol

Brett Cannon brett at python.org
Tue May 23 13:04:29 EDT 2017


On Tue, 23 May 2017 at 03:13 Wolfgang Maier <
wolfgang.maier at biologie.uni-freiburg.de> wrote:

> What do you think of this idea for a slight modification to os.fspath:
> the current version checks whether its arg is an instance of str, bytes
> or any subclass and, if so, returns the arg unchanged. In all other
> cases it tries to call the type's __fspath__ method to see if it can get
> str, bytes, or a subclass thereof this way.
>
> My proposal is to change this to:
> 1) check whether the type of the argument is str or bytes *exactly*; if
> so, return the argument unchanged
> 2) check wether __fspath__ can be called on the type and returns an
> instance of str, bytes, or any subclass (just like in the current version)
> 3) check whether the type is a subclass of str or bytes and, if so,
> return it unchanged
>
> This would have the following implications:
> a) it would speed up the very common case when the arg is either a str
> or a bytes instance exactly
> b) user-defined classes that inherit from str or bytes could control
> their path representation just like any other class
> c) subclasses of str/bytes that don't define __fspath__ would still work
> like they do now, but their processing would be slower
> d) subclasses of str/bytes that accidentally define a __fspath__ method
> would change their behavior
>
> I think cases c) and d) could be sufficiently rare that the pros
> outweigh the cons?
>

What exactly is the performance issue you are having that is leading to
this proposal? I ask because b) and d) change semantics and so it's not a
small thing to make this change at this point since Python 3.6 has been
released. So unless there's a major performance impact I'm reluctant to
want to change it at this point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170523/1919c803/attachment.html>


More information about the Python-ideas mailing list