Alex Martelli wrote: > > 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 This could be seen as favouring the protocol approach that Bob suggested. In that approach, the 'defaulting' is done by having dict access call __getdefaultitem__ if it exists, and the item being looked up is not found. The signature of __getdefaultitem__ is the same as that for __getitem__. If __getdefaultitem__ isn't found, then the current behaviour of raising KeyError is retained. I suspect the aim of this approach would be to reduce errors by avoiding rewriting the 'try/except KeyError' block everytime we wanted a defaulting dictionary. I imagine it could be made faster than the current "k in d" or "try...except Keyerror..." idioms, too. The more I think about it, the more I'm leaning towards the class-based approach - the version with 'factory' or 'setfactory' seems to lend itself to too many dangerous usages, especially: d = {} ...do some stuff... [A] d.factory = factory_func ...do some more stuff... [B] The meaning of d[k] is significantly different in section A than it was in section B. Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan at email.com | Mobile: +61 409 573 268
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