Steve Holden sholden at
Thu Feb 7 16:49:24 EST 2002

"Mark McEahern" <marklists at> wrote in message
news:mailman.1013099052.17373.python-list at
> Steve Holden wrote:
> > Since the *intent* for None is that there should only ever be one
> > object of type None, the better test would be
> >
> >     if something is None
> Thanks, that's how I generally test for None--I didn't know the bit about
> "there should only ever be one."
Well, all I really meant was that binding another name or reference to None
doesn't create a new one. The ref man says in section 3.2

This type has a single value. There is a single object with this value. This
object is accessed through the built-in name None. It is used to signify the
absence of a value in many situations, e.g., it is returned from functions
that don't explicitly return anything. Its truth value is false. """

> However, you wrote:
> > which can easily be used without requiring any changes to FixedPoint.
> Well, sure, I could easily change my local copy of PyPgSql's
> it seems like in this case it makes more sense for me to change my local
> copy of  Hmm, I'm having a hard time articulating *why*
> though.  I guess because we use PyPgSql more, it's actively maintained,
> etc.--I'm better off not maintaining our own branching of that code.
Oh, no, don't go changing other modules to fix this. Hadn't read your post
carefully enough to realize your problems were occurring with database

> Of course, I could ask the PyPgSql folks not to test for None like that.
> But then they're going to say, "how's the bug actually happening?"  And
> going to have to tell them I'm sending a FixedPoint instance as a param to
> cursor.execute().  And *that* only works because I modified's
> __repr__ to return str(self).  As you can tell, at the moment, I'm just
> flying by the seat of my pants trying to make something work.
Hmm. Really what's needed is an extension to PyPGSql's NUMBER type object,
but I don't think the maintainers will want to start getting involved in
special cases.

> > Good general rule: if Tim made it that way, it's supposed to be
> > that way :-)
> I tend to agree.  However, do you think he purposefully avoided making the
> code resilient to frippery like this?
> if FixedPoint(1.0) == None:
> ...
> Should it be resilient to code like that?  In the case of PyPgSql, one
> argue I'm using it incorrectly by passing it a FixedPoint to squirt into
> db.  But then that merely means I haven't framed my question correctly.
Equality to None is something pretty basic, and should be easy to test for.
You have my permission (like you need it) to fix FixedPoint :-0

I think we might admit that Tim's code was insufficiently polymorphic with
the built-in numeric types here.

but-he-knows-where-i-live-so-i'm-saying-it-quiet-ly y'rs  - steve
Consulting, training, speaking:
Author, Python Web Programming:

"This is Python.  We don't care much about theory, except where it
intersects with useful practice."  Aahz Maruch on

More information about the Python-list mailing list