[Python-Dev] collections module (original) (raw)

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 copy([]) dict(default=0)

This might work, but it would make copy.copy() part of the dictionary semantics, whereas at the moment copy is just a library.

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

class D(dict): def getitem(self, key): return compute_value(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.

Regards, Martin

More information about the Python-Dev mailing list