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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4