>
>
> 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).



Well the enumeration of the options targeted for a specific class has to be
specified somewhere. Otherwise, we'll end up passing its constructor the
entire dictionary of options, and it will raise errors because of invalid
keywords.

If there's some way to sniff the keyword arguments for a Dialect, Engine or
Pool class, that could be used as the list. But to me, sniffing the keyword
arguments is more fragile than just asking the instance for them, and if
you're going to ask for them, why not specify the type  as well?


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.



Yeah callables and such are way out of scope here. Any arguments specified
in a dburi ought to be simple types that can be easily specified in a string
format. The string/int/boolean scheme sounds reasonable enough, but having
the parser guess at which to produce is bound to have it guess wrong on
occasion.


>
> 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)
>

That works.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to