question of style

[Simon Forman]

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.)
>
> -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. :]