Re: [Python-Dev] file system path protocol PEP

Paul Moore wrote: On 13 May 2016 at 17:57, Ethan Furman wrote: 1) What is a wallet garden? I assumed he meant "walled garden" Works either way -- you'd want a wall around your wallet garden to stop people stealing your wallets. -- Greg

[Python-Dev] First 3.6.0 alpha release coming up: 2016-05-16 12:00 UTC

Hi everyone! Thank you for all of your work so far on our next feature release cycle, Python 3.6. Code checkins for 3.6 began 12 months ago, after the feature code cutoff and beta phase for Python 3.5.0. We are now about to do 3.6.0 alpha 1, our first of 4 alpha and 4 beta releases planned

Re: [Python-Dev] File system path PEP, 3rd draft

FYI, I recently sent a couple of emails in my earlier type hinting thread on -ideas. What I wrote now is about the path ABC regarding type hints. -- Koos On Sat, May 14, 2016 at 12:48 AM, Brett Cannon wrote: > > > On Fri, 13 May 2016 at 14:30 Philip Jenvey

Re: [Python-Dev] File system path PEP, 3rd draft

On Fri, 13 May 2016 at 14:30 Philip Jenvey wrote: > > On May 13, 2016, at 11:37 AM, Brett Cannon wrote: > > Biggest changes since the second draft: > >1. Resolve __fspath__() from the type, not the instance (for Guido) > > > if

Re: [Python-Dev] File system path PEP, 3rd draft

> On May 13, 2016, at 11:37 AM, Brett Cannon wrote: > > Biggest changes since the second draft: > Resolve __fspath__() from the type, not the instance (for Guido) > if (PyObject_HasAttrString(path->ob_type, "__fspath__")) { > return

[Python-Dev] quick GitHub transition update (was: File system path PEP, 3rd draft)

On Fri, 13 May 2016 at 12:56 Guido van Rossum wrote: > Can't wait until the peps repo is on GitHub! > With devinabox now moved over to GitHub, the peps repo is next on the list to move (and the devguide after that). I don't know if I'm going to be able to make the migration

Re: [Python-Dev] File system path PEP, 3rd draft

Can't wait until the peps repo is on GitHub! On Fri, May 13, 2016 at 12:24 PM, Brett Cannon wrote: > > > On Fri, 13 May 2016 at 12:08 Barry Warsaw wrote: > >> On May 13, 2016, at 06:37 PM, Brett Cannon wrote: >> >> >PEP: NNN >> >Title: Adding a file system

Re: [Python-Dev] Adding Type[C] to PEP 484

On Fri, 13 May 2016 at 12:38 Guido van Rossum wrote: > I've got another proposed update to PEP 484 ready. There was previously > some discussion on python-ideas (Bcc'ed for closure) and quite a bit on the > typing issue tracker: https://github.com/python/typing/issues/107 > >

[Python-Dev] Adding Type[C] to PEP 484

I've got another proposed update to PEP 484 ready. There was previously some discussion on python-ideas (Bcc'ed for closure) and quite a bit on the typing issue tracker: https://github.com/python/typing/issues/107 I've worked all that into a patch for PEP 484:

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 8:52 PM, Steven D'Aprano wrote: > On Fri, May 13, 2016 at 03:43:29PM +, Brett Cannon wrote: >> On Fri, 13 May 2016 at 04:00 Steven D'Aprano wrote: > > [...] >> > I think it is a bit confusing to refer to "path objects", as

Re: [Python-Dev] File system path PEP, 3rd draft

On Fri, 13 May 2016 at 12:08 Barry Warsaw wrote: > On May 13, 2016, at 06:37 PM, Brett Cannon wrote: > > >PEP: NNN > >Title: Adding a file system path protocol > >Version: $Revision$ > >Last-Modified: $Date$ > >Author: Brett Cannon , > >Koos Zevenhoven

Re: [Python-Dev] File system path PEP, 3rd draft

On May 13, 2016, at 06:37 PM, Brett Cannon wrote: >PEP: NNN >Title: Adding a file system path protocol >Version: $Revision$ >Last-Modified: $Date$ >Author: Brett Cannon , >Koos Zevenhoven >Status: Draft >Type: Standards Track >Content-Type: text/x-rst

[Python-Dev] File system path PEP, 3rd draft

Biggest changes since the second draft: 1. Resolve __fspath__() from the type, not the instance (for Guido) 2. Updated the TypeError messages to say "os.PathLike object" instead of "path object" (implicitly for Steven) 3. TODO item to define "path-like" in the glossary (for Steven)

Re: [Python-Dev] File system path PEP, part 2

On Fri, 13 May 2016 at 10:53 Steven D'Aprano wrote: > On Fri, May 13, 2016 at 03:43:29PM +, Brett Cannon wrote: > > On Fri, 13 May 2016 at 04:00 Steven D'Aprano > wrote: > > [...] > > > - but os.fspath() will only return str; > > > - and

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 03:43:29PM +, Brett Cannon wrote: > On Fri, 13 May 2016 at 04:00 Steven D'Aprano wrote: [...] > > - but os.fspath() will only return str; > > - and os.fspathb() will only return bytes; > I prefer what's in the PEP. I get where you coming from,

Re: [Python-Dev] file system path protocol PEP

On 13 May 2016 at 17:57, Ethan Furman wrote: > 1) What is a wallet garden? I assumed he meant "walled garden" (for people who don't know the phrase, it refers to an area or capability that's only made accessible to "favoured" clients - think of something like Apple's App

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 9:34 AM, Ethan Furman wrote: > I would say use `type(x).__fspath__`. I'm not aware of any other > __dunder__ method that doesn't access the attribute from the type instead > of the instance, and I see no point in making this one different. > Agreed.

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 9:33 AM, Larry Hastings wrote: > > > On 05/13/2016 06:21 PM, Guido van Rossum wrote: > > Really, if you want bytes, you should use os.fsencode(); if you want > strings, use os.fsencode(); if you want to be polymorphic, use os.fspath() > and check the

Re: [Python-Dev] file system path protocol PEP

On Fri, May 13, 2016 at 7:06 PM, Sven R. Kunze wrote: > On 13.05.2016 11:48, Koos Zevenhoven wrote: >> >> This issue is coupled with the future optimization questions. >> > > AFAIC coupling API design to optimization is called premature optimization. > I suppose so, but

Re: [Python-Dev] file system path protocol PEP

On 05/13/2016 09:06 AM, Sven R. Kunze wrote: On 13.05.2016 11:48, Koos Zevenhoven wrote: >> Sven R Kunze had previously queried: However, the proposed semantics will change if the checks are swapped. So, my actual question is: Is that an intended API inconsistency or a known bug supposed to

Re: [Python-Dev] file system path protocol PEP

On 13 May 2016 at 17:06, Sven R. Kunze wrote: > As far as I remember, one goal of this proposal was to avoid wallet gardens. > During the lengthy discussion on python-ideas people brought up that some > third-party libs indeed subclass from str. They are currently locked out.

Re: [Python-Dev] File system path PEP, part 2

On Sat, May 14, 2016 at 2:34 AM, Ethan Furman wrote: > I would say use `type(x).__fspath__`. I'm not aware of any other __dunder__ > method that doesn't access the attribute from the type instead of the > instance, and I see no point in making this one different. >

Re: [Python-Dev] file system path protocol PEP

On Sat, May 14, 2016 at 2:33 AM, Sven R. Kunze wrote: > On 13.05.2016 17:29, Brett Cannon wrote: >> >> Purposeful change. It was what I had in my head after I posted my "groups" >> breakdown email and what Guido suggested as well independently. This helps >> alleviate any perf

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 17:29, Brett Cannon wrote: Purposeful change. It was what I had in my head after I posted my "groups" breakdown email and what Guido suggested as well independently. This helps alleviate any perf worries as type checks in C are pointer checks that are cheap to make compared to

Re: [Python-Dev] File system path PEP, part 2

On 05/13/2016 06:21 PM, Guido van Rossum wrote: Really, if you want bytes, you should use os.fsencode(); if you want strings, use os.fsencode(); if you want to be polymorphic, use os.fspath() and check the type it returns. Am I severely misunderstanding the API, or did you mean "if you want

Re: [Python-Dev] File system path PEP, part 2

On 05/13/2016 08:43 AM, Brett Cannon wrote: a minor technical query: try: return path.__fspath__() Would I be right in saying that in practice this will actually end up being type(path).__fspath__() to match the behaviour of all(?) other dunder methods? I wasn't planning

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 2:00 PM, Steven D'Aprano wrote: > Counter suggestion: > > - __fspath__() method may return either bytes or str (no change > from the PEP as it stands now); > > - but os.fspath() will only return str; > > - and os.fspathb() will only return bytes; > >

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 4:00 AM, Steven D'Aprano wrote: > On Thu, May 12, 2016 at 08:53:12PM +, Brett Cannon wrote: > > > Second draft that takes Guido's comments into consideration. The biggest > > change is os.fspath() now returns whatever path.__fspath__() returns > >

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2016-05-06 - 2016-05-13) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5501 ( -3) closed 33270 (+47) total 38771 (+44) Open issues

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 11:48, Koos Zevenhoven wrote: This issue is coupled with the future optimization questions. AFAIC coupling API design to optimization is called premature optimization. However, the proposed semantics will change if the checks are swapped. So, my actual question is: Is that an

Re: [Python-Dev] File system path PEP, part 2

On Fri, 13 May 2016 at 04:00 Steven D'Aprano wrote: > On Thu, May 12, 2016 at 08:53:12PM +, Brett Cannon wrote: > > > Second draft that takes Guido's comments into consideration. The biggest > > change is os.fspath() now returns whatever path.__fspath__() returns > >

Re: [Python-Dev] file system path protocol PEP

On Fri, 13 May 2016 at 02:25 Sven R. Kunze wrote: > On 13.05.2016 10:36, Koos Zevenhoven wrote: > > This has just been discussed very recently in this thread (and earlier > > too). > > Could you point me to that? It seems I missed that part. I only found > posts related to

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016, at 07:00, Steven D'Aprano wrote: > - but os.fspath() will only return str; > > - and os.fspathb() will only return bytes; And raise an exception if __fspath__ returns the other, I suppose. What's the use case for these functions? When would I call them rather than fsdecode

Re: [Python-Dev] file system path protocol PEP

> On 13 May 2016, at 08:07, Ethan Furman wrote: > > On 05/12/2016 01:59 PM, Sjoerd Job Postmus wrote: >>> On 12 May 2016, at 21:30, Ethan Furman wrote: >>> >>> If you need bytes support for your paths, there's at least one [1] that has >>> that

Re: [Python-Dev] File system path PEP, part 2

> - there is no os function that returns "str or bytes, I don't > care which". (If you really need that, call __fspath__ directly.) os.fspath() in the PEP works when given str or bytes directly, but those don't have a __fspath__ method, so directly calling the dunder method is not equivalent

Re: [Python-Dev] File system path PEP, part 2

Thanks Brett! Now one thing is that, despite your suggestion, I had not added myself as an author in my big pull request. Originally, it was because I simply forgot to copy and paste it when I split my edits into separate commits ;-). Sorry about that (not sure if you care though, and I've been

Re: [Python-Dev] File system path PEP, part 2

On Thu, May 12, 2016 at 08:53:12PM +, Brett Cannon wrote: > Second draft that takes Guido's comments into consideration. The biggest > change is os.fspath() now returns whatever path.__fspath__() returns > instead of restricting it to only str. Counter suggestion: - __fspath__() method may

Re: [Python-Dev] file system path protocol PEP

On Fri, May 13, 2016 at 8:19 PM, Steven D'Aprano wrote: > I feel this is Not Our Problem. Surely the stdlib cannot be held > responsible for all the poor decisions made by third-party libraries? If > a library hard-codes "\\" as their directory separator, because everyone >

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 07:22:25PM +0200, Sjoerd Job Postmus wrote: > The whole point of adding `os.fspath` is to make it easier to use Path > objects. This is in an effort to gain greater adoption of pathlib in > libraries. Now, this is an excellent idea. > > However, if it were to reject

Re: [Python-Dev] file system path protocol PEP

On Fri, May 13, 2016 at 12:24 PM, Sven R. Kunze wrote: > On 13.05.2016 10:36, Koos Zevenhoven wrote: >> >> This has just been discussed very recently in this thread (and earlier >> too). > > > Could you point me to that? It seems I missed that part. I only found posts > related

Re: [Python-Dev] file system path protocol PEP

On 05/12/2016 05:42 PM, Ethan Furman wrote: And even given all that, for smoother interoperability with the rest of the stdlib, or at least the os.* portion, those functions would still need to be upgraded to check for .path on the incoming arguments -- at which point we may as well make a

Re: [Python-Dev] file system path protocol PEP

On 13.05.2016 10:36, Koos Zevenhoven wrote: This has just been discussed very recently in this thread (and earlier too). Could you point me to that? It seems I missed that part. I only found posts related to performance degradation. However, the proposed semantics will change if the checks

Re: [Python-Dev] file system path protocol PEP

This has just been discussed very recently in this thread (and earlier too). It may make sense, but it's not among our current worries. Besides, we already added the new fspath semantics to the PEP. While I hope Brett is asleep in his time zone, I'm guessing he will agree (just saying this

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 18:24, Guido van Rossum wrote: def fspath(p: Union[str, bytes, PathLike]) -> Union[str, bytes]: if isinstance(p, (str, bytes)): return p try: return p.__fspath__ except AttributeError: raise TypeError(...) @Brett Would you think it makes sense

Re: [Python-Dev] file system path protocol PEP

On 12.05.2016 19:27, Ethan Furman wrote: Maybe, but a bad idea for two reasons: 1) Reducing a str to the exact same str is silly; and, more importantly Finding something silly is no technical argument. Best, Sven ___ Python-Dev mailing list

Re: [Python-Dev] file system path protocol PEP

On 05/12/2016 01:59 PM, Sjoerd Job Postmus wrote: On 12 May 2016, at 21:30, Ethan Furman wrote: If you need bytes support for your paths, there's at least one [1] that has that support. So if I would need bytes support, I should submit a pull request to > library> which