Re: [Python-Dev] pathlib - current status of discussions

On 17 April 2016 at 04:47, Chris Barker - NOAA Federal wrote: >> On Apr 13, 2016, at 8:31 PM, Nick Coghlan wrote: >> class Special(bytes): def __fspath__(self): return 'str-val' obj = Special('bytes-val', 'utf8')

Re: [Python-Dev] pathlib - current status of discussions

> On Apr 13, 2016, at 8:31 PM, Nick Coghlan wrote: > >>> class Special(bytes): >>> def __fspath__(self): >>> return 'str-val' >>> obj = Special('bytes-val', 'utf8') >>> path_obj = fspath(obj, allow_bytes=True) >>> >>> With #2, path_obj == 'bytes-val'. With

Re: [Python-Dev] pathlib - current status of discussions

On 15 April 2016 at 00:01, Random832 wrote: > On Thu, Apr 14, 2016, at 09:50, Chris Angelico wrote: >> Adding integers and floats is considered "safe" because most people's >> use of floats completely compasses their use of ints. (You'll get >> OverflowError if it can't be

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016 at 9:35 PM, Random832 wrote: > On Thu, Apr 14, 2016, at 13:56, Koos Zevenhoven wrote: >> (1) Code that has access to pathname/filename data and has some level >> of control over what data type comes in. This code may for instance >> choose to deal with

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016, at 13:56, Koos Zevenhoven wrote: > (1) Code that has access to pathname/filename data and has some level > of control over what data type comes in. This code may for instance > choose to deal with either bytes or str > > (2) Code that takes the path or file name that it

Re: [Python-Dev] pathlib - current status of discussions

On 04/14/2016 10:22 AM, Paul Moore wrote: On 14 April 2016 at 17:46, Ethan Furman wrote: If you are not working at the bytes layer, you shouldn't be getting bytes objects because: - you specified str when asking for data from the OS, or - you transformed the incoming bytes from whatever

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016 at 7:46 PM, Ethan Furman wrote: > > What many folks seem to be missing is that *you* (generic you) have control > of your data. > > If you are not working at the bytes layer, you shouldn't be getting bytes > objects because: > > - you specified str when

Re: [Python-Dev] pathlib - current status of discussions

On 14 April 2016 at 17:46, Ethan Furman wrote: > On 04/14/2016 08:59 AM, Michael Mysinger via Python-Dev wrote: > >> I am saying that if os.path.join now accepts RichPath objects, and those >> objects can return either str or bytes, then its much harder to reason >> about >>

Re: [Python-Dev] pathlib - current status of discussions

On 04/14/2016 08:59 AM, Michael Mysinger via Python-Dev wrote: I am saying that if os.path.join now accepts RichPath objects, and those objects can return either str or bytes, then its much harder to reason about when I have all bytes or all strings. In essence, you will force me to pre- wrap

Re: [Python-Dev] pathlib - current status of discussions

On 04/14/2016 09:09 AM, Victor Stinner wrote: 2016-04-14 16:54 GMT+02:00 Ethan Furman: I consider that the final goal of the whole discussion is to support something like: path = os.path.join(pathlib_path, "str_path", direntry) (...) I expect that DirEntry.__fspath__ uses

Re: [Python-Dev] pathlib - current status of discussions

Donald Stufft stufft.io> writes: > > On Apr 14, 2016, at 11:59 AM, Michael Mysinger via Python-Dev python.org> wrote: > > > > In essence, you will force me to pre- > > wrap all RichPath objects in either os.fsencode(os.fspath(path)) or > > os.fsdecode(os.fspath(path)), just so I can reason

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016, at 12:05, Stephen J. Turnbull wrote: > Random832 writes: > > > And what such incompatibilities exist between bytes and str for the > > purpose of representing file paths? > > A plethora of encodings. Only one encoding, fsencode/fsdecode. All other encodings are not for

Re: [Python-Dev] pathlib - current status of discussions

> On Apr 14, 2016, at 11:59 AM, Michael Mysinger via Python-Dev > wrote: > > In essence, you will force me to pre- > wrap all RichPath objects in either os.fsencode(os.fspath(path)) or > os.fsdecode(os.fspath(path)), just so I can reason about the type. This is only

Re: [Python-Dev] pathlib - current status of discussions

2016-04-14 17:29 GMT+02:00 Ethan Furman : > Interoperability with other systems and/or libraries. If we use > surrogateescape to transform str to bytes, and the other side does not, we > no longer have a workable path. I guess that you mean a Python library? When you exchange

Re: [Python-Dev] pathlib - current status of discussions

2016-04-14 16:54 GMT+02:00 Ethan Furman : >> I consider that the final goal of the whole discussion is to support >> something like: >> >> path = os.path.join(pathlib_path, "str_path", direntry) >> >> (...) >> I expect that DirEntry.__fspath__ uses os.fsdecode() to return

Re: [Python-Dev] pathlib - current status of discussions

Random832 writes: > And what such incompatibilities exist between bytes and str for the > purpose of representing file paths? A plethora of encodings. > At the end of the day, there's exactly one answer to "what file on > disk this represents (or would represent if it existed)". Nope.

Re: [Python-Dev] pathlib - current status of discussions

Ethan Furman stoneleaf.us> writes: > On 04/14/2016 12:03 AM, Michael Mysinger via Python-Dev wrote: > > In particular, one RichPath > > class might return bytes and another str, or even worse the same class might > > sometimes return bytes and sometimes str. When will os.path.join blow up due

Re: [Python-Dev] pathlib - current status of discussions

On 04/14/2016 07:01 AM, Random832 wrote: On Thu, Apr 14, 2016, at 09:50, Chris Angelico wrote: Adding integers and floats is considered "safe" because most people's use of floats completely compasses their use of ints. (You'll get OverflowError if it can't be represented.) But float and Decimal

Re: [Python-Dev] pathlib - current status of discussions

On 04/14/2016 06:56 AM, Victor Stinner wrote: 2016-04-14 15:40 GMT+02:00 Nick Coghlan: >> Even earlier, Victor Stinner wrote: I consider that the final goal of the whole discussion is to support something like: path = os.path.join(pathlib_path, "str_path", direntry) That's not a *new*

Re: [Python-Dev] pathlib - current status of discussions

On 04/14/2016 05:16 AM, Victor Stinner wrote: I consider that the final goal of the whole discussion is to support something like: path = os.path.join(pathlib_path, "str_path", direntry) Even if direntry uses a bytes filename. I expect genericpath.join() to be patched to use os.fspath().

Re: [Python-Dev] pathlib - current status of discussions

On 04/14/2016 12:03 AM, Michael Mysinger via Python-Dev wrote: Brett Cannon writes: After playing with and considering the 4 possibilities, anything where __fspath__ can return bytes seems like insanity that flies in the face of everything Python 3 is trying to accomplish. In particular, one

Re: [Python-Dev] pathlib - current status of discussions

2016-04-14 15:40 GMT+02:00 Nick Coghlan : >> I consider that the final goal of the whole discussion is to support >> something like: >> >> path = os.path.join(pathlib_path, "str_path", direntry) > > That's not a *new* problem though, it already exists if you pass in a > mix

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016, at 09:50, Chris Angelico wrote: > Adding integers and floats is considered "safe" because most people's > use of floats completely compasses their use of ints. (You'll get > OverflowError if it can't be represented.) But float and Decimal are > considered "unsafe": > > >>>

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016, at 09:40, Nick Coghlan wrote: > That's not a *new* problem though, it already exists if you pass in a > mix of bytes and str: > > There's also already a solution (regardless of whether you want bytes > or str as the result), which is to explicitly coerce all the arguments >

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016 at 11:45 PM, Random832 wrote: > On Thu, Apr 14, 2016, at 09:40, Nick Coghlan wrote: >> That's not a *new* problem though, it already exists if you pass in a >> mix of bytes and str: >> >> There's also already a solution (regardless of whether you want

Re: [Python-Dev] pathlib - current status of discussions

On 14 April 2016 at 22:16, Victor Stinner wrote: > 2016-04-13 19:10 GMT+02:00 Brett Cannon : >> https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the >> four potential approaches implemented (although it doesn't follow the >>

Re: [Python-Dev] pathlib - current status of discussions

2016-04-13 19:10 GMT+02:00 Brett Cannon : > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the > four potential approaches implemented (although it doesn't follow the > "separate functions" approach some are proposing and instead goes with the >

Re: [Python-Dev] pathlib - current status of discussions

Brett Cannon python.org> writes: > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the four potential approaches implemented (although it doesn't follow the "separate functions" approach some are proposing and instead goes with the allow_bytes approach I originally

Re: [Python-Dev] pathlib - current status of discussions

On 14 April 2016 at 14:05, Random832 wrote: > On Wed, Apr 13, 2016, at 23:27, Nick Coghlan wrote: >> In this kind of case, inheritance tends to trump protocol. For >> example, int subclasses can't override operator.index: > ... >> The reasons for that behaviour are more

Re: [Python-Dev] pathlib - current status of discussions

On Wed, Apr 13, 2016, at 23:27, Nick Coghlan wrote: > In this kind of case, inheritance tends to trump protocol. For > example, int subclasses can't override operator.index: ... > The reasons for that behaviour are more pragmatic than philosophical: > builtins and their subclasses are extensively

Re: [Python-Dev] pathlib - current status of discussions

On 14 April 2016 at 13:14, Ethan Furman wrote: > On 04/13/2016 07:57 PM, Nikolaus Rath wrote: >> Either I haven't understood your answer, or you haven't understood my >> question. I'm concerned about this case: >> >>class Special(bytes): >>def __fspath__(self): >>

Re: [Python-Dev] pathlib - current status of discussions

On 04/13/2016 07:57 PM, Nikolaus Rath wrote: On Apr 13 2016, Ethan Furman wrote: On 04/13/2016 03:45 PM, Nikolaus Rath wrote: When passing an object that is of type str and has a __fspath__ attribute, all approaches return the value of __fspath__(). However, when passing something of type

Re: [Python-Dev] pathlib - current status of discussions

On Apr 13 2016, Ethan Furman wrote: > On 04/13/2016 03:45 PM, Nikolaus Rath wrote: > >> When passing an object that is of type str and has a __fspath__ >> attribute, all approaches return the value of __fspath__(). >> >> However, when passing something of type bytes, the

Re: [Python-Dev] pathlib - current status of discussions

On Apr 13, 2016 19:06, Brett Cannon wrote: > On Wed, 13 Apr 2016 at 15:46 Nikolaus Rath wrote: >> When passing an object that is of type str and has a __fspath__ >> attribute, all approaches return the value of __fspath__(). >> >> However, when passing

Re: [Python-Dev] pathlib - current status of discussions

On Apr 13, 2016 20:06, Chris Barker wrote: > > In this case, I don't know that we need to be tolerant of buggy __fspathname__() implementations -- they should be tested outside these checks, and not be buggy. So a buggy implementation may raise and may be ignored,

Re: [Python-Dev] pathlib - current status of discussions

On 04/13/2016 05:06 PM, Chris Barker wrote: In this case, I don't know that we need to be tolerant of buggy __fspathname__() implementations -- they should be tested outside these checks, and not be buggy. So a buggy implementation may raise and may be ignored, depending on what Exception the

Re: [Python-Dev] pathlib - current status of discussions

On Wed, Apr 13, 2016 at 1:47 PM, Random832 wrote: > On Wed, Apr 13, 2016, at 16:39, Chris Barker wrote: > > so are we worried that __fspath__ will exist and be callable, but might > > raise an AttributeError somewhere inside itself? if so isn't it broken > > anyway, so

Re: [Python-Dev] pathlib - current status of discussions

On Wed, 13 Apr 2016 at 15:20 Victor Stinner wrote: > Oh, since others voted, I will also vote and explain my vote. > > I like choice 1, str only, because it's very well defined. In Python > 3, Unicode is simply the native type for text. It's accepted by almost > all

Re: [Python-Dev] pathlib - current status of discussions

On Wed, 13 Apr 2016 at 15:46 Nikolaus Rath wrote: > On Apr 13 2016, Brett Cannon wrote: > > On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < > > python-dev@python.org> wrote: > > > >> Ethan Furman stoneleaf.us> writes: > >> > >> > Do we allow

Re: [Python-Dev] pathlib - current status of discussions

On 04/13/2016 03:45 PM, Nikolaus Rath wrote: When passing an object that is of type str and has a __fspath__ attribute, all approaches return the value of __fspath__(). However, when passing something of type bytes, the second approach returns the object, while the third returns the value of

Re: [Python-Dev] pathlib - current status of discussions

On Apr 13 2016, Brett Cannon wrote: > On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < > python-dev@python.org> wrote: > >> Ethan Furman stoneleaf.us> writes: >> >> > Do we allow bytes to be returned from os.fspath()? If yes, then do we >> > allow bytes from

Re: [Python-Dev] pathlib - current status of discussions

Oh, since others voted, I will also vote and explain my vote. I like choice 1, str only, because it's very well defined. In Python 3, Unicode is simply the native type for text. It's accepted by almost all functions. In other emails, I also explained that Unicode is fine to store undecodable

Re: [Python-Dev] pathlib - current status of discussions

On Wed, Apr 13, 2016, at 16:39, Chris Barker wrote: > so are we worried that __fspath__ will exist and be callable, but might > raise an AttributeError somewhere inside itself? if so isn't it broken > anyway, so should it be ignored? Well, if you're going to say "ignore the protocol because it's

Re: [Python-Dev] pathlib - current status of discussions

On Wed, 13 Apr 2016 at 13:40 Chris Barker wrote: > so are we worried that __fspath__ will exist and be callable, but might > raise an AttributeError somewhere inside itself? if so isn't it broken > anyway, so should it be ignored? > It should propagate instead of

Re: [Python-Dev] pathlib - current status of discussions

so are we worried that __fspath__ will exist and be callable, but might raise an AttributeError somewhere inside itself? if so isn't it broken anyway, so should it be ignored? and I know it's asking poermission rather than forgiveness, but what's wrong with: if hasattr(path, "__fspath__"):

Re: [Python-Dev] pathlib - current status of discussions

On Wed, 13 Apr 2016 at 12:39 Fred Drake wrote: > On Wed, Apr 13, 2016 at 3:24 PM, Chris Angelico wrote: > > Is that the intention, or should the exception catching be narrower? I > > know it's clunky to write it in Python, but AIUI it's less so in C: > > > >

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016 at 5:46 AM, Random832 wrote: > On Wed, Apr 13, 2016, at 15:24, Chris Angelico wrote: >> Is that the intention, or should the exception catching be narrower? I >> know it's clunky to write it in Python, but AIUI it's less so in C: > > How is it less so

Re: [Python-Dev] pathlib - current status of discussions

On Wed, Apr 13, 2016, at 15:24, Chris Angelico wrote: > Is that the intention, or should the exception catching be narrower? I > know it's clunky to write it in Python, but AIUI it's less so in C: How is it less so in C? You lose the ability to PyObject_CallMethod.

Re: [Python-Dev] pathlib - current status of discussions

On 4/13/2016 13:49, Ethan Furman wrote: Number 3: it allows bytes, but only when told it's okay to do so. Having code get a bytes object when one is not expected is not a headache we need to inflict on anyone. This is an artifact of the other needless restrictions I said I wouldn't rant

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016 at 5:30 AM, Brett Cannon wrote: > > > On Wed, 13 Apr 2016 at 12:25 Chris Angelico wrote: >> >> On Thu, Apr 14, 2016 at 3:10 AM, Brett Cannon wrote: >> >

Re: [Python-Dev] pathlib - current status of discussions

On Wed, Apr 13, 2016 at 3:24 PM, Chris Angelico wrote: > Is that the intention, or should the exception catching be narrower? I > know it's clunky to write it in Python, but AIUI it's less so in C: > > try: > callme = path.__fspath__ > except AttributeError: > pass >

Re: [Python-Dev] pathlib - current status of discussions

On Wed, 13 Apr 2016 at 12:25 Chris Angelico wrote: > On Thu, Apr 14, 2016 at 3:10 AM, Brett Cannon wrote: > > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 > has the > > four potential approaches implemented (although it doesn't follow

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016 at 3:10 AM, Brett Cannon wrote: > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the > four potential approaches implemented (although it doesn't follow the > "separate functions" approach some are proposing and instead goes with

Re: [Python-Dev] pathlib - current status of discussions

Brett Cannon python.org> writes: > In the spirit of Python 3 I feel like bytes might not be needed in practice, > but something like this with defaults of False will allow people to easily > test all the various options. > > > >

Re: [Python-Dev] pathlib - current status of discussions

On 04/13/2016 10:22 AM, Alexander Walters wrote: On 4/13/2016 13:10, Brett Cannon wrote: https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the four potential approaches implemented (although it doesn't follow the "separate functions" approach some are proposing and

Re: [Python-Dev] pathlib - current status of discussions

On 4/13/2016 13:10, Brett Cannon wrote: https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the four potential approaches implemented (although it doesn't follow the "separate functions" approach some are proposing and instead goes with the allow_bytes approach I

Re: [Python-Dev] pathlib - current status of discussions

On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < python-dev@python.org> wrote: > Ethan Furman stoneleaf.us> writes: > > > Do we allow bytes to be returned from os.fspath()? If yes, then do we > > allow bytes from __fspath__()? > > De-lurking. Especially since the ultimate goal is

Re: [Python-Dev] pathlib - current status of discussions

On 13 April 2016 at 02:19, Chris Barker wrote: > So: why use strings as the lingua franca of paths? i.e. the basis of the > path protocol. maybe we should support only two path representations: > > 1) A "proper" path object -- i.e. pathlib.Path or anything else that >

Re: [Python-Dev] pathlib - current status of discussions

Ethan Furman stoneleaf.us> writes: > Do we allow bytes to be returned from os.fspath()? If yes, then do we > allow bytes from __fspath__()? De-lurking. Especially since the ultimate goal is better interoperability, I feel like an implementation that people can play with would help guide the

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016 at 6:52 PM, Stephen J. Turnbull wrote: > > (A) Why does anybody need bytes out of a pathlib.Path (or other > __fspath__-toting, higher-level API) *inside* the boundary? Note > that the APIs in os (etc) *don't need* bytes because they are >

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016 at 9:32 AM, Koos Zevenhoven wrote: > > 1) A "proper" path object -- i.e. pathlib.Path or anything else that > > supports the path protocol. > > > > 2) the bytes that the OS actually needs. > > > > You do have a point there. But since bytes pathnames are

Re: [Python-Dev] pathlib - current status of discussions

On 04/12/2016 09:26 AM, Koos Zevenhoven wrote: So I'm, once again, posing this question (that I don't think got any reactions previously): Is there a significant audience for this new function, or is it enough to keep it a private function for the stdlib to use? Quite frankly, I expect the

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016 at 7:19 PM, Chris Barker wrote: > > One more though came up just now: there are different level sof abstractions > and representations for paths. We don't want to make Path a subclass of > string, because Path is supposed to be a higher level

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016 at 11:56 AM, Nick Coghlan wrote: > One possible way to address this concern would be to have the > underlying protocol be bytes/str (since boundary code frequently needs > to handle the paths-are-bytes assumption in POSIX), but offer an > "os.fspathname"

Re: [Python-Dev] pathlib - current status of discussions

On Mon, Apr 11, 2016 at 10:40 PM, Greg Ewing wrote: > > So the ONLY thing >> you should do with it is pass it along to another low level system >> call. >> > > Not quite -- you can separate it into components and > work with them. Essentially the same set of

Re: [Python-Dev] pathlib - current status of discussions

On 04/11/2016 02:58 PM, Ethan Furman wrote: Sticking points: --- Do we allow bytes to be returned from os.fspath()? If yes, then do we allow bytes from __fspath__()? On 04/11/2016 10:28 PM, Stephen J. Turnbull wrote: > In text applications, "bytes as carcinogen" is an apt

Re: [Python-Dev] pathlib - current status of discussions

Nick Coghlan writes: > One possible way to address this concern would be to have the > underlying protocol be bytes/str (since boundary code frequently > needs to handle the paths-are-bytes assumption in POSIX), What "needs"? As has been pointed out several times, with PEP 383 you can deal

Re: [Python-Dev] pathlib - current status of discussions

Sorry for disturbing this thread's harmony. On 12.04.2016 08:00, Ethan Furman wrote: On 04/11/2016 10:14 PM, Chris Barker - NOAA Federal wrote: Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Because

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016 at 7:58 AM, Ethan Furman wrote: > Sticking points: > --- > > Do we allow bytes to be returned from os.fspath()? If yes, then do we allow > bytes from __fspath__()? > I would say No and No, on the basis that it's *far* easier to widen their

Re: [Python-Dev] pathlib - current status of discussions

On 12 April 2016 at 15:28, Stephen J. Turnbull wrote: > Donald Stufft writes: > > > I think yes and yes [__fspath__ and fspath should be allowed to > > handle bytes, otherwise] it seems like making it needlessly harder > > to deal with a bytes path > > It's not needless.

Re: [Python-Dev] pathlib - current status of discussions

On 12 April 2016 at 06:28, Stephen J. Turnbull wrote: > Donald Stufft writes: > > > I think yes and yes [__fspath__ and fspath should be allowed to > > handle bytes, otherwise] it seems like making it needlessly harder > > to deal with a bytes path > > It's not needless.

Re: [Python-Dev] pathlib - current status of discussions

On 04/11/2016 10:14 PM, Chris Barker - NOAA Federal wrote: Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Because library XYZ that takes a path and wants to open it shouldn't have to care whether that path

Re: [Python-Dev] pathlib - current status of discussions

Chris Barker - NOAA Federal wrote: Why in the world do the os.path functions need to work with Path objects? So that applications using path objects can pass them to library code that uses os.path to manipulate them. I'm confused about what a bytes path IS -- is it encoded? It's a

Re: [Python-Dev] pathlib - current status of discussions

Donald Stufft writes: > I think yes and yes [__fspath__ and fspath should be allowed to > handle bytes, otherwise] it seems like making it needlessly harder > to deal with a bytes path It's not needless. This kind of polymorphism makes it hard to review code locally. Once bytes get a

Re: [Python-Dev] pathlib - current status of discussions

> with the > rationale being the one someone mentioned regarding ease-of-use in > os.path. > > Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Thus all started with the goal of using Path objects in the stdlib,

Re: [Python-Dev] pathlib - current status of discussions

On 12 April 2016 at 13:45, Nick Coghlan wrote: > Consider os.path.join: with a permissive os.fspath, the necessary > update should just be to introduce "map(os.fspath, args)" (or its C > equivalent), and then continue with the existing bytes vs str handling > logic. That does

Re: [Python-Dev] pathlib - current status of discussions

On 12 April 2016 at 07:58, Ethan Furman wrote: > Sticking points: > --- > > Do we allow bytes to be returned from os.fspath()? If yes, then do we allow > bytes from __fspath__()? I've come around to the point of view that allowing both str and bytes-like objects

Re: [Python-Dev] pathlib - current status of discussions

> On Apr 11, 2016, at 5:58 PM, Ethan Furman wrote: > > name: > > > We are down to two choices: > > - __fspath__, or > - __fspathname__ > > The final choice I suspect will be affected by the choice to allow (or not) > bytes. +1 on __fspath__, -0 on __fspathname__