question of style
sajmikins at gmail.com
Sat Jul 4 16:05:36 EDT 2009
On Jul 4, 2:10 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Simon Forman <sajmik... at 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.)
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 : class bar: pass
In : b = bar()
In : bool(b)
> 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
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. :]
More information about the Python-list