On 2004 Jan 20, at 19:32, Raymond Hettinger wrote:
...
> d = {}
> d.setfactory(list)
> for k, v in myitems:
> d[k].append(v) # dict of lists
>
> d = {}
> d.setfactory(set):
> for v in mydata:
> d[f(v)].add(v) # partition into equivalence classes
>
> d = {}
> d.setfactory(int):
> for v in mydata:
> d[k] += 1 # bag
Yes, except that a .factory property seems preferable to me to a
.setfactory setter-method (which would have to come with .getfactory or
equivalent if introspection, pickling etc are to work...) except
perhaps for the usual "we don't have a built-in curry" issues (so
.setfactory might carry arguments after the first [callable factory]
one to perform the usual "ad hoc currying" hac^H^H^H idiom). In fact
I'd _love_ this approach, were it not for the fact that in some use
cases I'd like the factory to receive the key as its argument. E.g.:
squares_of_ints = {}
def swe_factory(k):
assert isinstance(k, (int, long))
return k*k
squares_of_ints.setfactory_receiving_key(swe_factory)
Alex
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