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.
* b
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 say that I do not, unde
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 the
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 supporting bytes paths. So
a
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 the
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
> asked for them. AFAICS,
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 p
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 say that it extends setupt
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 can
> interpret yours without pain by compa
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
> using pathlib, o
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 support
> for
> > pathlib I can either (a) rewrite all
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 bette
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 conclusion that
extending p
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 "port
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 en
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 people are just passing i
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 me, I can live with t
17 matches
Mail list logo
