Re: [Python-Dev] PEP 468 ready for pronouncement.

Thanks Eric! The synergy between this PEP and the compact dict is amazing BTW. Clearly its time has come. Therefore: PEP 468 is now accepted. You may as well call it Final, since all we need to do now is update the docs. Congrats!! --Guido On Thu, Sep 8, 2016 at 1:20 PM, Eric Snow

[Python-Dev] PEP 468 ready for pronouncement.

see: https://github.com/python/peps/blob/master/pep-0468.txt With the introduction of the compact dict implementation for CPython 3.6, PEP 468 becomes no more than a change to the language reference. I've adjusted the PEP to specify use of an ordered mapping rather than exactly OrderedDict.

Re: [Python-Dev] PEP 468

Compact OrderedDicts can leave gaps, and once in a while compactify. For example, whenever the entry table is full, it can decide whether to resize (and only copy non-gaps), or just compactactify Compact regular dicts can swap from the back and have no gaps. I don't see the point of discussing

Re: [Python-Dev] PEP 468

On 06/13/2016 05:47 PM, Larry Hastings wrote: On 06/13/2016 05:05 PM, MRAB wrote: This could be avoided by expanding the items to include the index of the 'previous' and 'next' item, so that they could be handled like a doubly-linked list. The disadvantage would be that it would use more

Re: [Python-Dev] PEP 468

On Jun 13, 2016 6:16 PM, "MRAB" wrote: > > On 2016-06-14 01:47, Larry Hastings wrote: >> >> On 06/13/2016 05:05 PM, MRAB wrote: >>> >>> This could be avoided by expanding the items to include the index of >>> the 'previous' and 'next' item, so that they could be

Re: [Python-Dev] PEP 468

On 2016-06-14 01:47, Larry Hastings wrote: On 06/13/2016 05:05 PM, MRAB wrote: This could be avoided by expanding the items to include the index of the 'previous' and 'next' item, so that they could be handled like a doubly-linked list. The disadvantage would be that it would use more memory.

Re: [Python-Dev] PEP 468

On 06/13/2016 05:05 PM, MRAB wrote: This could be avoided by expanding the items to include the index of the 'previous' and 'next' item, so that they could be handled like a doubly-linked list. The disadvantage would be that it would use more memory. Another, easier technique: don't fill

Re: [Python-Dev] PEP 468

On 2016-06-13 17:34, Ethan Furman wrote: On 06/10/2016 02:13 PM, Franklin? Lee wrote: P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many purposes, including kwargs and class

Re: [Python-Dev] PEP 468

I've set him to moderation for now. Beyond that we'd have to unsubscribe him altogether and ask him to resubscribe later. TJG On 13/06/2016 22:34, Guido van Rossum wrote: Can someone block Franklin until his mailer stops resending this message? --Guido (mobile) On Jun 13, 2016 2:26 PM,

Re: [Python-Dev] PEP 468

Can someone block Franklin until his mailer stops resending this message? --Guido (mobile) On Jun 13, 2016 2:26 PM, "Franklin? Lee" wrote: > I am. I was just wondering if there was an in-progress effort I should be > looking at, because I am interested in

Re: [Python-Dev] PEP 468

I am. I was just wondering if there was an in-progress effort I should be looking at, because I am interested in extensions to it. P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many

Re: [Python-Dev] PEP 468

I am. I was just wondering if there was an in-progress effort I should be looking at, because I am interested in extensions to it. P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many

Re: [Python-Dev] PEP 468

I am. I was just wondering if there was an in-progress effort I should be looking at, because I am interested in extensions to it. P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many

Re: [Python-Dev] PEP 468

On 06/10/2016 02:13 PM, Franklin? Lee wrote: P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many purposes, including kwargs and class definition. It would be great for kwargs, but

Re: [Python-Dev] PEP 468

I am. I was just wondering if there was an in-progress effort I should be looking at, because I am interested in extensions to it. P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many

Re: [Python-Dev] PEP 468

I am. I was just wondering if there was an in-progress effort I should be looking at, because I am interested in extensions to it. P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many

Re: [Python-Dev] PEP 468

I am. I was just wondering if there was an in-progress effort I should be looking at, because I am interested in extensions to it. P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many

Re: [Python-Dev] PEP 468

On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee wrote: > Eric, have you any work in progress on compact dicts? Nope. I presume you are talking the proposal Raymond made a while back. -eric ___ Python-Dev mailing list

Re: [Python-Dev] PEP 468

Eric, have you any work in progress on compact dicts? On Fri, Jun 10, 2016 at 12:54 PM, Eric Snow wrote: > On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote: >> As stated by Guido (and pointed out in the PEP): >> >> Making **kwds ordered is still

Re: [Python-Dev] PEP 468

I would be super excited for this feature, so if there's a reasonable chance of it being picked up I don't mind doing the implementation work. On Fri, Jun 10, 2016, at 11:54 AM, Eric Snow wrote: > On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote: > > As stated by Guido (and

Re: [Python-Dev] PEP 468

On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote: > As stated by Guido (and pointed out in the PEP): > > Making **kwds ordered is still open, but requires careful design and > implementation to avoid slowing down function calls that don't benefit. > > The PEP has not been

Re: [Python-Dev] PEP 468

On Thu, Jun 9, 2016 at 12:41 PM, wrote: > Is there any further thoughts on including this in 3.6? I don't have any plans and I don't know of anyone willing to champion the PEP for 3.6. Note that the implementation itself shouldn't take very long. > Similar to the > recent

Re: [Python-Dev] PEP 468

> From: zr...@fastmail.com > Subject: [Python-Dev] PEP 468 > > Is there any further thoughts on including this in 3.6? Similar to the > recent discussion on OrderedDict namespaces for metaclasses, this would > simplify / enable a number of type factory use cases where pr

[Python-Dev] PEP 468

Is there any further thoughts on including this in 3.6? Similar to the recent discussion on OrderedDict namespaces for metaclasses, this would simplify / enable a number of type factory use cases where proper metaclasses are overkill. This feature would also be quite nice in say pandas where the

Re: [Python-Dev] PEP 468 (Ordered kwargs)

On 28/01/2015 07:14, Gregory P. Smith wrote: It is a potentially bad idea if order is the default behavior of iteration, items(), keys() and values(). Ideally order should only be exposed when explicitly asked for to help prevent bugs and mitigate potential information leaks. I have to be

Re: [Python-Dev] PEP 468 (Ordered kwargs)

Hi all, On 24 January 2015 at 11:50, Maciej Fijalkowski fij...@gmail.com wrote: I would like to point out that we implemented rhettingers idea in PyPy that makes all the dicts ordered by default and we don't have any adverse performance effects (in fact, there is quite significant memory

Re: [Python-Dev] PEP 468 (Ordered kwargs)

On Tue Jan 27 2015 at 2:13:08 PM Armin Rigo ar...@tunes.org wrote: Hi all, On 24 January 2015 at 11:50, Maciej Fijalkowski fij...@gmail.com wrote: I would like to point out that we implemented rhettingers idea in PyPy that makes all the dicts ordered by default and we don't have any

Re: [Python-Dev] PEP 468 (Ordered kwargs)

On Sat, Jan 24, 2015 at 3:50 AM, Maciej Fijalkowski fij...@gmail.com wrote: I would like to point out that we implemented rhettingers idea in PyPy that makes all the dicts ordered by default and we don't have any adverse performance effects (in fact, there is quite significant memory saving

Re: [Python-Dev] PEP 468 (Ordered kwargs)

Hi Guido. I *think* part of the reason why our implementation works is that machines are significantly different than at the times of Knuth. Avoiding cache misses is a very effective way to improve performance these days. Cheers, fijal On Sat, Jan 24, 2015 at 7:39 PM, Guido van Rossum

Re: [Python-Dev] PEP 468 (Ordered kwargs)

Wow, very cool. When I implemented the very first Python dict (cribbing from an algorithm in Knuth) I had no idea that 25 years later there would still be ways to improve upon it! I've got a feeling Knuth probably didn't expect this either... On Sat, Jan 24, 2015 at 2:51 AM, Maciej Fijalkowski

Re: [Python-Dev] PEP 468 (Ordered kwargs)

On Sat, Jan 24, 2015 at 11:11 AM, Maciej Fijalkowski fij...@gmail.com wrote: Hi Guido. I *think* part of the reason why our implementation works is that machines are significantly different than at the times of Knuth. Avoiding cache misses is a very effective way to improve performance

Re: [Python-Dev] PEP 468 (Ordered kwargs)

On Sat, Jan 24, 2015 at 12:50 PM, Maciej Fijalkowski fij...@gmail.com wrote: Hi I would like to point out that we implemented rhettingers idea in PyPy that makes all the dicts ordered by default and we don't have any adverse performance effects (in fact, there is quite significant memory

[Python-Dev] PEP 468 (Ordered kwargs)

Hi I would like to point out that we implemented rhettingers idea in PyPy that makes all the dicts ordered by default and we don't have any adverse performance effects (in fact, there is quite significant memory saving coming from it). The measurments on CPython could be different, but in