Dear folks,
Carsten Haese wrote:
On Mon, 2007-06-04 at 12:13 -0500, Carl Karsten wrote:
Hmm, default style brings up a new issue:
If there will be more than one style, should there be a common
default?
No, the default will be implementation-defined for backwards
compatibility. There will be a common way of switching to the common
mandatory paramstyle.
might want to convey which paramstyles the module can accept. I see
two
options:
* Invent a new module attribute called paramstyles that is a list or
set
of supported paramstyles.
* Simply raise ValueError if the programmer requests an unsupported
parameter style.
I kinda think it been decided that the set of styles will be required
of all
modules. But given that it was never voted on, add it to the ballot.
I think we're more leaning towards making only one common style
mandatory, and allowing other styles as optional extensions.
The collective may be leaning toward a more status quo with allowing
other styles
as extensions, BUT I for one, strongly endorse forbidding whatever is
not required
in the the way of parameter styles (or at the very least dropping any
mention of any
parameter style that is not required). I do not care much about how
easy it is to
implement. I care more about how easy it is for users of the interfaces
to understand
and be able to "transfer" that understanding to another interface. The
users should
be able to know how to get the parameter style that they want to use
without having
to switch the DB backend and interface module to get it. To me, that is
the only
reason for a shared API, to allow the users to code to common standards.
If users can not code to a common standard with Python, they will
code to a common
standard with JAVA & JDBC.
Thank you all,
Art Protin
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
