Re: [Python-Dev] proposed os.fspath() change

On Wed, Jun 15, 2016 at 11:00 PM, Ethan Furman wrote: > On 06/15/2016 12:24 PM, Koos Zevenhoven wrote: >> >> And the other question could be turned into whether to make str and >> bytes also PathLike in __subclasshook__. > > No, for two reasons. > > - most str's and bytes' are

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 12:24 PM, Koos Zevenhoven wrote: On Wed, Jun 15, 2016 at 10:15 PM, Brett Cannon wrote: ABCs like os.PathLike can override __subclasshook__ so that registration isn't required (see https://hg.python.org/cpython/file/default/Lib/os.py#l1136). So registration is definitely good to

Re: [Python-Dev] proposed os.fspath() change

PEP 519 updated: https://hg.python.org/peps/rev/92feff129ee4 On Wed, 15 Jun 2016 at 11:44 Brett Cannon wrote: > On Wed, 15 Jun 2016 at 11:39 Guido van Rossum wrote: > >> OK, so let's add a check on the return of __fspath__() and keep the check >> on

Re: [Python-Dev] proposed os.fspath() change

On Wed, Jun 15, 2016 at 10:15 PM, Brett Cannon wrote: > > > On Wed, 15 Jun 2016 at 12:12 Koos Zevenhoven wrote: >> >> >> if isinstance(filename, os.PathLike): >> >> By the way, regarding the line of code above, is there a convention >> regarding whether

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 12:10 PM, Koos Zevenhoven wrote: if isinstance(filename, os.PathLike): By the way, regarding the line of code above, is there a convention regarding whether implementing some protocol/interface requires registering with (or inheriting from) the appropriate ABC for it to work

Re: [Python-Dev] proposed os.fspath() change

On Wed, 15 Jun 2016 at 12:12 Koos Zevenhoven wrote: > >> if isinstance(filename, os.PathLike): > > By the way, regarding the line of code above, is there a convention > regarding whether implementing some protocol/interface requires > registering with (or inheriting from)

Re: [Python-Dev] proposed os.fspath() change

>> if isinstance(filename, os.PathLike): By the way, regarding the line of code above, is there a convention regarding whether implementing some protocol/interface requires registering with (or inheriting from) the appropriate ABC for it to work in all situations. IOW, in this case, is it

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 11:44 AM, Brett Cannon wrote: On Wed, 15 Jun 2016 at 11:39 Guido van Rossum wrote: OK, so let's add a check on the return of __fspath__() and keep the check on path-like or string/bytes. I'll update the PEP. Ethan, do you want to leave a note on the os.fspath() issue to

Re: [Python-Dev] proposed os.fspath() change

On Wed, Jun 15, 2016 at 9:29 PM, Nick Coghlan wrote: > On 15 June 2016 at 10:59, Brett Cannon wrote: >> >> >> On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: >>> >>> These are really two separate proposals. >>> >>> I'm okay with

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 10:59 AM, Brett Cannon wrote: On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: These are really two separate proposals. I'm okay with checking the return value of calling obj.__fspath__; that's an error in the object anyways, and it doesn't matter much whether we do this or

Re: [Python-Dev] proposed os.fspath() change

OK, so let's add a check on the return of __fspath__() and keep the check on path-like or string/bytes. --Guido (mobile) On Jun 15, 2016 11:29 AM, "Nick Coghlan" wrote: > On 15 June 2016 at 10:59, Brett Cannon wrote: > > > > > > On Wed, 15 Jun 2016 at

Re: [Python-Dev] proposed os.fspath() change

On Wed, 15 Jun 2016 at 11:39 Guido van Rossum wrote: > OK, so let's add a check on the return of __fspath__() and keep the check > on path-like or string/bytes. > I'll update the PEP. Ethan, do you want to leave a note on the os.fspath() issue to update the code and go

Re: [Python-Dev] proposed os.fspath() change

On 15 June 2016 at 10:59, Brett Cannon wrote: > > > On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: >> >> These are really two separate proposals. >> >> I'm okay with checking the return value of calling obj.__fspath__; that's >> an error in the object

Re: [Python-Dev] proposed os.fspath() change

My proposal at the point of the first PEP draft solved both of these issues. That version of the fspath function passed anything right through that was an instance of the keyword-only `type_constraint`. If not, it would ask __fspath__, and before returning the result, it would check that

Re: [Python-Dev] proposed os.fspath() change

On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: > These are really two separate proposals. > > I'm okay with checking the return value of calling obj.__fspath__; that's > an error in the object anyways, and it doesn't matter much whether we do > this or not (though when

Re: [Python-Dev] proposed os.fspath() change

These are really two separate proposals. I'm okay with checking the return value of calling obj.__fspath__; that's an error in the object anyways, and it doesn't matter much whether we do this or not (though when approving the PEP I considered this and decided not to insert a check for this). But

[Python-Dev] proposed os.fspath() change

I would like to make a change to os.fspath(). Specifically, os.fspath() currently raises an exception if something besides str, bytes, or os.PathLike is passed in, but makes no checks if an os.PathLike object returns something besides a str or bytes. I would like to change that to the opposite: