In article <[EMAIL PROTECTED]>, Alex Martelli wrote: >Derek Peschel <[EMAIL PROTECTED]> wrote:
>> They are the same except for the expression in "for key in ...". Can they >> be combined into one function? How can I determine if the argument is > >They can easily be refactored, if that's what you mean: No, that isn't what I mean. I wanted _one_ function that works with a wide variety of objects -- anything that has a finite number of keys you can iterate over, with each key mapping to a finite number of values, and the key iteration and value lookup referentially transparent. This hypothetical function would have to do some checking of the argument type, but hopefully as little as possible. It should work with object types invented after it was written. Reading everyone's replies, especially yours and Fredrik Lundh's, I realized I've been thinking of the whole problem in Smalltalk (or possibly Ruby) terms. Smalltalk and Ruby use inheritance to describe some properties of objects. Python has many primitive types that aren't related to eaach other. I thought that testing for methods might get the properties I wanted, but you two pointed out that the method writer has too much latitude. Do you think the generic-function idea is still useful? At the moment I only need to invert dicts and lists. Is subclassing dict and list considred good style? (I see I can't add methods to dict and list directly.) >I've also performed a few other minor enhancements (never name things >dict or list because that hides the builtin types, use xrange vs range). OK, I'll remember those points. The argument names are a style I got from my Ruby code, and possibly not a good idea there either. >I have not changed the 4 lines in the if/else though I don't like them >(if not.../else is a very confusing construct -- at a minimum I'd >rephrase it as if/else swapping the bodies of the two clauses). It used if/else originally. Then I swapped the parts of the conditional to make the inversion function match another function (that takes a key, old value, and new value, and makes the change in a sequence and in its inverted form). To me the swapped version made some sense in the second function, because of the layout of the function as a whole, but you have a point that if not/else is rarely (never?) clear. >If you want to add a generic form accepting either lists or dicts you >need a try/except statement inside it, e.g.: Is that a reliable way to get the properties I wanted? RADLogic Pty. Ltd. added a two-way dict package to the Cheese Shop. It requires that the mapping be one-to-one, which won't work for me. It sub- classes dict, and requires that keys and values be hashable. -- Derek -- http://mail.python.org/mailman/listinfo/python-list
