[Python-ideas] tweaking the file system path protocol
Guido van Rossum
guido at python.org
Tue May 23 13:49:30 EDT 2017
I see no future for this proposal. Sorry Wolfgang! For future reference,
the proposal was especially weak because it gave no concrete examples of
code that was inconvenienced in any way by the current behavior. (And the
performance hack of checking for exact str/bytes can be made without
changing the semantics.)
On Tue, May 23, 2017 at 10:04 AM, Brett Cannon <brett at python.org> wrote:
>
>
> 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.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
--
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170523/77e63876/attachment.html>
More information about the Python-ideas
mailing list