Sorry about the sporadic posts, I'm travelling > if we are going whole hog with query strings (basically we're talking > about adding pool options mostly), a comprehensive solution needs to > be added in DefaultEngineStrategy.
All that sounds fine, if Paul is still interested, I'll work with him on the implementation if he wants. > also, the system of > "typing" the string args would have to be more automatic than it is > now...id favor an auto-conversion that converts pure integer strings > to ints, "true"/"false" to True/False, and the rest stays as string. >this is so that writing a dialect doesnt require that you have to > interpret all the given kwargs among several types. 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. Note that we haven't yet addressed the namespace collision issue head-on yet. Any insights there, beyond "prefixes are ugly"? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
