Re: [Python-Dev] File system path encoding on Windows

On 31 August 2016 at 10:27, Steve Dower wrote: > On 30Aug2016 1702, Victor Stinner wrote: >> I can try to run more tests if you know some other major Python >> applications (modules?) working on Windows/Python 3. > > The major ones aren't really the concern. I'd be interested to see where > numpy

Re: [Python-Dev] File system path encoding on Windows

On 30Aug2016 1702, Victor Stinner wrote: I made another quick&dirty test on Django 1.10 (I ran Django test suite on my modified Python raising exception on bytes path): I didn't notice any exception related to bytes path. Django seems to only use Unicode for paths. I can try to run more tests i

Re: [Python-Dev] File system path encoding on Windows

I made another quick&dirty test on Django 1.10 (I ran Django test suite on my modified Python raising exception on bytes path): I didn't notice any exception related to bytes path. Django seems to only use Unicode for paths. I can try to run more tests if you know some other major Python applicat

Re: [Python-Dev] File system path encoding on Windows

On 30Aug2016 1611, Victor Stinner wrote: 2016-08-30 23:51 GMT+02:00 Victor Stinner : As I already wrote once, my problem is also tjat I simply have no idea how much Python 3 code uses bytes filename. For example, does it concern more than 25% of py3 modules on PyPi, or less than 5%? I made a v

Re: [Python-Dev] File system path encoding on Windows

2016-08-30 23:51 GMT+02:00 Victor Stinner : > As I already wrote once, my problem is also tjat I simply have no idea how > much Python 3 code uses bytes filename. For example, does it concern more > than 25% of py3 modules on PyPi, or less than 5%? I made a very quick test on Windows using a modif

Re: [Python-Dev] File system path encoding on Windows

Le 30 août 2016 8:05 PM, "Nick Coghlan" a écrit : > This seems to be the crux of the disagreement: our perceptions of the > relative risks to native Windows Python applications that currently > work properly on Python 3.5 vs the potential compatibility benefits to > primarily *nix applications tha

Re: [Python-Dev] File system path encoding on Windows

On 30Aug2016 1108, Guido van Rossum wrote: Is this thread something I need to follow closely? I have PEPs coming, and I'll distil the technical parts of the discussion into those. We may need you to impose an opinion on whether 3.6 is an appropriate time for the change or it should wait for

Re: [Python-Dev] File system path encoding on Windows

On 31 August 2016 at 01:06, Victor Stinner wrote: > 2016-08-30 16:31 GMT+02:00 Steve Dower : >> Any system that requires communication between two different versions of >> Python must have install instructions (if it's public) or someone who >> maintains it. It won't magically break without an upg

Re: [Python-Dev] File system path encoding on Windows

Is this thread something I need to follow closely? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/pyth

Re: [Python-Dev] File system path encoding on Windows

On 30Aug2016 0806, Victor Stinner wrote: 2016-08-30 16:31 GMT+02:00 Steve Dower : It's the random user on Windows who installed their library that has the problem. They don't know the fix, and may not know how to apply it (e.g. if it's their Jupyter notebook that won't find one of their files -

Re: [Python-Dev] File system path encoding on Windows

2016-08-30 16:31 GMT+02:00 Steve Dower : > It's the > random user on Windows who installed their library that has the problem. > They don't know the fix, and may not know how to apply it (e.g. if it's > their Jupyter notebook that won't find one of their files - no obvious > command line options he

Re: [Python-Dev] File system path encoding on Windows

Top-posted from my Windows Phone -Original Message- From: "Victor Stinner" Sent: ‎8/‎30/‎2016 1:21 To: "Nick Coghlan" Cc: "Steve Dower" ; "Python Dev" Subject: Re: [Python-Dev] File system path encoding on Windows Le 30 août 2016 03:10, "Nick

Re: [Python-Dev] File system path encoding on Windows

Le 30 août 2016 03:10, "Nick Coghlan" a écrit : > However, this view is also why I don't agree with being aggressive in > making this behaviour the default on Windows - I think we should make > it readily available as a provisional feature through a single > cross-platform command line switch and

Re: [Python-Dev] File system path encoding on Windows

On 30 August 2016 at 13:29, Steve Dower wrote: > The other discussion about OpenSSL and LTS systems is also interesting. Do > we really expect users to take their fully functioning systems and blindly > upgrade to a new major version of Python expecting everything to just work? > That seems very u

Re: [Python-Dev] File system path encoding on Windows

On 29Aug2016 1810, Nick Coghlan wrote: On 30 August 2016 at 08:38, Victor Stinner wrote: Hi, tl; dr: just drop byte support and help developers to use Unicode in their application! My view (and Steve's) is that this approach is likely to result in Linux-centric projects just dropping even no

Re: [Python-Dev] File system path encoding on Windows

On 30 August 2016 at 11:10, Daniel Holth wrote: > A nice recent blog post about paths encoding in a media player. > http://beets.io/blog/paths.html . It's not merely the porting that makes it > hard. Interestingly, with Steve's proposed changes, their approach of using bytes paths internally shou

Re: [Python-Dev] File system path encoding on Windows

On 30 August 2016 at 08:38, Victor Stinner wrote: > Hi, > > tl; dr: just drop byte support and help developers to use Unicode in > their application! My view (and Steve's) is that this approach is likely to result in Linux-centric projects just dropping even nominal native Windows support, rather

Re: [Python-Dev] File system path encoding on Windows

A nice recent blog post about paths encoding in a media player. http://beets.io/blog/paths.html . It's not merely the porting that makes it hard. On Mon, Aug 29, 2016, 19:32 Victor Stinner wrote: > 2016-08-24 17:44 GMT+02:00 Steve Dower : > > I know Nick and Victor like the idea of a -X flag (or

Re: [Python-Dev] File system path encoding on Windows

2016-08-24 17:44 GMT+02:00 Steve Dower : > I know Nick and Victor like the idea of a -X flag (or a direct -utf8 flag), > but I prefer more specific environment variables: > > - PYTHONWINDOWSLEGACYSTDIO (for the console changes) > - PYTHONWINDOWSLEGACYPATHENCODING (assuming getfilesystemencoding() i

Re: [Python-Dev] File system path encoding on Windows

2016-08-20 21:31 GMT+02:00 Nick Coghlan : > Reading your summary meant this finally clicked with something Victor > has been considering for a while: a "Force UTF-8" switch that told > Python to ignore the locale encoding on Linux, and instead assume > UTF-8 everywhere (command line parameter parsi

Re: [Python-Dev] File system path encoding on Windows

Hi, tl; dr: just drop byte support and help developers to use Unicode in their application! As you may already know, I dislike your whole project. But first of all, IMHO you should open a separated thread to discuss changes related to the Windows console. I consider that they are unrelated, well

Re: [Python-Dev] File system path encoding on Windows

On 28Aug2016 2043, Stephen J. Turnbull wrote: tritium-l...@sdamon.com writes: > Once you get to var lengths like that, arcane single character flags start > looking preferable. How about "PYTHONWINLEGACY" to just turn it all on or > off. If the code breaks on one thing, it obviously isn't w

Re: [Python-Dev] File system path encoding on Windows

tritium-l...@sdamon.com writes: > Once you get to var lengths like that, arcane single character flags start > looking preferable. How about "PYTHONWINLEGACY" to just turn it all on or > off. If the code breaks on one thing, it obviously isn't written to use the > other two, so might as well

Re: [Python-Dev] File system path encoding on Windows

t; Cc: Nick Coghlan ; Python Dev > d...@python.org> >> Subject: Re: [Python-Dev] File system path encoding on Windows >> >> On 23Aug2016 2150, Stephen J. Turnbull wrote: >> > Steve Dower writes: >> > >> > > * Stephen sees "no reason not to change &

Re: [Python-Dev] File system path encoding on Windows

> -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Steve Dower > Sent: Wednesday, August 24, 2016 11:44 AM > To: Stephen J. Turnbull > Cc: Nick Coghlan ; Python Dev d...@python.org> > Subjec

Re: [Python-Dev] File system path encoding on Windows

On 23Aug2016 2150, Stephen J. Turnbull wrote: Steve Dower writes: > * Stephen sees "no reason not to change locale.getpreferredencoding()" > (default encoding for open()) at the same time with the same switches, > while I'm not quite as confident. Do users generally specify an encoding > the

Re: [Python-Dev] File system path encoding on Windows

Steve Dower writes: > * Stephen sees "no reason not to change locale.getpreferredencoding()" > (default encoding for open()) at the same time with the same switches, > while I'm not quite as confident. Do users generally specify an encoding > these days? I know I always put utf-8 there. I

Re: [Python-Dev] File system path encoding on Windows

I've trimmed fairly aggressively for the sake of not causing the rest of the list to mute our discussion (again :) ). Stephen - feel free to email me off list if I go too far or misrepresent you. As a summary for people who don't want to read on (and Stephen will correct me if I misquote): *

Re: [Python-Dev] File system path encoding on Windows

eryk sun writes: > I just wrote a simple function to enumerate the 822 system locales on > my Windows box (using EnumSystemLocalesEx and GetLocaleInfoEx, which > are Unicode-only functions), and 36.7% of them lack an ANSI codepage. > They're Unicode-only locales. UTF-8 is the only way to suppo

Re: [Python-Dev] File system path encoding on Windows

Steve Dower writes: > The Windows world is Unicode. Mostly represented in UTF-16, but UTF-8 is > entirely equivalent. Sort of, yes, and not for present purposes. AFAICS, the Windows world is mostly application/* media that require substantial developer effort to extract text from; character e

Re: [Python-Dev] File system path encoding on Windows

On Mon, Aug 22, 2016 at 3:58 PM, Steve Dower wrote: > All MSVC users have been pushed towards Unicode for many years. The .NET > Framework has defaulted to UTF-8 its entire existence. The use of code pages > has been discouraged for decades. We're not going first :) I just wrote a simple function

Re: [Python-Dev] File system path encoding on Windows

On 22Aug2016 0247, Stephen J. Turnbull wrote: Nick Coghlan writes: > On 21 August 2016 at 06:31, Steve Dower wrote: > > My biggest concern is that it then falls onto users to know how > > to start Python with that flag. The users I'm most worried about belong to organizations where concerte

Re: [Python-Dev] File system path encoding on Windows

Nick Coghlan writes: > On 21 August 2016 at 06:31, Steve Dower wrote: > > My biggest concern is that it then falls onto users to know how > > to start Python with that flag. The users I'm most worried about belong to organizations where concerted effort has been made to "purify" the environme

Re: [Python-Dev] File system path encoding on Windows

On 21 August 2016 at 06:31, Steve Dower wrote: > My biggest concern is that it then falls onto users to know how to start > Python with that flag. Not necessarily, as this is one of the areas where commercial redistributors can earn their revenue stream - by deciding that flipping the default beh

Re: [Python-Dev] File system path encoding on Windows

On 20Aug2016 1231, Nick Coghlan wrote: I'd like to suggest an option that didn't come up on python-ideas: add such a flag to Python 3.6, and then actively seek feedback from folks using non-UTF-8 encodings before making a decision on what to do by default in Python 3.7. My biggest concern is th

Re: [Python-Dev] File system path encoding on Windows

On 20 August 2016 at 04:59, Steve Dower wrote: > Questions: > * should we always use Window's Unicode APIs instead of switching between > bytes/Unicode based on parameter type? Yes > * should we allow users to pass bytes and interpret them as utf-8 rather > than letting Windows do the decoding?

Re: [Python-Dev] File system path encoding on Windows

On 19Aug2016 1225, Daniel Holth wrote: #1 sounds like a great idea. I suppose surrogatepass solves approximately the same problem of Rust's WTF-8, which is a way to round-trip bad UCS-2? https://simonsapin.github.io/wtf-8/ Yep. #2 sounds like it would leave several problems, since mbcs is not

Re: [Python-Dev] File system path encoding on Windows

#1 sounds like a great idea. I suppose surrogatepass solves approximately the same problem of Rust's WTF-8, which is a way to round-trip bad UCS-2? https://simonsapin.github.io/wtf-8/ #2 sounds like it would leave several problems, since mbcs is not the same as a normal text encoding, IIUC it depe

[Python-Dev] File system path encoding on Windows

Hi python-dev About a week ago I proposed on python-ideas making some changes to how Python deals with encodings on Windows, specifically in relation to how Python interacts with the operating system. Changes to the console were uncontroversial, and I have posted patches at http://bugs.pytho

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

On 05/17/2016 02:57 AM, Brett Cannon wrote: On Mon, May 16, 2016, 19:02 Ethan Furman > wrote: Isn't 3.4 now in security-fix mode? Yes, but because of pathlib's provisional status, Guido backported the path attribute from 3.4 forward. I think this is one reas

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

On Mon, May 16, 2016, 19:02 Ethan Furman wrote: > On 05/16/2016 02:32 PM, Brett Cannon wrote: > > > PEP 519 is now marked as accepted! Two PEPs accepted in one day (Nick > > approved 518 earlier)! > > Excellent! :) > > > If pathlib doesn't get updated in 3.4, 3.5, and 3.6 before PyCon it will >

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

On 05/16/2016 02:32 PM, Brett Cannon wrote: PEP 519 is now marked as accepted! Two PEPs accepted in one day (Nick approved 518 earlier)! Excellent! :) If pathlib doesn't get updated in 3.4, 3.5, and 3.6 before PyCon it will be the first thing I do at the sprints so that it isn't an issue fo

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

On Mon, 16 May 2016 at 14:03 Guido van Rossum wrote: > For those following along on the list, it's PEP 519: > https://www.python.org/dev/peps/pep-0519/ > > I've read it once more and found nothing worth bickering about, so I am > hereby approving PEP 519. Thanks Brett and Koos for getting this on

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

For those following along on the list, it's PEP 519: https://www.python.org/dev/peps/pep-0519/ I've read it once more and found nothing worth bickering about, so I am hereby approving PEP 519. Thanks Brett and Koos for getting this one over the finish line, and congrats! It's been quite an effort

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

On Mon, 16 May 2016 at 13:12 Guido van Rossum wrote: > Once you assign yourself a PEP number I'll do one more pass and then I > expect to accept it -- the draft looks good to me! > Done: https://hg.python.org/peps/rev/b41cb718054a > > On Mon, May 16, 2016 at 1:00 PM, Brett Cannon wrote: > >>

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

Once you assign yourself a PEP number I'll do one more pass and then I expect to accept it -- the draft looks good to me! On Mon, May 16, 2016 at 1:00 PM, Brett Cannon wrote: > Recent discussions have been about type hints which are orthogonal to the > PEP, so things have seemed to have reached

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

Recent discussions have been about type hints which are orthogonal to the PEP, so things have seemed to have reached a steady state. Was there anything else that needed clarification, Guido, or are you ready to pronounce? Or did you want to wait until the language summit? Or did you want to assign

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

Greg Ewing writes: > 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. Actually,

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

On Fri, May 13, 2016 at 7:43 PM, Chris Angelico wrote: [...] > "Check" accepts subclasses; "CheckExact" doesn't (it's like "type(x) > is str"). The question is, which one SHOULD be being done? Indeed it should do "Check", so that path libraries that do inherit from str will still work (see also b

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

On 14 May 2016 at 19:36, Sven R. Kunze wrote: > Fine example. Thinking naively, I would say, when somebody made an effort to > write __fspath__, it should be respected. Maybe, that's just me. Over time, we've generally moved towards treating subclasses as if they were the base class where protoco

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

On 13.05.2016 18:43, Chris Angelico wrote: https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Check https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_CheckExact Thanks for pointing me at this. I searched via github and found usages only: https://github.com/python/cpython/search?u

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

Chris Angelico writes: > AFAICT, the compatibility layer would simply decode the bytes using > surrogateescape handling, which should round-trip anything. By design. See PEP 383. Or rather, the OP should; he has not done his homework and is confused by his own FUD. This whole subthread is re

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 ___ Pytho

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 wrote: >> >> >> On May 13, 2016, at 11

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 (PyObject_HasAttrString(path->ob_type, "__fspath__")) {

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 PyObject_CallMethodObjArgs(path->ob_type,

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 path protocol >> >Version: $Revision$

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 that seems >> > like you are referring only to

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 > >Status: Draft > >Type: Standards

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 >Created: 11-May-2016 >Post-History:

[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 os.fspathb() will only return bytes; > > > I prefer wh

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, Steven, but I > don't th

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 Store, where you have to

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. -- --Guido van Ross

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 type it returns. > > >

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 currently I consider the A

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 b

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. Hardly. Libraries th

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. > __reduce__ / __reduce_ex__ in

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 worries as type chec

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 att

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; > > - there is no os func

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 > > instead of restrictin

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 i

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 > > instead of restricting it

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 performance degradation

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 a

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 support. >> >> So if I would need bytes suppor

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 to

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 de

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

On 13 May 2016 at 21: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 >> instead of restricting it to only

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

On Fri, May 13, 2016 at 9:00 PM, Steven D'Aprano wrote: > Cons: > (3) Polymorphic code that truly doesn't care whether it gets bytes or > str will have a slightly less convenient way of getting it, namely by > calling __fspath__() itself, instead of os.fspath(). I don't like this; it goes against

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 r

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 > uses Windows, you'd sim

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 bytes,

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 to performance degr

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 pr

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 a

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 because

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 t

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 Python-D

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 replaces usage of the

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

On 13 May 2016 at 06:53, 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. > > Minor changes: > - Renamed the C function to PyOS_FSPath() > -

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

On Thu, 12 May 2016 at 14:04 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 > which replac

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

> 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 which replaces usage of the stdlib pathlib with another variant, upon which the

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

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. Minor changes: - Renamed the C function to PyOS_FSPath() - Added an Implementation section with a TODO list - Bunch o

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

On 05/12/2016 10:22 AM, Sjoerd Job Postmus wrote: However, if it were to reject bytes, that would mean that when libraries start to use pathlib, it would suddenly become harder for people that actually need bytes-support to use pathlib. pathlib is not about bytes support. While bytes are nece

  1   2   3   >