Maybe this is late, and the issues are already settled, but it seemed
that nobody spoke up for them, so I figured I ought to.
There are two downsides given for the format and pyformat
paramstyles. They are:
1) It confuses newbies, and they wind up building queries in Python
instead of using parameters.
2) You have to use '%%' to get a real '%' into the query.
#1 is a bad thing. But the reason it happens is because python
programmers are already familiar with the syntax from python. This is
a *good* thing. While being friendly to newbies is a good thing, it's
not clear to me that introducing yet another syntax that has to be
learned as a cure isn't worse than the disease. Sure, if you're a db
person instead of a Python person and the format is the one your db
uses, then this cuts the other way - but in that case, you should also
know the difference between using parameters and trying to build the
query from untrustworthy data yourself.
As for #2, yes, you have to use '%%' to insert a single '%'. How do
the other paramstyles deal with wanting to get their significant
character into the query? From reading the last few months of
archives, it seems that they don't. The db module author either
expects that that won't happen, or is expected to recognize those
characters in some db-dependent way. If the goal is to be able to
write code that will port between db modules - or even databases -
without modification, then having a defined way to deal with this
issue is clearly better than punting to the module authors. After all,
it's the latter that created the current situation.
As a final note, on backwards compatibility - that was amusing. The
two sides were trying to define two things with one definition. Let me
try with two definitions:
A module is backwards compatible if code that used the documented APIs
of the previous version of the module will work unchanged with the
current version.
A specification is backwards compatible if it is possible for an
implementation of the current version to be backwards compatible with
an implementation of the previous version.
I think both of these are desirable properties.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
