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

2016-04-19 Thread Chris Angelico
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()

2016-04-19 Thread Stephen J. Turnbull
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()

2016-04-19 Thread Stephen J. Turnbull
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()

2016-04-19 Thread Stephen J. Turnbull
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] Modify PyMem_Malloc to use pymalloc for performance

2016-04-19 Thread Victor Stinner
Ping? Is someone still opposed to my change #26249 "Change PyMem_Malloc to use pymalloc allocator"? If no, I think that I will push my change. My change only changes two lines, so it can be easily reverted before CPython 3.6 if we detect major issues in third-party extensions. And maybe it's

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

2016-04-19 Thread Brett Cannon
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()

2016-04-19 Thread Eric Snow
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()

2016-04-19 Thread Brett Cannon
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] Dependent packages not listed on PyPI

2016-04-19 Thread Brett Cannon
Questions about PyPI should be directed at the distutils-sig mailing list. On Tue, 19 Apr 2016 at 08:12 Andreas Maier wrote: > Hi, > I have a package "pywbem" which in its setup script specifies a number of > dependent packages via "install_requires". > > I should also

[Python-Dev] Dependent packages not listed on PyPI

2016-04-19 Thread Andreas Maier
Hi, I have a package "pywbem" which in its setup script specifies a number of dependent packages via "install_requires". I should also say that it extends setuptools/distutils with its own additional keywords, e.g. it adds a "develop_requires", but I believe (hope) that is irrelevant for my

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

2016-04-19 Thread Nick Coghlan
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] PEP 509: Add a private version to dict (version 3)

2016-04-19 Thread Victor Stinner
Hi, > Backwards Compatibility > === > > Since the ``PyDictObject`` structure is not part of the stable ABI and > the new dictionary version not exposed at the Python scope, changes are > backward compatible. My current implementation inserts the new ma_version_tag field in

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

2016-04-19 Thread Koos Zevenhoven
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()

2016-04-19 Thread Stephen J. Turnbull
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()

2016-04-19 Thread Stephen J. Turnbull
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

[Python-Dev] PEP 509: Add a private version to dict (version 3)

2016-04-19 Thread Victor Stinner
Hi, Below if the third version of my PEP 509 (dict version). Changes since the version 2: * __setitem__() and update() now always increases the version: remove the micro-optimization on "dict[key] is new_value". Exception: version is not changed with dict.update() is called without argument. *