[Fwd: Re: DB-API format string conventions]

[Steve Holden]

[posted after mailing response in error]

Craig Ringer wrote:

> On Tue, 2004-12-28 at 21:16, Steve Holden wrote:
> 
> 
>>>So ... anybody for a DB-API 2.1 with mandatory pyformat support and a
>>>tuple dbmodule.paramstyles for supported styles?
>>
>> 
>>Well, you can certainly put me down as supporting less variability in 
>>allowed paramstyles, to the extent that it would allow much more 
>>application portability.
>>
>>However, you might not be aware that the reason that variability was 
>>included in the first place is to allow Python module authors to take 
>>advantage of features already available in the various underlying 
>>database platform support code - Oracle, for example, already supports 
>>numbered access (:1), and so on.
> 
> 
> I'm not actually against the number of choices available, I'm just
> concerned that there is currently no _single_ choice that can be
> guaranteed to work, and that it's hard to identify all styles a given
> API supports.
> 
> Of course, even if one does confine ones self strictly to what can be
> guaranteed to work in the DB API, there are a multitude of differences
> in database SQL syntax and extensions to worry about. That is an issue
> any programmer will face - not just a Python DB-API 2.0 user, and I see
> it as a separate issue. Tackling that would involve building a DB
> abstraction layer like the various query builders available for Java - a
> very interesting, but much bigger, job that I'm not even remotely
> interested in looking at right now ;-)
> 
Though you might care to look at Chapter 11 of "Python Web Programming"
when you have time, where I had a go at such an abstraction layer. It
was moderately successful across a number of platforms.
> 
>>So be aware that you are asking the various module authors for 
>>significant amounts of work, which may not be forthcoming under all 
>>circumstances.
> 
> 
> That's true, and something I'm keeping in mind. I'd be quite happy to
> implement the required changes for modules I'm familar with to help with
> that issue.
> 
That's good.

> That said, if pyformat was chosen as the required style it might not be
> too big a job at all. Many modules already support pyformat though not
> all advertise the fact, and for them it may be as simple as bumping the
> API version to 2.1 and adding a module-level var containing a tuple of
> all supported styles.
> 
We can but hope. I'm afraid I'm less optimistic than you, but this lack
of optimism shouldn't be allowed to restrain your enthusiasm.

> 
>>Also be aware that there have been various post-2.0 proposals for the DB 
>>API, which you might want to look up on Google and fold in to the 
>>current campaign.
> 
> 
> Indeed. I went looking for proposals specifically related to argument
> handling earlier, but still need to have a look for other API revision
> proposals.
> 
> I thought it best to ask here to find out how much interest there would
> be in clarifying the API and adding a required format style before going
> ahead with actually writing a few patches and a draft PEP for comments.
> 
Well, let's hope I'm not the only one to respond, then. Since the push
for 2.5 is allegedly to improve the standard library, it would be great
if we could improve the portability of the DB API as well.

I'd personally be in favor of trying to include a number of database
modules either in the standard library or in a package that could easily
be added in a lump. Go to it, and good luck - let me know when you need
help.

regards
  Steve

-- 
Steve Holden               http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC      +1 703 861 4237  +1 800 494 3119



-- 
Steve Holden               http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC      +1 703 861 4237  +1 800 494 3119