Arc Riley wrote: > > Yes, yes, there aren't many DB packages for Py3 yet. This is exactly > why we're looking for something that's database-agnostic; right now > we're limited to sqlite but preferably our classes shouldn't care what > database is being used and can just as readily be used with postgres > or mysql in the future. This is a chicken-and-egg problem that will > only be solved when existing Py3 code can take advantage of postgres > py3 bindings. > > We have already ported Genshi to Py3 to the extent that it works for > our purposes, hosting our transformed branch on > http://hg.concordance-xmpp.org/genshi-py3 > > Two of us spent a good deal of time last night banging out the > wrinkles left in sqlalchemy post-2to3, reducing the number of errors > reported by alltests from 2000+ to just over 100. All our patches can > be seen at http://hg.concordance-xmpp.org/sqlalchemy-py3 applied > against a mirror of your hg mirror. > > Clearly we're not done yet but we've whittled down to the last few > pieces. While we don't mind hosting this branch until you're ready to > officially support Py3 it'd be nice to have all this work in a form > that you can readily pull in and use. > > What can we do to help with that, and toward a near-future sqlalchemy > release of a -py3 versioned tarball.
We have a mostly working py3 of SQLAlchemy which is targeted towards 0.6. It includes a wrapper around 2to3 which allows us to manually control sections of code for which 2to3 can't guess what we'd like to do. The 0.6 branch is available for review at http://svn.sqlalchemy.org/sqlalchemy/branches/rel_0_6 , and we'll be sprinting on it further at pycon. The sa2to3.py script detects blocks of code marked as PY3K or PY2K and adjusts before sending off to 2to3. The 0.6 series of SQLA is focused around a refactor of database dialects and is appropriate for py3k since it decouples database compilers from DBAPIs - the release can run MySQL against both MySQLdb as well as pyodbc, and can run Postgres against either psycopg2 or pg8000 (the latter which runs on py3k). Support for jython, ironpython, others is much more of a drop-in as existing SQL compilation code can be reused. It seems like most of the changes implemented in your branch of 0.5 are already present in 0.6. If you'd like to work on 0.6 getting all tests to pass, let me know. 0.6 is intended to be almost totally backwards compat with 0.5, no huge ORM changes or anything like that, so the average application should be able to switch to it without any significant migration of their code. There might be some changes needed to external packages that build upon schema compilation like Migrate. --~--~---------~--~----~------------~-------~--~----~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
