On 22 March 2014 04:48, Maciej Fijalkowski wrote:
> at the end of the day we settled for dicts with str int or identity
> keys, so we're perfectly safe
Ah, Armin's original investment in PyPy's type tracking infrastructure
pays off yet again :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmai
On Wed, Mar 19, 2014 at 11:43 PM, Nick Coghlan wrote:
>
> On 20 Mar 2014 07:38, "Nick Coghlan" wrote:
>>
>> Correct, but I think this discussion has established that "how many times
>> dict lookup calls __eq__ on the key" is one such thing. In CPython, it
>> already varies based on:
>>
>> - dict
On 20 Mar 2014 07:38, "Nick Coghlan" wrote:
>
> Correct, but I think this discussion has established that "how many times
dict lookup calls __eq__ on the key" is one such thing. In CPython, it
already varies based on:
>
> - dict contents (due to the identity check and the distribution of
entries a
On 20 Mar 2014 02:37, "Stephen J. Turnbull" wrote:
>
> Kevin Modzelewski writes:
>
> > Sorry, I definitely didn't mean to imply that this kind of
> > optimization is valid on arbitrary subscript expressions; I thought
> > we had restricted ourselves to talking about builtin dicts.
>
> Ah, maybe
Kevin Modzelewski writes:
> Sorry, I definitely didn't mean to imply that this kind of
> optimization is valid on arbitrary subscript expressions; I thought
> we had restricted ourselves to talking about builtin dicts.
Ah, maybe so -- Maciej made that clear later for PyPy. My bad. (With
the
On Wed, Mar 19, 2014 at 8:38 AM, Kevin Modzelewski wrote:
> Sorry, I definitely didn't mean to imply that this kind of optimization is
> valid on arbitrary subscript expressions; I thought we had restricted
> ourselves to talking about builtin dicts. If we do, I think this becomes a
> discussion
On Wed, Mar 19, 2014 at 3:26 PM, Antoine Pitrou wrote:
> On Wed, 19 Mar 2014 15:21:16 +0200
> Maciej Fijalkowski wrote:
>
>> On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou wrote:
>> > On Wed, 19 Mar 2014 15:09:04 +0200
>> > Maciej Fijalkowski wrote:
>> >>
>> >> I would like to point out that i
Sorry, I definitely didn't mean to imply that this kind of optimization is
valid on arbitrary subscript expressions; I thought we had restricted
ourselves to talking about builtin dicts. If we do, I think this becomes a
discussion about what subset of the semantics of CPython's builtins are
langua
The docs don't seem to make any guarantee about calling __eq__ or __hash__:
d[key]
Return the item of d with key key. Raises a KeyError if key is not in the
map.
which seems to indicate that this kind of optimization should be fine.
In fact I would very much like messing with the semantics of __
On Wed, 19 Mar 2014 07:09:23 -0700
Thomas Wouters wrote:
>
> He means you're being unrealistically pedantic :) The number of calls to
> __eq__ is _already_ unpredictable, since (as Mark Shannon said) it depends
> among other things on the hashing algorithm and the size of the dict.
Well, I was n
On Wed, Mar 19, 2014 at 6:26 AM, Antoine Pitrou wrote:
> On Wed, 19 Mar 2014 15:21:16 +0200
> Maciej Fijalkowski wrote:
>
> > On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou
> wrote:
> > > On Wed, 19 Mar 2014 15:09:04 +0200
> > > Maciej Fijalkowski wrote:
> > >>
> > >> I would like to point ou
On Wed, 19 Mar 2014 15:21:16 +0200
Maciej Fijalkowski wrote:
> On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou wrote:
> > On Wed, 19 Mar 2014 15:09:04 +0200
> > Maciej Fijalkowski wrote:
> >>
> >> I would like to point out that instructing people does not really
> >> work. Besides, other exampl
On Wed, Mar 19, 2014 at 3:17 PM, Antoine Pitrou wrote:
> On Wed, 19 Mar 2014 15:09:04 +0200
> Maciej Fijalkowski wrote:
>>
>> I would like to point out that instructing people does not really
>> work. Besides, other examples like this:
>>
>> if d[x] >= 3:
>>d[x] += 1 don't really work.
>
> Th
On Wed, 19 Mar 2014 15:09:04 +0200
Maciej Fijalkowski wrote:
>
> I would like to point out that instructing people does not really
> work. Besides, other examples like this:
>
> if d[x] >= 3:
>d[x] += 1 don't really work.
That's a good point. But then, perhaps PyPy should analyze the __eq__
On 03/18/2014 10:19 PM, Paul Moore wrote:
Surely in the presence of threads the optimisation is invalid anyway
Why? As written, the code uses no synchronization primitives to ensure
that the modifications to the dict are propagated at a particular point.
As a consequence, it cannot rely on th
On Wed, Mar 19, 2014 at 2:42 PM, Antoine Pitrou wrote:
> On Tue, 18 Mar 2014 09:52:05 +0200
> Maciej Fijalkowski wrote:
>>
>> We're thinking about doing an optimization where say:
>>
>> if x in d:
>>return d[x]
>>
>> where d is a dict would result in only one dict lookup (the second one
>> be
On Tue, 18 Mar 2014 09:52:05 +0200
Maciej Fijalkowski wrote:
>
> We're thinking about doing an optimization where say:
>
> if x in d:
>return d[x]
>
> where d is a dict would result in only one dict lookup (the second one
> being constant folded away). The question is whether it's ok to do
On Tue, Mar 18, 2014 at 11:19 PM, Paul Moore wrote:
> On 18 March 2014 19:46, Maciej Fijalkowski wrote:
>>> A question: how far away will this optimization apply?
>>>
>>> if x in d:
>>> do_this()
>>> do_that()
>>> do_something_else()
>>> spam = d[x]
>>
>> it de
On 18/03/14 07:52, Maciej Fijalkowski wrote:
Hi
I have a question about calling __eq__ in some cases.
We're thinking about doing an optimization where say:
if x in d:
return d[x]
where d is a dict would result in only one dict lookup (the second one
being constant folded away). The ques
Kevin Modzelewski writes:
> I think in this case, though, if we say for the sake of argument
> that the guaranteed semantics of a dictionary lookup are zero or
I don't understand the point of that argument. It's simply false that
semantics are guaranteed, and all of the dunders might be user
f
On 19 March 2014 11:09, Steven D'Aprano wrote:
> Although I have tentatively said I think this is okay, it is a change in
> actual semantics of Python code: what you write is no longer what gets
> run. That makes this *very* different from changing the implementation
> of sort -- by analogy, its m
I think in this case, though, if we say for the sake of argument that the
guaranteed semantics of a dictionary lookup are zero or more calls to
__hash__ plus zero or more calls to __eq__, then two back-to-back
dictionary lookups wouldn't have any observable differences from doing only
one, unless y
On 3/18/2014 9:09 PM, Steven D'Aprano wrote:
Currently, the code:
if key in dict:
return dict[key]
performs two dictionary lookups. If you read the code, you can see the
two lookups: "key in dict" performs a lookup, and "dict[key]" performs a
lookup.
The doc says that
@deco
d
On Tue, Mar 18, 2014 at 04:42:29PM -0700, Kevin Modzelewski wrote:
> My 2 cents: it feels like a slippery slope to start guaranteeing the number
> and ordering of calls to comparison functions -- for instance, doing that
> for the sort() function would lock in the sort implementation.
Although I a
My 2 cents: it feels like a slippery slope to start guaranteeing the number
and ordering of calls to comparison functions -- for instance, doing that
for the sort() function would lock in the sort implementation. It feels
like the number/ordering of the calls should be "implementation-defined" in
On 18 March 2014 19:46, Maciej Fijalkowski wrote:
>> A question: how far away will this optimization apply?
>>
>> if x in d:
>> do_this()
>> do_that()
>> do_something_else()
>> spam = d[x]
>
> it depends what those functions do. JIT will inline them and if
> the
On Tue, Mar 18, 2014 at 4:21 PM, Steven D'Aprano wrote:
> On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote:
>
>> note that this is specifically about dicts, where __eq__ will be
>> called undecided number of times anyway (depending on collisions in
>> hash/buckets which is implem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/18/2014 07:18 AM, Steven D'Aprano wrote:
> Nevertheless, an __eq__ with side-effects is legal Python and may in
> fact be useful.
E.g., for an LRU usecase.
Tres.
- --
===
Tres S
On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote:
> note that this is specifically about dicts, where __eq__ will be
> called undecided number of times anyway (depending on collisions in
> hash/buckets which is implementation specific to start with)
Exactly. Using a __eq__ metho
On Tue, Mar 18, 2014 at 1:18 PM, Steven D'Aprano wrote:
> On Tue, Mar 18, 2014 at 05:05:56AM -0400, Terry Reedy wrote:
>> On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote:
>> >Hi
>> >
>> >I have a question about calling __eq__ in some cases.
>> >
>> >We're thinking about doing an optimization where
On Tue, Mar 18, 2014 at 05:05:56AM -0400, Terry Reedy wrote:
> On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote:
> >Hi
> >
> >I have a question about calling __eq__ in some cases.
> >
> >We're thinking about doing an optimization where say:
> >
> >if x in d:
> >return d[x]
>
> if d.__contains__(
On Tue, Mar 18, 2014 at 11:35 AM, Nick Coghlan wrote:
> On 18 March 2014 17:52, Maciej Fijalkowski wrote:
>> Hi
>>
>> I have a question about calling __eq__ in some cases.
>>
>> We're thinking about doing an optimization where say:
>>
>> if x in d:
>>return d[x]
>>
>> where d is a dict would
On 18 March 2014 17:52, Maciej Fijalkowski wrote:
> Hi
>
> I have a question about calling __eq__ in some cases.
>
> We're thinking about doing an optimization where say:
>
> if x in d:
>return d[x]
>
> where d is a dict would result in only one dict lookup (the second one
> being constant fol
On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote:
Hi
I have a question about calling __eq__ in some cases.
We're thinking about doing an optimization where say:
if x in d:
return d[x]
if d.__contains__(x): return d.__getitem__(x)
I do not see any requirement to call x.__eq__ any particula
Hi
I have a question about calling __eq__ in some cases.
We're thinking about doing an optimization where say:
if x in d:
return d[x]
where d is a dict would result in only one dict lookup (the second one
being constant folded away). The question is whether it's ok to do it,
despite the fact
35 matches
Mail list logo
