Folks,
At the sprint both Victor and Yury have petitioned me to accept this
PEP. I now agree. Let's do it! PEP 509 is hereby officially accepted.
(Some implementation details have to be sorted out, but I need to
unblock Victor before the sprint is over.)
--
--Guido van Rossum (python.org/~guido)
On Fri, Apr 15, 2016 at 7:31 PM, Victor Stinner
wrote:
> .2016-04-15 23:45 GMT+02:00 Jim J. Jewett :
...
>> I just worry that you may end up closing off even better optimizations
>> later, if you make too many promises about exactly how you will do
>> which ones.
>> Today, dict only cares about =
.2016-04-15 23:45 GMT+02:00 Jim J. Jewett :
>> It's an useful property. For example, let's say that you have a guard
>> on globals()['value']. The guard is created with value=3. An unit test
>> replaces the value with 50, but then restore the value to its previous
>> value (3). Later, the guard is
On Fri, Apr 15, 2016 at 4:41 PM, Victor Stinner
wrote:
> 2016-04-15 19:54 GMT+02:00 Jim J. Jewett :
>> (2) Why *promise* not to update the version_tag when replacing a
>> value with itself?
> It's an useful property. For example, let's say that you have a guard
> on globals()['value']. The guar
Hi,
FYI I updated the implementation of the PEP 509:
https://bugs.python.org/issue26058
2016-04-15 11:01 GMT+02:00 Antoine Pitrou :
> Why do this? It's a nice property that two dicts always have different
> version tags, and now you're killing this property for... no obvious
> reason?
>
> Do you
2016-04-15 23:16 GMT+02:00 Ethan Furman :
>> It's an useful property. For example, let's say that you have a guard
>> on globals()['value']. The guard is created with value=3. An unit test
>> replaces the value with 50, but then restore the value to its previous
>> value (3). Later, the guard is ch
2016-04-15 23:07 GMT+02:00 Random832 :
> Why is iterating over items different from iterating over keys?
>
> in other words, why do I have to write:
>
> for k in dict:
> v = dict[k]
> ...do some stuff...
> dict[k] = something
>
> rather than
>
> for k, v in dict.items():
> ...do som
On 04/15/2016 01:41 PM, Victor Stinner wrote:
2016-04-15 19:54 GMT+02:00 Jim J. Jewett:
(2) Why *promise* not to update the version_tag when replacing a
value with itself?
It's an useful property. For example, let's say that you have a guard
on globals()['value']. The guard is created with
On Fri, Apr 15, 2016, at 16:41, Victor Stinner wrote:
> If the dictionary values are modified during the loop, the dict
> version is increased. But it's allowed to modify values when you
> iterate on *keys*.
Why is iterating over items different from iterating over keys?
in other words, why do I
2016-04-15 19:54 GMT+02:00 Jim J. Jewett :
> (1) Meta Question: If this is really only for CPython, then is
> "Standards Track" the right classification?
Yes, I think so. It doesn't seem to be an Informal nor a Process:
https://www.python.org/dev/peps/pep-0001/#pep-types
> (2) Why *promise* n
On 15 April 2016 at 18:54, Jim J. Jewett wrote:
>
> [2A] Do you want to promise that replacing a value with a
> non-identical object *will* trigger a version_tag update *even*
> if the objects are equal?
>
> I would vote no, but I realize backwards-compatibility may create
> such a promise implici
On Thu Apr 14 11:19:42 EDT 2016, Victor Stinner posted the latest
draft of PEP 509; dict version_tag
(1) Meta Question: If this is really only for CPython, then is
"Standards Track" the right classification?
(2) Why *promise* not to update the version_tag when replacing a
value with itself?
2016-04-15 11:01 GMT+02:00 Antoine Pitrou :
> Victor Stinner gmail.com> writes:
>> You're right that incrementing the global version is useless for these
>> specific cases, and using the version 0 should work. It only matters
>> that the version (version? version tag?) is different.
>
> Why do thi
Victor Stinner schrieb am 15.04.2016 um 10:20:
> Le vendredi 15 avril 2016, Stefan Behnel a écrit :
>
>> How can that be achieved? If the tag is just a sequentially growing number,
>> creating two dicts and applying one operation to the first one should give
>> both the same version tag, right?
>>
Victor Stinner gmail.com> writes:
>
> Hi,
>
> 2016-04-14 22:42 GMT+02:00 Armin Rigo tunes.org>:
> > Hi Victor,
> >
> > On 14 April 2016 at 17:19, Victor Stinner
gmail.com> wrote:
> >> Each time a dictionary is created, the global
> >> version is incremented and the dictionary version is initia
Le vendredi 15 avril 2016, Stefan Behnel a écrit :
> How can that be achieved? If the tag is just a sequentially growing number,
> creating two dicts and applying one operation to the first one should give
> both the same version tag, right?
>
Armin didn't propose to get ride of the global versi
Victor Stinner schrieb am 15.04.2016 um 00:33:
> 2016-04-15 0:22 GMT+02:00 Brett Cannon:
>> And even if it was GIL-free you do run the risk of two dicts ending up at
>> the same version # by simply mutating the same number of times if the
>> counters were per-dict instead of process-wide.
>
> For
On Thu, Apr 14, 2016, 17:14 MRAB wrote:
> On 2016-04-14 21:42, Armin Rigo wrote:
> > Hi Victor,
> >
> > On 14 April 2016 at 17:19, Victor Stinner
> wrote:
> >> Each time a dictionary is created, the global
> >> version is incremented and the dictionary version is initialized to the
> >> global v
On 2016-04-14 21:42, Armin Rigo wrote:
Hi Victor,
On 14 April 2016 at 17:19, Victor Stinner wrote:
Each time a dictionary is created, the global
version is incremented and the dictionary version is initialized to the
global version.
A detail, but why not set the version tag of new empty dict
On 2016-04-14 4:42 PM, Armin Rigo wrote:
Hi Victor,
On 14 April 2016 at 17:19, Victor Stinner wrote:
Each time a dictionary is created, the global
version is incremented and the dictionary version is initialized to the
global version.
A detail, but why not set the version tag of new empty d
On 4/14/2016 3:33 PM, Victor Stinner wrote:
When we will be able to get ride of the GIL for the dict type, we will
probably be able to get an atomic "global_version++" for 64-bit
integer. Right now, I don't think that an atomic int64++ is available
on 32-bit archs.
By the time we get an atomic in
2016-04-15 0:22 GMT+02:00 Brett Cannon :
> And even if it was GIL-free you do run the risk of two dicts ending up at
> the same version # by simply mutating the same number of times if the
> counters were per-dict instead of process-wide.
For some optimizations, it is not needed to check if the di
On Thu, 14 Apr 2016 at 15:14 Victor Stinner
wrote:
> 2016-04-14 23:29 GMT+02:00 Barry Warsaw :
> > I can see why you might want a global version number, but not doing so
> would
> > eliminate an implicit reliance on the GIL, or in a GIL-less
> implementation
> > a lock around incrementing the gl
2016-04-14 23:29 GMT+02:00 Barry Warsaw :
> I can see why you might want a global version number, but not doing so would
> eliminate an implicit reliance on the GIL, or in a GIL-less implementation
> a lock around incrementing the global version number.
It's not like the builtin dict type is goin
On Apr 14, 2016, at 11:17 PM, Victor Stinner wrote:
>You're right that incrementing the global version is useless for these
>specific cases, and using the version 0 should work. It only matters
>that the version (version? version tag?) is different.
>
>I will play with that. If I don't see any iss
2016-04-14 22:50 GMT+02:00 Barry Warsaw :
> Although I'm not totally convinced, I won't continue to object. You've
> provided some performance numbers in the PEP even without FAT, and you aren't
> exposing the API to Python, so it's not a burden being imposed on other
> implementations.
Cool!
Ah
Hi,
2016-04-14 22:42 GMT+02:00 Armin Rigo :
> Hi Victor,
>
> On 14 April 2016 at 17:19, Victor Stinner wrote:
>> Each time a dictionary is created, the global
>> version is incremented and the dictionary version is initialized to the
>> global version.
>
> A detail, but why not set the version ta
> From Armin Rigo
> Sent: Thursday, April 14, 2016 4:42 PM
> To: Victor Stinner
> Cc: Python Dev
> Subject: Re: [Python-Dev] RFC: PEP 509: Add a private version to dict
>
> Hi Victor,
>
> On 14 April 2016 at 17:19, Victor Stinner wrote:
> > Each time a
On Apr 14, 2016, at 09:49 PM, Victor Stinner wrote:
>It would be nice to hear Barry Warsow who was opposed to the PEP in
>january. He wanted to wait until FAT Python was proven to really be faster,
>which is still not case right now. (I mean that I didnt't run seriously
>benchmarks, but early macr
Hi Victor,
On 14 April 2016 at 17:19, Victor Stinner wrote:
> Each time a dictionary is created, the global
> version is incremented and the dictionary version is initialized to the
> global version.
A detail, but why not set the version tag of new empty dictionaries to
zero, always? Same afte
Victor Stinner schrieb am 14.04.2016 um 21:56:
> Which kind of usage do you see in Cython?
Mainly caching, I guess. We could avoid global/module name lookups in some
cases, especially inside of loops.
> Off-topic (PEP 510):
>
> I really want to experiment automatic generation of Cython code fro
Which kind of usage do you see in Cython?
Off-topic (PEP 510):
I really want to experiment automatic generation of Cython code from the
Python using profiling to discover function parameters types. Then use the
PEP 510 to attach the fast Cython code to a Python function, but fallback
to bytecode
It would be nice to hear Barry Warsow who was opposed to the PEP in
january. He wanted to wait until FAT Python was proven to really be faster,
which is still not case right now. (I mean that I didnt't run seriously
benchmarks, but early macro benchmarks are not really promising, only micro
benchma
I'll wait a day before formally pronouncing to see if any objections
are made, but it looks good to me.
On Thu, Apr 14, 2016 at 8:19 AM, Victor Stinner
wrote:
> Hi,
>
> I updated my PEP 509 to make the dictionary version globally unique.
> With *two* use cases of this PEP (Yury's method call patc
+1 from me, too. I'm sure we can make some use of this in Cython.
Stefan
Victor Stinner schrieb am 14.04.2016 um 17:19:
> PEP: 509
> Title: Add a private version to dict
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
2016-04-14 18:28 GMT+02:00 Brett Cannon :
> +1 from me!
Thanks.
> A couple of grammar/typo suggestions below.
Fixed. (Yes, I want to use unsigned type, so PY_UINT64_T.)
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
+1 from me!
A couple of grammar/typo suggestions below.
On Thu, 14 Apr 2016 at 08:20 Victor Stinner
wrote:
> Hi,
>
> I updated my PEP 509 to make the dictionary version globally unique.
> With *two* use cases of this PEP (Yury's method call patch and my FAT
> Python project), I think that the P
Hi,
I updated my PEP 509 to make the dictionary version globally unique.
With *two* use cases of this PEP (Yury's method call patch and my FAT
Python project), I think that the PEP is now ready to be accepted.
Globally unique identifier is a requirement for Yury's patch
optimizing method calls (
38 matches
Mail list logo
