On Wed, Jul 20, 2011 at 10:58 AM, Ethan Furman <et...@stoneleaf.us> wrote: > Carl Karsten wrote: >> >> 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. > > > Okay, I think what I'll do is keep it simple by default: None will be > returned both for Empty and Null, and if None is assigned to a field it will > be written as either Empty, or Null if that field is Nullable. I'll keep the > custom objects around and provide a mechanism to specify which objects to > return based on field type/null status, so if anyone wants, for example, > Decimals instead of floats they can have them, or Empty/Null objects they > can have those too. > > Seem reasonable?
Yep. I was kinda thinking of keeping the empty-able objects around. I hate the idea of trying to document them; I hardly like trying to keep track of how VFP handles them :) -- Carl K _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
