Yes, that's the idea: an alternative. Something like: <code> try: import theDriverUsuallyUsed as db dbDriver = 'tDUU' except ImportError: import adodbapi as db dbDriver = 'ado' </code> If there are differences that show up later in the code, they would be handled by something like: <code> if dbDriver == 'tDUU': conn = db.connect("the traditional connection string") else: conn = db.connect("the ADO connection string") </code> IronPython makes a very good transitional step because it uses Python 2 syntax, but makes the jump to strings being Unicode. [There was a small problem with the way Microsoft was handling "string1 = str(string2)", but I believe that is fixed for the 2.7A1 release.] Adodbapi uses "if sys.platform == 'clr':" to handle the differences between Iron and C. The source is then run through 2to3 to correct to syntax changes, and uses "if sys.version[0] >= '3':" for the remaining idiosyncrasies. If differences are pervasive, a function or method is defined to handle it. Same source code, TEN versions of Python. (C 2.3, 2.4, 2.5, 2.6, 2.7, Iron 2.0,2.6,2.7, Python 3.0,3.1) It is not really too hard. The application programmer sees no difference between the versions. Proposed matrix for Storm platform growth: (OS) -> (Python version) -> (dbDriver) = (status) Linux -> Cpython -> traditional drivers = Works! Windows -> CPython -> traditional drivers = Works! Windows -> CPython -> adodbapi = proposed step 1 Windows(add MS SQL support) -> CPython -> adodbapi = proposed step 2 Windows -> IronPython -> adodbapi = proposed step 3 Linux(add MS SQL support) -> IronPython -> adodbapi = proposed step 4 Windows -> Python 3 -> adodbapi = proposed step 5 Windows -> Python 3 -> traditional drivers = automatic when drivers become available. Linux -> Python 3 -> traditional drivers = automatic when drivers become available. Whaddya think? -- Vernon <div class="gmail_quote">On Wed, Jul 28, 2010 at 10:36 AM, Jamu Kakar <<a href="mailto:jkakar@kakar.ca">jkakar@kakar.ca</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi, <div class="im"> On Wed, Jul 28, 2010 at 4:49 PM, Vernon Cole <<a href="mailto:vernondcole@gmail.com">vernondcole@gmail.com</a>> wrote: > So, if I offer patches to use adodbapi for the now-supported database > engines (as an option to than the "native" dbapi for each one) would those > patches be considered? > > The advantages: > 1) Microsoft SQL Server databases could also be supported. > 2) No need to install/import multiple api packages in order to read multiple > db engines. > 3) Storm could be ported to Python 3. > 4) Storm could be ported to IronPython. > > The disadvantages: > 1) The code for each engine's front end would be a bit more complex (need to > try adodbapi if the preferred import fails.) > 2) Adodbapi does not work on Linux -- yet. > > Followup question: > If I make adodbapi run on Linux (would require IronPython and Mono) would > you be more likely to accept the patches? </div>I think we'd consider adopting adodbabi as an alternative, but not as a replacement for the existing native drivers. Storm not running on linux with CPython is a blocker, as far as I'm concerned. Thanks, J. </blockquote></div>