[IronPython] Poll: split of adodbapi.py into two modules? (django support)

Vernon Cole vernondcole at gmail.com
Sun Nov 29 03:34:25 CET 2009


This is a feature poll.
It will be cross posted on both the IronPython and pyWin32 groups.

Please answer if you have strong feelings either way on this....

Introduction:
    I am now working on a new version (2.3.0) of adodbapi which is intended
to have all of the features needed to interoperate with

django.  This should be a significant step forward to two projects:
  1) MS SQL database support for django.
  2) running django on IronPython.

As the old saying goes: "Killing two birds with one stone."

I order to accomplish this, I am taking some of  the significant changes
made to an earlier (non-IronPython) version of  adodbapi and

merging them into the current (IronPython compatible) version.  This
includes the changes needed to make adodbapi work with

'format' paramstyle,  which django expects, as an option to the native
'qmark' paramstyle.

In performing this Hurculan labor, Adam Vandenberg made some badly needed
cleanups to the code.  His work makes the module

much more readable and easier to understand. Thank you, Adam!

One of the changes Adam made was to remove dozens of lines defining various
ADO constants from adodbapi.py and place them in

another file, ado_consts.py.  I really like the change, both because it
takes the bloat out of adodbapi, and it makes  the constants

accessible to other uses:
   >>> ado_consts.adLongVarWChar
   203
   >>> ado_consts.ado_type_name(203)
   'adLongVarWChar'
   >>>

This will break code which expects some of these constants to be attributes
of adodbapi, such as 'adUseClient' and 'adXactBrowse'.

Question:
Should I proceed to use the separate version of ado_consts, even though it
might break some existing programs?
--
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20091128/1bd5c7d8/attachment.html>


More information about the Ironpython-users mailing list