Do not hold your breath. I understand that there is a problem with unicode vs str in django. The PEP 429 specifies a BINARY constructor (which within adodbapi has different definitions for Python2.x and Python3.x) which a user can call to get a piece of raw memory. Django does not seem to have similar functionality, and all that will have to be fixed before porting to Python 3. IronPython uses 'str' as a synonym for 'unicode' -- so it is halfway there, and porting to IPy is a good step in getting ready for Python 3. Internally in adodbapi I use the symbols 'makeByteBuffer' and 'memoryViewType' when I need to refer to raw bytes. Django will need something like that.
Also, the version of adodbapi which is used in the django-MSsql project was forked off before the IronPython support was added. I have communicated with the authors and will try to make a new version of adodbapi which has all of the functionality needed for django, so that this fork can be merged in. I do not know whether the other dbapi modules for IronPython are complete enough to support django, but I kind of doubt it. The database access code in django seems to be quite version specific for database api modules. Again, ADO should be able to replace any of them -- but it will take some work to get there.
--
Vernon
On Tue, Oct 20, 2009 at 12:48 PM, Josh
<josh@...> wrote:
"I Py 2.6 RC1 successfully passes all tests for adodbapi. Congratulations!
You now have a fully PEP 249 compliant database engine on IronPython."
Excellent. I wonder if this bodes well for Django out of the box on IPy 2.6? Is there still an issue of Django's handling of Unicode for binary data?
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
