I think of an upcast as casting to the base-class (casting up the inheritance tree). http://en.wiktionary.org/wiki/upcast But really, what I am thinking of doing is overriding the virtual methods of a derived class with the base class behavior in an object that I can then pass into methods that are base/derived agnostic.
defaultdict is the way to go. W <ps> <rant> Sadly, there are guidelines that I program by that are perhaps anti-pythonic: 1. Don't use "extra" variables in code. Don't use global variables. Keep the scopes of local variables at a minimum to reduce state (the exception being for inner loops) or variables explicitly identified as part of the algorithm before implementation. [In python, just about everything is a variable which is terrifying to me. I never want the Alabama version of math.pi i.e., http://www.snopes.com/religion/pi.asp, or math.sin being "666".] 2. Use built-in functions/features as much as possible, as this are the most tested. Don't roll your own -- you're not that good, instead master the language. (How often do I invent a noun in English? Not even "upcast"!) [Plus, guys with phds probably already did what you need.] Use only very well known libraries -- numpy is okay (I hope!) for example. An exception can be made while interfacing external data, because others who create data may not have abided by rule #2. In most cases (except gui programming, which again tackles the external interfacing program) the more heavy-weight your API, the more wrong you are. 3. In interpreted languages, avoid function calls, unless the function does something significant. [e.g., Functional call overhead tends to be worse that a dictionary lookup -- and yes I used timeit, the overhead can be 100%.] Small functions and methods (and callbacks) hamper good interpreted code. When writing functions, make them operate on lists/dicts. It is because of the above that I stopped writing object-oriented Perl. So I want "big" functions that do a lot of work with few variable names. Ideally, I'd create only variables that are relevant based on the description of the algorithm. [Oh yeah, real programming is done before the implementation in python or C++.] My problems are compounded by the lack of indention-based scope, but I see this as simply enforcing the full use of functional-programming approaches. </rant> </ps> On Sat, Jul 31, 2010 at 5:55 AM, Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > On Sat, 31 Jul 2010 01:02:47 -0400, wheres pythonmonks wrote: > > >>> Hint -- what does [].append(1) return? >>> >>> >> Again, apologies from a Python beginner. It sure seems like one has to >> do gymnastics to get good behavior out of the core-python: >> >> Here's my proposed fix: >> >> m['key'] = (lambda x: x.append(1) or x)(m.get('key',[])) >> >> Yuck! > > Yuk is right. What's wrong with the simple, straightforward solution? > > L = m.get('key', []) > L.append(1) > m['key'] = L > > > Not everything needs to be a one-liner. But if you insist on making it a > one-liner, that's what setdefault and defaultdict are for. > > > >> So I guess I'll use defaultdict with upcasts to dict as needed. > > You keep using that term "upcast". I have no idea what you think it > means, so I have no idea whether or not Python does it. Perhaps you > should explain what you think "upcasting" is. > > >> On a side note: does up-casting always work that way with shared >> (common) data from derived to base? (I mean if the data is part of >> base's interface, will b = base(child) yield a new base object that >> shares data with the child?) > > Of course not. It depends on the implementation of the class. > > > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
