[DB-SIG] DB API 2.0... what about NULLs ?

Andy Dustman adustman@comstar.net
Wed, 14 Apr 1999 15:06:29 -0400 (EDT)


On Wed, 14 Apr 1999, M.-A. Lemburg wrote:

> Here is the text I'd like to add to the Type Objects section:
> 
> """
> NULL 
>      SQL NULL values are represented by the Python None singleton
>      on input and output. NULL is an alias for None that the module must
>      define if the database supports NULL values. 
> """
> 
> This has the added advantage of being able to check for NULL
> support via hasattr(), e.g. Gadfly should not define it.
> 
> If nobody objects, I'll update the spec on starship later today.

I'll object, for reasons stated earlier: The interface should require None
to be the Python equivalent of NULL. Having more that one way to specify
NULL values which may or be not be present in a given interface seems to
be a good way to create portability problems. This is an even more serious
problem than having connect() parameters being interface-dependent (though
that one is unavoidable and can be fixed in one place in an application
generally). Plus, MySQLdb would run afoul of it, since it defines NULL =
'NULL', but if an application were to see it and make use of it, it would
be writing the string literal 'NULL' instead of the token NULL. (Actually,
I could be NULL = None in my Python layer, but I really think this is a
bad idea.)

Drop the "NULL is an alias for None" bit and I'm happy.

-- 
andy dustman  | programmer/analyst |  comstar communications corporation
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d