On Wed, 13 Apr 2016 at 09:52 Random832 <random...@fastmail.com> wrote:
> On Wed, Apr 13, 2016, at 11:28, Ethan Furman wrote: > > On 04/13/2016 08:17 AM, Random832 wrote: > > > On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote: > > > > >> I'd expect the main consumers to be os and os.path, and would honestly > > >> be surprised if we needed many explicit invocations above that layer, > > >> other than in pathlib itself. > > > > > > I made a toy implementation to try this out, and making os.open support > > > it does not get you builtin open "for free" as I had suspected; builtin > > > open has its own type checks in _iomodule.c. > > > > Yup, it will take some effort to make this work. > > A corner case just occurred to me... > > For functions that will continue to accept str/bytes (and functions that > accept some other type such as Number or file-like objects), what should > be done with an object that is one of these, *and* has an __fspath__ > method, *and* this method returns a value other than the object's own > value? Basically, should the protocol check be done unconditionally > (before attempting to use the argument as a string) or only if the > argument is not a string (there's an efficiency argument for this). Or > should it be left "unspecified", with the understanding that such > objects are badly behaved and may not be handled consistently across > different functions / python implementations / cpython versions? > > Also, should the os.fspath (or whatever we call it) function itself > accept str/bytes, even if these are not going to implement the protocol? > All of this is demonstrated in https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 by the various possibilities. In the end it's not a corner case because the definition of __fspath__ will be such that there's no ambiguity in what os.fspath() will accept and what __fspath__ can return and the code will be written to conform to what the PEP dictates (IOW I'm aware that this needs to be considered in the implementation :) .
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
