question of style

Simon Forman sajmikins at
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> 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 " 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

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 mailing list