[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-3000
Subject:    [Python-3000] Detecting conflicts in dict displays
From:       jcarlson () uci ! edu (Josiah Carlson)
Date:       2006-07-28 22:15:38
Message-ID: 20060728151056.E61A.JCARLSON () uci ! edu
[Download RAW message or body]


"Stian Soiland" <stian at soiland.no> wrote:
> 
> On 7/11/06, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> > >>> d={1:'one', 1.0:'one'}
> > >>> d
> > {1: 'one'}
> 
> This highlights the problem. Imagine that you don't type out the
> actual objects, but just receive them:
> 
> def make_dict(x, y, obj):
>     return {x: obj, y: obj}
> 
> x1 = x2 = "fish"
> d = make_dict(x1, x2, 1337)
> 
> 
> Here I don't really care if a and b are the same or not, I just care
> that I can do d[x1] and d[x2].
> 
> (Of course this is a dangerous path to go down too deep, what about
> del d[x1] ? And who would make such code, anyway?)
> 
> 
> Maybe only for the literal values and direct variable names..?
> 
> Is the following behaviour as expected, or is it just The Lock?

It's not related to the GIL at all, it just happens that dict creation
occurred within an entire bytecode 'time slice' (sys.get/setcheckinterval()).


>>> def foo():
...     x = {count-1+1: 1, count: 2, count-1+1: 3, count: 4, count: 5,
... count:6, count: 7, count: 8, count-1+1: 9, count: 10, count: 11}
...     while len(x) == 1:
...             x = {count-1+1: 1, count: 2, count-1+1: 3, count: 4,
... count: 5, count: 6, count: 7, count: 8, count-1+1: 9, count: 10,
... count: 11}
...     return x
...
>>> foo()
{149703626: 11, 149703605: 1}

 - Josiah


[prev in list] [next in list] [prev in thread] [next in thread]