[DB-SIG] Remaining issues with DB API 2.0
Thu, 1 Apr 1999 00:48:48 -0500 (EST)
On Wed, 31 Mar 1999, Greg Stein wrote:
> However, I do believe that MySQL can always take a fully-qualified
> date/time and will trim it back as necessary. This implies a single
Apparently not totally true. M-A and I tested this, and if you pass MySQL
a TIMESTAMP with a fractional seconds part, it treats that as an illegal
value and sets it to zero. Nuisance. This is true at least with 3.22.19a.
I have not tested against 19b.
> I would like to see a stated preference for 'numeric', 'named', and/or
> 'pyformat'. They are marginally clearer, and easier to use.
Are there any databases where the parameter marker is actually an option?
I suppose you could use whatever you wanted for MySQL, but it is vastly
easier to use 'format' and/or 'pyformat'.
> The client should not be required to "escape" the value so that it can
> be used -- the value should be equal to the actual database value."
I.e., the module should do any escaping, correct? If true, I agree.
> I'd say we make two subclasses of Error: InterfaceError, and
Speaking of which, I can't find a obvious way in the Python API to create
an exception with multiple inheritance. Any ideas?
> > > * in all methods that state "an exception is raised..." we should state
> > > *which* exception. We have a complete set defined at the beginning, so
> > > this makes sense to do. I would recommend InterfaceError (it is based on
> > > the interface we provide, rather than the underlying database). Hrm.
> > > Maybe not. I can see a case where the DB module will simply attempt to
> > > call the underlying DB function and generate a DB-related exception.
> > > Thoughts anyone?
> > This is hard to do, since the types of errors may very well be
> > the whole range of possible Python exceptions + the ones defined
> > in the DB API, e.g. a conversion routine might raise an OverflowError
> > in case of numeric overflow while raising an InterfaceError in
> > case a certain internal assertion failed.
> Good point. I retract my request :-)
This is why I would like to find a way to do multiple inheritance on
exceptions in the Python C API...
> New comment: should we change the globals to be: apiLevel, threadSafety,
> and paramStyle? Or maybe underscore-separated? Or leave them? hmm... I
> think "Python style" says all lower-case for these, mixed signal on the
> underscore. Thoughts?
My reading of the style guide suggests lower-case, no underscores.
Andy Dustman (ICQ#32922760) You should always say "spam" and "eggs"
ComStar Communications Corp. instead of "foo" and "bar"
(706) 549-7689 | PGP KeyID=0xC72F3F1D in Python examples. (Mark Lutz)