[prev in list] [next in list] [prev in thread] [next in thread]
List: python-db-sig
Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article
From: TKeating () ea ! com (Keating, Tim)
Date: 2004-10-15 0:32:13
Message-ID: 25BCE2B1149CDA4E9758CC08E70A20A9FD6564 () eahq-mb1
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic