[Python-Dev] collections module

[Martin v. Loewis]

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