[Python-Dev] collections module
Martin v. Loewis
martin at v.loewis.de
Sat Jan 10 17:11:31 EST 2004
Raymond Hettinger wrote:
> If lambda is made parameterless, it allows type constructors to be used
> for the most common cases:
> dict(default=list) # this is clear enough
> dict(default=int) # this may be too cute
A keyword parameter is a good idea - I had problems calling it
"default", though, as it would give the impression that you specify
the default value.
> Or, lambda could be avoided altogether by cloning a default value
> dict(default=) # individual default values computed by
This might work, but it would make copy.copy() part of the
dictionary semantics, whereas at the moment copy is just
>>Having a key in the lambda is probably better, as it would
>>also allow lazily-filled dictionaries.
> Can you give an example?
We once had the need to evaluate code in an "unbounded"
context, i.e. where it is not possible/efficient to compute
a list of all variables upfront.
So in principle, we would have done
def __getitem__(self, key):
exec some_code in D(params)
except that instances of D() could not have been passed
to exec/eval - this requires a "true" dictionary.
I see that Python now allows to use D as the dictionary,
but still won't use __getitem__ to find values.
In the specific example, the "unbounded" context was
a CORBA namespace, for which we new that the bindings
would not randomly change. So we would very much have
liked a lazy filling of the dictionary - each access
to an uncached value is a roundtrip on the wire.
With a default value function, we could have done
exec some_code in dict(default=compute_value)
We ended up analyzing the code to find out what variables
are referenced, and prefetch those into a proper dictionary.
More information about the Python-Dev