On Jul 9, 2007, at 4:56 PM, Rick Morrison wrote:
> The nature of that kind of automatic typing sounds a lot like the
> job of parsing command line options to me. Maybe we can use a least
> a bit of the optparse or getopt module, or at least follow that
> pattern, and have each Dialect & etc. provide a list of options
> they're interested in along with the expected type. The list of
> options then passed to that object would then be limited to that
> list of options, so that will help to eliminate potentially
> confusing options as well.
>
ugh...i was so happy that Dialect could be written with normal
keyword arguments. while i want "comprehensive", i didnt
necessarily want to require a "getopt" layer for every dialect (as
well as every Engine class, every Pool class, etc).
cant we just agree that the only three types we want on the query
string are string/int/boolean ? if you need to send a callable
argument in, clearly that cant be embedded in a query string unless
you wanted to eval() something, which i think is beyond overkill.
> Note that we haven't yet addressed the namespace collision issue
> head-on yet. Any insights there, beyond "prefixes are ugly"?
if a known collision exists, then the dialect constructor specifies a
prefixed keyword argument for that particular option, and installs it
in its get_dbapi_options() result. so the dialects do prefixing for
known conflicts only. (as usual, there is still connect_args={} too)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
