Dear folks,
Carsten Haese wrote:
On Thu, 2007-05-31 at 10:44 -0400, Art Protin wrote:
I guess I am expected to weigh in and make perfectly clear where I
stand.
"Expected" may be too strong a word, but yes, input from as many
interested parties and API module maintainers as possible is helpful to
measure consensus.
[snip...]
If I summarized that correctly, you are in favor of requiring qmark,
named, and numeric, and dropping format and pyformat.
I could live with that. As I said before, InformixDB already supports
all three styles, so whether named/numeric are optional or required
makes no difference to me. I'm concerned that requiring named/numeric
might encounter more resistance than requiring qmark, but so far I
haven't seen such resistance on this thread.
As for a switching requirement: how does this sound (I just though of
it this morning)
making the parameterstyle depend on the first character of the SQL
statement.
If it is a colon, remove it and the parameter style is either numeric
or named; if it is
not a colon, the parameter style is qmark.
Sorry, I give that a -1. Using "magical characters" is utterly
unpythonic, and somebody reading the code would have no clue what's
going on.
A sensible switching mechanism should look something like this, in my
opinion: Add optional 'paramstyle' keyword arguments to
module.connect(), connection.cursor(), cursor.execute() and
cursor.executemany(). In the absence of a 'paramstyle' argument,
individual executions inherit the cursor's paramstyle, cursors inherit
the connection's paramstyle, and connections use the module's read-only
paramstyle attribute as default. (As discussed before, allowing the
module-wide paramstyle to be changed is IMO a bad idea.)
First, I must confess. I do not know how to make a module's attributes
read-only.
I do know how to make classes where object instances have read-only
attributes.
Optional keyword arguments are a very good approach & I do like the
inheritance scheme. Would it make sense for paramstyle to be an attribute
of connection and cursor, that could be read and written?
(As for changing the module-wide paramstyle, you have persuaded me that
that approach is "sub-optimum". I do expect that I will at least have
to add
a superior way and change the documentation to point users at the better
way.)
Then again, I'm not too excited about the whole idea of manual
switching. I'd prefer auto-detection based on whether the query string
contains question marks, colon+number or colon+identifier markers
outside of string literals. Not only because that is what InformixDB
already does, but because it leads to cleaner code.
I would like autodetection, even prefer autodetection, if I was sure
that it would
work correctly every time no matter what. I am getting more comfortable
with
that hypothesis, but have not yet developed a proof that autodetection
could not
get spoofed.
In absense of such a proof, I prefer to have the user (even when that
user is me)
declare what is expected and have the module check as best it can and
complain
when the expectations are not met.
If such a proof was included in the spec., then .paramstyle could be
eliminated
(and that would be good).
Best regards,
[[ why does my email agent seem to discard your signature ??? ]]
Thank you all,
Art Protin
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
