Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 20 April 2016 at 13:16, Stephen J. Turnbull wrote: > It's people who live in monolingual mono-encoding environments who > will be using bytes successfully, and be resistent to costly changes > that don't make their lives better. But the bytes vs. text cost is > inherent

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 20 April 2016 at 13:16, Stephen J. Turnbull wrote: > What's left is DirEntry (and perhaps other producers of byte-oriented > objects in os and os.path). If they're currently using DirEntry, > they're currently accessing .path. Surely bytes users can continue > doing

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 20, 2016 at 6:16 AM, Stephen J. Turnbull wrote: > > (1) some really attractive producer of pathlib.Paths will be > published, and > Yes, pathlib is str-only, so this sounds just right. > (2) people will want to plug that producer into their bytes paths >

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 20, 2016 at 6:11 AM, Stephen J. Turnbull wrote: > Koos Zevenhoven writes: > > On Tue, Apr 19, 2016 at 2:55 PM, Stephen J. Turnbull > wrote: > > > > > > AFAICS bytes return from __fspath__ is just YAGNI. Show me something > > > that

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Eric Snow writes: > On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon wrote: > > Ah, but you see that doesn't make porting easy. > Perhaps I missed previous discussion on the point, but why not support > both __fspath__() -> str and __fssyspath__() -> bytes? That's fine by

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 20, 2016 at 1:16 PM, Stephen J. Turnbull wrote: > Brett Cannon writes: > > > Now if you can convince me that the use of bytes paths is very > > minimal > > I doubt that I can do that, because all that Python 2 code is > effectively bytes. To the extent that

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Nick Coghlan writes: > The gist of the motivation for bytes/str polymorphism here is similar to > that for restoring __mod__ polymorphism in > https://www.python.org/dev/peps/pep-0461/: I don't think it is, actually. Filenames off the wire cannot be relied on to be in the local file system

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Brett Cannon writes: > Now if you can convince me that the use of bytes paths is very > minimal I doubt that I can do that, because all that Python 2 code is effectively bytes. To the extent that people are just passing it into their bytes-domain code and it works for them, they probably

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Koos Zevenhoven writes: > On Tue, Apr 19, 2016 at 2:55 PM, Stephen J. Turnbull > wrote: > > > > AFAICS bytes return from __fspath__ is just YAGNI. Show me something > > that actually wants it. > > It might be, May I take that as meaning you just jumped to the

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, 19 Apr 2016 at 15:22 Eric Snow wrote: > On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon wrote: > > Ah, but you see that doesn't make porting easy. If I have a bunch of > > path-manipulating code using os.path already and I want to add

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon wrote: > Ah, but you see that doesn't make porting easy. If I have a bunch of > path-manipulating code using os.path already and I want to add support for > pathlib I can either (a) rewrite all of that path-manipulating code to work

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, 19 Apr 2016 at 04:46 Stephen J. Turnbull wrote: > Brett Cannon writes: > > On Mon, 18 Apr 2016 at 12:26 Stephen J. Turnbull > wrote: > > > Well, it makes *your* head hurt; > > It doesn't, because I have a different (and IMHO better) model. I

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 19 April 2016 at 21:55, Stephen J. Turnbull wrote: > I really want to know. I'm not 100% sure that's the right way to go, > mostly because Nick and Brett are signed up for polymorphism. But I > sure haven't seen any explicit arguments for polymorphism, though I've >

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, Apr 19, 2016 at 2:55 PM, Stephen J. Turnbull wrote: > > AFAICS bytes return from __fspath__ is just YAGNI. Show me something > that actually wants it. It might be, but as long as bytes paths are supported polymorphicly all over the stdlib, we won't get rid of

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman writes: > On 04/18/2016 12:25 PM, Stephen J. Turnbull wrote: > > Koos Zevenhoven writes: > > >> After all, we want something that's *almost* exclusively str. > > > > But we don't want that, AFAICT. Some clearly want this API to be > > unbiased against bytes in the same way

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Brett Cannon writes: > On Mon, 18 Apr 2016 at 12:26 Stephen J. Turnbull wrote: > Well, it makes *your* head hurt; It doesn't, because I have a different (and IMHO better) model. I can interpret yours without pain by comparing to that. > By providing os.fspath() I can

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Apr 18, 2016 3:19 PM, "Ethan Furman" wrote: > > On 04/18/2016 12:54 PM, Wes Turner wrote: > >> Don't we *have* to always support bytes because other programs can >> create filenames containing bytes? > > > Yes, but not every function has to support bytes. Because there's

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/18/2016 12:26 PM, Stephen J. Turnbull wrote: I haven't looked at Antipathy, but I would guess from Ethan's promotion of bytes paths and concern with efficiency that "bytes antipaths" do *not* "go through" str to get to bytes, they already are bytes (in the sense of class inheritance).

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/18/2016 02:58 PM, Koos Zevenhoven wrote: It's a matter of documentation whether it "supports" bytes or not. In fact, that function (assuming the name os.fspath) could now even be documented to support this: patharg = os.fspath(patharg, output_types = (str, pathlib.PurePath)) # :-)

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 18, 2016 at 5:03 PM, Ethan Furman wrote: > On 04/18/2016 12:41 AM, Nick Coghlan wrote: > >> Given the variant you [Koos] suggested, what if we defined the API >> semantics >> like this: >> >> # Offer the simplest possible API as the public vesion >> def

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 18 Apr 2016 at 12:26 Stephen J. Turnbull wrote: > Brett Cannon writes: > > > If we continue with the "str is an encoding of file paths", > > It's not. It's a representation, but not an encoding. In Python 3, > encoding means a representation of a character string

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/18/2016 12:54 PM, Wes Turner wrote: Don't we *have* to always support bytes because other programs can create filenames containing bytes? Yes, but not every function has to support bytes. -- ~Ethan~ ___ Python-Dev mailing list

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Apr 18, 2016 2:50 PM, "Ethan Furman" wrote: > > On 04/18/2016 12:25 PM, Stephen J. Turnbull wrote: > >> Koos Zevenhoven writes: > > >>> After all, we want something that's *almost* exclusively str. >> >> >> But we don't want that, AFAICT. Some clearly want this API to be

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/18/2016 12:25 PM, Stephen J. Turnbull wrote: Koos Zevenhoven writes: After all, we want something that's *almost* exclusively str. But we don't want that, AFAICT. Some clearly want this API to be unbiased against bytes in the same way the os APIs are unbiased[2], because that's what

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 18, 2016, at 15:26, Stephen J. Turnbull wrote: > in > particular it is not true for DirEntry (which is a "enhanced > degenerate" path containing only one path segment but also other > useful information abot the filesystem object addressed) DirEntry contains multiple path segments -

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Brett Cannon writes: > If we continue with the "str is an encoding of file paths", It's not. It's a representation, but not an encoding. In Python 3, encoding means a representation of a character string using bytes. It's using "encoding" generically for "representation" that makes your head

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

I don't disagree with the basic analysis, but there are a number of issues with motivational statements. Koos Zevenhoven writes: > (B) "str-based only" > *Accept*: str, provided via __fspath__ as well as plain str. > *Return*: str. > *Audience*: relatively low-level code that works

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Sun, 17 Apr 2016 at 06:59 Koos Zevenhoven wrote: > On Sun, Apr 17, 2016 at 11:03 AM, Stephen J. Turnbull > wrote: > > Nick Coghlan writes: > > > > > str and bytes aren't going to implement __fspath__ (since they're > > > only *sometimes* path

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/18/2016 12:41 AM, Nick Coghlan wrote: Given the variant you [Koos] suggested, what if we defined the API semantics like this: # Offer the simplest possible API as the public vesion def fspath(pathlike) -> str: return os._raw_fspath(pathlike) # Expose the

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 18 April 2016 at 07:05, Koos Zevenhoven wrote: > On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman wrote: > > On 04/17/2016 06:58 AM, Koos Zevenhoven wrote: > > > >> So, as a summary: With a str+bytes-polymorphic __fspath__, with the > >> above

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/17/2016 02:05 PM, Koos Zevenhoven wrote: On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman wrote: On 04/17/2016 06:58 AM, Koos Zevenhoven wrote: So, as a summary: With a str+bytes-polymorphic __fspath__, with the above argumentation and the rough implementation of

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 18, 2016 at 7:05 AM, Koos Zevenhoven wrote: > On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman wrote: >> On 04/17/2016 06:58 AM, Koos Zevenhoven wrote: >> >>> So, as a summary: With a str+bytes-polymorphic __fspath__, with the >>> above

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman wrote: > On 04/17/2016 06:58 AM, Koos Zevenhoven wrote: > >> So, as a summary: With a str+bytes-polymorphic __fspath__, with the >> above argumentation and the rough implementation of os.fspath(...), >> the conclusion is that the

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/17/2016 06:58 AM, Koos Zevenhoven wrote: So, as a summary: With a str+bytes-polymorphic __fspath__, with the above argumentation and the rough implementation of os.fspath(...), the conclusion is that the os.fspath function should indeed be public, and that no further variations are

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Sun, Apr 17, 2016 at 11:03 AM, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > str and bytes aren't going to implement __fspath__ (since they're > > only *sometimes* path objects), so asking people to call the > > protocol method directly for any purpose would be

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 17 April 2016 at 18:03, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > and instead throw exceptions in those cases. > > Then I don't understand the current design of fsdecode and fsencode. > Shouldn't they raise on str and bytes respectively, rather than > passing

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Nick Coghlan writes: > str and bytes aren't going to implement __fspath__ (since they're > only *sometimes* path objects), so asking people to call the > protocol method directly for any purpose would be a pain. It *should* be a pain. People who need bytes should call fsencode, people who

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 16 April 2016 at 21:21, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > On 15 April 2016 at 00:52, Stephen J. Turnbull wrote: > > > Nick Coghlan writes: > > > > > > > The use case for returning bytes from __fspath__ is DirEntry, so you > >

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 16 April 2016 at 14:46, Stephen J. Turnbull wrote: > Paul Moore writes: [...] > > 1. I just want to pass the argument on to other functions - just do > > so, stdlib functions will work fine. > > I think this is a bad idea unless you *need* polymorphism, but OK, > it's

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Paul Moore writes: > On 16 April 2016 at 12:21, Stephen J. Turnbull wrote: > > OK, you win, __fspath__ needs to be polymorphic. > > > > But you've just shifted me to -1 on "os.fspath": it's an attractive > > nuisance. EIBTI, applications and high-level library functions

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 16 April 2016 at 12:21, Stephen J. Turnbull wrote: > OK, you win, __fspath__ needs to be polymorphic. > > But you've just shifted me to -1 on "os.fspath": it's an attractive > nuisance. EIBTI, applications and high-level library functions should > use os.fsdecode or

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Nick Coghlan writes: > On 15 April 2016 at 00:52, Stephen J. Turnbull wrote: > > Nick Coghlan writes: > > > > > The use case for returning bytes from __fspath__ is DirEntry, so you > > > can write things like this in low level code: > > > > > > def

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 15 April 2016 at 00:52, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > The use case for returning bytes from __fspath__ is DirEntry, so you > > can write things like this in low level code: > > > > def myscandir(dirpath): > > for entry in

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/14/2016 06:01 PM, Ethan Furman wrote: On 04/14/2016 05:20 PM, Stephen J. Turnbull wrote: you'll have to impose it on me. Hmm. Well, the good news is you have convinced me that letting bytes through willy-nilly is akin to loosing the hounds of hell on our code. The bad news is I was

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/14/2016 05:20 PM, Stephen J. Turnbull wrote: However, the proposed polymorphism does create ambiguity and risk for my uses. I rarely have the luxury of *not* ensuring paths are text, regardless of the bytes-ness of the underlying application, because I can be pretty darn sure that

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman writes: > Substitute open() with sending those bytes somewhere else: Eg, pathlib.Path, which will raise? Surely it should be safe to pass a DirEntry to a pathlib constructor? Note that having Path call fsdecode implicitly is a bad idea, because we don't know the provenance of

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 02:37 PM, Victor Stinner wrote: I'm not a big fan of a flag parameter to change the return type of a function. Usually, two functions are preferred. In the os module we have getcwd/getcwdb for example. I don't know if it's a good example I think of os.fspath() as more of a

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/14/2016 07:52 AM, Stephen J. Turnbull wrote: Nick Coghlan writes: The use case for returning bytes from __fspath__ is DirEntry, so you can write things like this in low level code: def myscandir(dirpath): for entry in os.scandir(dirpath): if entry.is_file():

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Random832 writes: > On Thu, Apr 14, 2016, at 03:02, Stephen J. Turnbull wrote: > > I have a strong preference for str only, because I still don't see a > > use case for polymorphic __fspath__. > > Ultimately we're talking about redundancy and performance here. Ultimately, yes. Right now I

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Nick Coghlan writes: > The use case for returning bytes from __fspath__ is DirEntry, so you > can write things like this in low level code: > > def myscandir(dirpath): > for entry in os.scandir(dirpath): > if entry.is_file(): > with open(entry) as

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Thu, Apr 14, 2016, at 03:02, Stephen J. Turnbull wrote: > I have a strong preference for str only, because I still don't see a > use case for polymorphic __fspath__. Ultimately we're talking about redundancy and performance here. The "use case" such as there is one, is if there's a class (be

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Thu, Apr 14, 2016, at 02:00, Nick Coghlan wrote: > > If the protocol can return bytes, then that means that types (DirEntry? > > someone had an alternate path library with a bPath?) which return bytes > > via the protocol will proliferate, and cannot be safely passed to > > anything that uses

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 17:02, Stephen J. Turnbull wrote: > But WDOT? I'd especially like to hear if Nick is tempted to flip-flop > (so far he's been in the "pathlib is a text utility" camp). pathlib is too high level (i.e. has too many dependencies) to be used in low level

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 08:02, Stephen J. Turnbull wrote: > So let me propose what I think is the elephant in the room. If you're > going to have a polymorphic __fspath__, then pathlib is *the* example > of a module that *desperately* needs to be polymorphic. Consider: > > A

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

I was going to read the new posts that came in since I started this one (at one point it was 5X as long as it is now), but this thread is way out of control. My apologies to anybody who has presented[1] use cases in support of the wildly speculative proposals under discussion, but my bet is that

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 13:54, Random832 wrote: > On Wed, Apr 13, 2016, at 23:17, Nick Coghlan wrote: > >> - os.fspath -> str (no coercion) >> - os.fsdecode -> str (with coercion from bytes) >> - os.fsencode -> bytes (with coercion from str) >> - os._raw_fspath -> str-or-bytes

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016, at 23:17, Nick Coghlan wrote: > - os.fspath -> str (no coercion) > - os.fsdecode -> str (with coercion from bytes) > - os.fsencode -> bytes (with coercion from str) > - os._raw_fspath -> str-or-bytes (no coercion) > > (with "coercion" referring to how the result of

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 12:49, Nick Coghlan wrote: > The API could be something like: > > - os.fspath -> str-or-bytes > - os.fsencode -> bytes (with coercion from str) > - os.fsdecode -> str (with coercion from bytes) > - os.strpath -> str (no coercion) There seems to be fairly

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 07:37, Victor Stinner wrote: > Le mercredi 13 avril 2016, Brett Cannon a écrit : >> >> All of this is demonstrated in >> https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 by the >> various possibilities. In the

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Oops sorry, I forgot to add that I have no strong opinion on the type (I only have a minor preference for str only). Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Le mercredi 13 avril 2016, Brett Cannon a écrit : > > 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

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, 13 Apr 2016 at 09:52 Random832 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

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 09:58 AM, Brett Cannon wrote:> On Wed, 13 Apr 2016 at 09:19 Fred Drake wrote: >> I do the same, but... this is one of those cases where a caller will >> usually be passing a constant directly. If passed as a positional >> argument, it'll just be confusing ("what's True?" is my

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Apr 13 2016, Ethan Furman wrote: > (I'm not very good at keeping similar sounding functions separate -- > what's the difference between shutil.copy and shutil.copy2? I have to > look it up every time). Well, "2" is more than "" (or 1), so copy2() copies *more* than copy()

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, 13 Apr 2016 at 09:19 Fred Drake wrote: > On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote: > > - a single os.fspath() with an allow_bytes parameter > > (mostly True in os and os.path, mostly False everywhere > > else) > > -0 > > > - a

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

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

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 13 April 2016 at 17:31, Ethan Furman wrote: > On 04/13/2016 09:27 AM, Paul Moore wrote: >> >> On 13 April 2016 at 17:18, Fred Drake wrote: > > >>> Names like os.fspath() and os.fssyspath() seem good to me. >> >> >> -1 on fssyspath - the "system" representation is bytes on

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 09:27 AM, Paul Moore wrote: On 13 April 2016 at 17:18, Fred Drake wrote: Names like os.fspath() and os.fssyspath() seem good to me. -1 on fssyspath - the "system" representation is bytes on POSIX, but not on Windows. Let's be explicit and go with fsbytespath(). It will be

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 09:18 AM, Fred Drake wrote: On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote: - a single os.fspath() with an allow_bytes parameter (mostly True in os and os.path, mostly False everywhere else) -0 - a str-only os.fspathname() and a str/bytes os.fspath() +1 on using

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016 at 12:27 PM, Paul Moore wrote: > -1 on fssyspath - the "system" representation is bytes on POSIX, but > not on Windows. Let's be explicit and go with fsbytespath(). Depends on the semantics; if we're expecting it to return str-or-bytes, os.fssyspath()

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 13 April 2016 at 17:18, Fred Drake wrote: > Names like os.fspath() and os.fssyspath() seem good to me. -1 on fssyspath - the "system" representation is bytes on POSIX, but not on Windows. Let's be explicit and go with fsbytespath(). But agreed that always-constant boolean

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote: > - a single os.fspath() with an allow_bytes parameter > (mostly True in os and os.path, mostly False everywhere > else) -0 > - a str-only os.fspathname() and a str/bytes os.fspath() +1 on using separate functions.

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

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

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

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

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/13/2016 07:21 AM, Nick Coghlan wrote: On 14 April 2016 at 00:11, Paul Moore wrote: On 13 April 2016 at 14:51, Nick Coghlan wrote: The potential SE-strings only come back when you pass str, and the operating system data isn't properly encoded according to the nominal filesystem

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 14 April 2016 at 00:11, Paul Moore wrote: > On 13 April 2016 at 14:51, Nick Coghlan wrote: >> The potentially SE-strings only come back when you pass str, and the >> operating system data isn't properly encoded according to the nominal >> filesystem

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 13 April 2016 at 14:51, Nick Coghlan wrote: > The potentially SE-strings only come back when you pass str, and the > operating system data isn't properly encoded according to the nominal > filesystem encoding. They round trip nicely to other operating system > APIs, but can

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 13 April 2016 at 02:15, Ethan Furman wrote: > On 04/11/2016 04:43 PM, Victor Stinner wrote: >> >> Le 11 avr. 2016 11:11 PM, "Ethan Furman" a écrit : > > >>> So my concern in such a case is what happens if we pass this SE >>> string somewhere else: a UTF-8 file, or over a

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/12/2016 09:20 AM, Chris Angelico wrote: On Wed, Apr 13, 2016 at 2:15 AM, Ethan Furman latin1? I thought latin1 had a code point for 0-255, so how could using it raise an encoding error? Latin-1 / ISO-8859-1 defines a character for every byte, so any byte string will *decode*. It only

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, Apr 12, 2016 at 9:20 AM, Chris Angelico wrote: > > latin1? I thought latin1 had a code point for 0-255, so how could using > it > > raise an encoding error? > > Latin-1 / ISO-8859-1 defines a character for every byte, so any byte > string will *decode*. It only defines

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016 at 2:15 AM, Ethan Furman wrote: > On 04/11/2016 04:43 PM, Victor Stinner wrote: >> >> Le 11 avr. 2016 11:11 PM, "Ethan Furman" a écrit : > > >>> So my concern in such a case is what happens if we pass this SE >>> string somewhere else: a UTF-8 file, or

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 04:43 PM, Victor Stinner wrote: Le 11 avr. 2016 11:11 PM, "Ethan Furman" a écrit : So my concern in such a case is what happens if we pass this SE string somewhere else: a UTF-8 file, or over a socket, or into a database? Does this have issues that we wouldn't face if we just

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

INADA Naoki writes: > > Why not print(obj)? print(obj) will give mojibake by default if sys.getfilenameencoding() != sys.getdefaultencoding(). > > str() is normal high-level API, and __fspath__ and os.fspath() should be > > low level API. > > Normal users shouldn't use __fspath__ and

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman wrote: # after new protocol with bytes/str support def zingar(a_path): a_path = fspath(a_path) if not isinstance(a_path, (bytes,str)): raise TypeError('bytes or str required') ... I think that one would be just def zingar(a_path): a_path

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Sorry, I've forgot to use "Reply All". On Tue, Apr 12, 2016 at 9:49 AM, INADA Naoki wrote: > IHMO it's safer to get an encoding error rather than no error when you >> concatenate two byte strings encoded to two different encodings (mojibake). >> >> print(os.fspath(obj))

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 01:42 PM, Victor Stinner wrote: With the PEP 383, a bytes filename can be stored as str using the surrogateescape error handler. So DirEntry can convert a bytes path to str using os.fsdecode(). Does this mean that os.fsdecode() is simply a wrapper that sets the errors to the

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Le 11 avr. 2016 11:11 PM, "Ethan Furman" a écrit : > So my concern in such a case is what happens if we pass this SE string somewhere else: a UTF-8 file, or over a socket, or into a database? Does this have issues that we wouldn't face if we just used bytes? "SE string" are

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 14:11 Ethan Furman wrote: > On 04/11/2016 01:42 PM, Victor Stinner wrote: > > 2016-04-11 21:00 GMT+02:00 Brett Cannon: > > >> I'm -0 on allowing __fspath__ to return bytes, but we can see what > others > >> think. > > > > With the PEP 383, a bytes

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 01:42 PM, Victor Stinner wrote: 2016-04-11 21:00 GMT+02:00 Brett Cannon: I'm -0 on allowing __fspath__ to return bytes, but we can see what others think. With the PEP 383, a bytes filename can be stored as str using the surrogateescape error handler. So DirEntry can convert a

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

2016-04-11 21:00 GMT+02:00 Brett Cannon : > I'm -0 on allowing __fspath__ to return bytes, but we can see what others > think. With the PEP 383, a bytes filename can be stored as str using the surrogateescape error handler. So DirEntry can convert a bytes path to str using

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 12:00 PM, Brett Cannon wrote: On Mon, 11 Apr 2016 at 11:28 Ethan Furman wrote: I would write the above as: def fspath(path, *, allow_bytes=False): You get type consistency from so.fspath(), not the protocol, though. Well, since the protocol is also a function, we could

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 11:28 Ethan Furman wrote: > On 04/11/2016 10:36 AM, Brett Cannon wrote: > > On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote: > > >> I'm not saying that bytes paths are common -- and if this was a > >> brand-new feature I wouldn't be pushing for it so

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 10:36 AM, Brett Cannon wrote: On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote: I'm not saying that bytes paths are common -- and if this was a brand-new feature I wouldn't be pushing for it so hard; however, bytes paths are already supported and it seems to me to be much less

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 11, 2016, at 13:36, Brett Cannon wrote: > How about we take something from the "explicit is better than implicit" > playbook and add a keyword argument to os.fspath() to allow bytes to pass > through? Except, we already know how to convert a bytes-path into a str (and vice versa) with

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman stoneleaf.us> writes: > > On 04/11/2016 07:56 AM, Antoine Pitrou wrote: > > >> 2) pathlib.Path accepts bytes -- > > > > Does it? Or are you proposing such a change? > > It used to (I posted a couple examples from 3.5.0). I finally rebuilt > with the latest and it no longer does.

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote: > On 04/11/2016 09:32 AM, Zachary Ware wrote: > > On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote: > > >> If those examples are anywhere close to accurate, an fspath protocol > that > >> supported both bytes and str seems

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

> On Apr 11, 2016, at 1:12 PM, Ethan Furman wrote: > > Asked another way, what are we gaining by disallowing bytes in this new way > of getting paths versus the pain caused when bytes are needed and/or accepted? It seems fine to me to allow __fspath__ to return bytes as

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 09:32 AM, Zachary Ware wrote: On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote: If those examples are anywhere close to accurate, an fspath protocol that supported both bytes and str seems a lot easier to work with. But why are you working with bytes paths in the first

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote: > If those examples are anywhere close to accurate, an fspath protocol that > supported both bytes and str seems a lot easier to work with. But why are you working with bytes paths in the first place? Where did you get

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/10/2016 11:27 PM, Nick Coghlan wrote: On 11 April 2016 at 02:16, Ethan Furman wrote: DirEntry can still get the check, it can just throw TypeError when it represents a binary path (that's one of the advantages of using a method-based protocol - exceptions on method

  1   2   >