On Tue, 23 May 2017 at 03:13 Wolfgang Maier < wolfgang.ma...@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
