Re: [SQLObject] Default Behaviour when notNull == False

On Wed, 2003-04-30 at 15:54, Ian Bicking wrote:
> It was my intention to make the default explicit, even if it isn't
> explicit in SQL, so default=None does what Brad wants.  I can see why it
> would be inconvenient, but only slightly, and I think that's countered
> by it being a useful discipline (and more closely matching Python, which
> doesn't use implicit defaults).

But on the other had, I think he has a point about the notNull field. 
And we are getting back to Pythonic vs. SQL naming conventions.  IMHO,
being of little weight since I've only recently stuck my nose in, I
think your class definitions should look like SQL, while class *usage*
should look like Python.  Because, chances are the designer knows much
about SQL and will be easy to generate those classes from schema
knowledge, while your end API user may (probably) doesn't know (or need
to know) about the schema structure or even SQL for most things.  Plus,
it'll make the whole thing easier to debug from a mapping point of view.

Maybe the constructor should map a default of None automatically if
notNull is False and there is no default specified.  In that case,
though I would think you would still want notNull to default to True
rather than False.  In other words, I think it's just wierd to stipulate
that if you have to say default=None if you've already specified
notNull=False.

Nick