Python 3.0 - is this true?

rurpy at yahoo.com rurpy at yahoo.com
Mon Nov 10 15:45:19 EST 2008


On Nov 10, 1:21 pm, Steve Holden <st... at holdenweb.com> wrote:
> ru... at yahoo.com wrote:
> > On Nov 10, 8:57 am, Steve Holden <st... at holdenweb.com> wrote:
> >> Robin Becker wrote:
> > ...snip...
> >>> In old style python there was a sort of standard behaviour whereby None
> >>> was comparable with most of the other primitive types. That at least
> >>> allowed us to performs various stupid tricks with data. Unfortunately it
> >>> seems that None is no longer orderable even against itself.
>
> >>> Is there any advice on how to create N/A float or integer or string
> >>> values? I assume the DB api will continue to return None for null
> >>> columns no matter what the column type.
>
> >>> Presumably I can always define my own comparator which makes None < x
> >>> for all x!=None.
> >> Yes, you can (though that will mean subtyping the standard Python types
> >> and ensuring you use only the subtypes, not always easy to maintain).
>
> >> Of course, using SQL against a traditional RDBMS will not return rows
> >> with NULL values for salary in a query such as
>
> >>   SELECT name, address WHERE salary < 10000
>
> >> precisely *because* NULL (absence of value) does not compare with any
> >> value.
>
> > Huh?  Thats like saying it's ok if cmp raises an error
> > when comparing negative numbers because "abs(x)" always
> > return positive ones.  You will find plenty of cases
> > when db apps return NULL, e.g.:
>
> >   SELECT name, salary WHERE name LIKE 'Steven %'
>
> I'm not saying an RDBMS can't return NULL values. I am saying that
> comparisons with NULL return NULL, not true or false. SQL uses
> three-valued logic.
>
> > So you could say that 3.0 is forcing us to acknowledge database
> >> reality ;-)
>
> > (Again) huh?
> > Reality in databases is that NULL *is* comparable.
> > "NULL==something" returns False, it doesn't raise an error.
>
> That's at best misleading and at worst just plain wrong.

Yes, it's just plain wrong. :-(  You are correct that it
returns NULL not False.  Nevertheless, that typo does
not change my point that NULLs are comparable to other
values in SQL, in contrast to your original post that
seemed to be using SQLs NULL behavior as justification
for Py3K's making None not comparable to anything.



More information about the Python-list mailing list