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 wrote:
> see
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. Thank
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 th
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 memo
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 handled like a
>>> doubly-linked li
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.
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 hol
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 definiti
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, "Fran
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 extensions to it.
>
> P.S.: If anyone is
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 pur
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 pur
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 pur
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 no
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 pur
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 pur
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 pur
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
Python-Dev@python.org
https://mail
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 open, but requires careful design and
>> implem
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 pointed out in the
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 updated in a while, th
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 discussion on Ordere
> 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 proper
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 (
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 hone
On Tue Jan 27 2015 at 2:13:08 PM Armin Rigo wrote:
> Hi all,
>
> On 24 January 2015 at 11:50, Maciej Fijalkowski 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
Hi all,
On 24 January 2015 at 11:50, Maciej Fijalkowski 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 coming fro
On Sat, Jan 24, 2015 at 11:11 AM, Maciej Fijalkowski
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
> these days.
>
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 wrote:
>
On Sat, Jan 24, 2015 at 3:50 AM, Maciej Fijalkowski 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 coming from it)
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
wr
On Sat, Jan 24, 2015 at 12:50 PM, Maciej Fijalkowski 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 saving coming
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 principl
33 matches
Mail list logo
