Python 3.0 - is this true?

Steve Holden steve at holdenweb.com
Mon Nov 10 22:38:09 CET 2008


rurpy at yahoo.com wrote:
> 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.

Well I guess now I understand your real point that's fair enough.

regards
 Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/




More information about the Python-list mailing list