On Tue, Jul 19, 2011 at 6:39 PM, Ethan Furman <et...@stoneleaf.us> wrote: > Greetings, > > I am finally adding Null support to my dbf package > (http://pypi.python.org/pypi/dbf) and, as usual, the VFP side is being a > pain. > > The issue is that the Logical, Date, and DateTime field types, even when the > table does not allow Null values, can be empty -- and when Null values are > allowed, those fields can be empty or Null. (Empty pretty much meaning not > initialized -- neither True nor False, and no Date nor Time.) > > At this point, also, my module does not support the DB API (that is a goal > though), so right now you pretty much get direct access to the physical > table. > > My question: for the direct access side, is there any advantage to treating > an empty L, D, or T field differently from a Null L, D, or T field? Or > should they be semantically the same, always returning, for example, None > whether it's actually Null in the table or just empty?
for those of you that are wondering about this nuttyness: VFP is a dBase derivative. In there early days, there was no support for Null. But a side effect of adding a row but not storing values to it was empty fields. the best example is a date. dates are stored on disk as a string "YYYYMMDD" and in the case of an empty date: " ". Same with numbers: N(6,2) would store 3.14 as " 3.14" and an empty number was " ". Then they added Null support, but instead of using this empty state, they added a flag, so now a field could be Null, Blank or have a value. which was a mistake, but here we are. For D/T I am not sure you have a choice. What value would you return for an empty date other than Null? for Logical I would return False. Mainly because I am pretty sure that because in VFP an empty logical will be treated as .f. anywhere a logical is evaluated. -- Carl K _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
