On Jul 4, 2:10 pm, Paul Rubin <http://phr...@nospam.invalid> wrote: > Simon Forman <sajmik...@gmail.com> writes: > > > if not (self.higher and self.lower): > > > return self.higher or self.lower > > > That would work too in this case, both higher and lower are expected > > to be either None or an object (that doesn't override the default all- > > objects-are-true rule.) > > -1.
Heh heh heh, I figured someone might call me on this, but I stopped short of adding further elucidation to that parenthetical clause. What I meant (of course, *wink*) was "...an instance of a user-defined class that doesn't override the special double-underscore methods in a way that causes it (the instance) to be considered False in a 'boolean context', as they say in perl." In [1]: class bar: pass ...: In [2]: b = bar() In [3]: bool(b) Out[3]: True > Objects can support methods like __bool__, __len__ (a tree might use > this to compute the number of nodes or something like that), and > __nonzero__. If len(object)==0 then the object is treated as false. > So that test can fail if a __len__ method gets added to the tree class > sometime. Or you might decide you want to support empty trees which > would test as false. Ya, that's exactly why I stuck to checking explicitly against None in that tree code. :] > Anyway, Python's overloading of bool(...) is yet another misfeature > and although it's convenient, the "explicit is better than implicit" > principle indicates to avoid that sort of trick. I really like the "misfeature" myself. Python (to me) seems to relieve you of gory details that get in the way (compare equivalent C+ + and Python code) but still exposes you to gory details that, with care in coding, can make your code easier to grok and more elegant in general. BTW, Paul, kind of a tangent: I reimplemented the same algorithm but using tuples instead of instances (and empty tuples for "NULL" values.) I was trying to mess around in the space you seemed to indicate existed, i.e. a better implementation using other datatypes, but I didn't have a clear idea what I was doing and, as I said, I started by simply re-implementing with a different datatype. Much to my surprise and delight, I discovered the tuple-based BTree was /already/ a "persistent data type"! It was both awesome and a bit of an anti-climax. :] -- http://mail.python.org/mailman/listinfo/python-list