[DB-SIG] Re: [Python-Dev] Toward Python's future article

[Keating, Tim]

Chris Cogsden wrote:

> In my humble opinion, and with all the proper deference to those that 
> have written excellent and useful code, I disagree (and have always,
in 
> the past on this list) with the above two statements.
>
> Giving the module author a choice in implementation is great, but
given 
> them a choice in the data-type being returned just pushes the problem 
> of dealing with differing data types onto the application writer.
> 
> Making things 'easy for the module writer' is well and good... it gets

> a useful module out there quicker and with fewer bugs, but this makes 
> it harder for the application writer, and I don't think that should be

> the focus. After all, the 'hard job' of writing the module is only
done 
> once (or, really, just a few times, for each database type and each 
> person that decides to put the effort in to create a variation), but 
> the job of writing applications is done over and over.
> 
> I think it SHOULD BE the job of the module writer (whether it's a DB 
> interface, or an interface to the operating system) to deal with all 
> the vagaries of the underlying layers and present a consistent (as far

> as possible) interface to the application writer. I appreciate that 
> this is much harder with something like a DB interface, but for 
> something as simple as date/time return types, it should be mandated.
> 
> Otherwise, it's like saying "the module writer has the choice of 
> returning integer values as a int, long, or a string, and it's up to 
> the application writer to deal with it".

Well said. This was my reaction, as well. Probably because I'm one of
those "application writers" people keep talking about.

<goes back to lurk mode>

TK