.dbf tables and Null

[Ethan Furman]

John Machin wrote:
> On Aug 1, 3:41 am, Ethan Furman <et... at stoneleaf.us> wrote:
> 
>>Mornin'!  and a good one, too, I hope.
>>
>>Question for you...
>>
>>First part of the question:  What is the general value in having Null
>>capability for fields?
> 
> 
> In general, in any database system, so that one can distinguish
> between "the customer has no 'middle name'" ('') and "the customer's
> 'middle name' is unknown" (NULL).
> 
> 
>>Second part:  Is there a tangible difference between Null, and the
>>nothing of 0, '', False, etc, in python?
> 
> 
> 0 is the zero thing, it is not nothing. False is not nothing.
> 
> 
> 
>>Third part:  If there is a tangible difference, do those of us who use
>>python and these old, refuse-to-die, .dbf files actually have need of,
>>or have tables including, Null values?
>>
>>P.S. part (for John Machin, if he sees this  ;)
>>Will the dbf package you are working on support Null values?
> 
> 
> My philosophy when digging stuff out of arcane storages is to expose
> what is found and leave any kludging/sanitising to the next layer.
> 
> For example, None is returned for an N (Number) field that's all
> spaces; it's up to the caller to decide whether to treat None as zero,
> raise an exception, pop up a data-collection dialogue box, ...
> 
> If you mean specifically the Visual Foxpro v3 _NullFlags hack, yes, it
> already supports that, as well as the VFP9 abuse of that hack for
> Varchar and Varbinary fields :-)

Thank you.

It's been an interesting journey learning Python.  Probably the two most 
difficult concepts for me to really internalize have been "batteries 
included" (thank you for the pointer to struct!) (I finally 'found' and 
incorporated array into my dbf module), and "everything is an object, 
even functions!".

The unittest module worked wonderfully in making sure everything still 
worked after switching over to array as well, and the 30+% speed-up is 
also nice!  :)

All in all, I *love* Python!

~Ethan~