On Tue, Jul 19, 2011 at 8:41 PM, Ethan Furman <et...@stoneleaf.us> wrote: > Carl Karsten wrote: >> >> 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. > > Thanks for the clarification, Carl. > >> For D/T I am not sure you have a choice. What value would you return >> for an empty date other than Null? > > As it happens, I created custom Date, Time, and DateTime objects so that I > could deal with the empty values. I probably just should have returned None > from the beginning, but did I mention that this is the project I have > learned Python with?
Impressive! > > Now that I have them, I'm thinking of keeping and continuing to use them for > the empty case... but not sure if that's a great idea, hence my question > here. I would say supporting Empty is a backwards compatibility thing: If there was code that relied on it, then you should continue to support it. When I was using VFP I never needed both values. My guess is the custom objects will cause problems and solve none. > >> 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. > > The test I tried before I left work seems to confirm that (it was just > printing). -- Carl K _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
