Grr - you mean trunk *isn't* the head development tree in svn? Frustrating in wasted time in duplicated effort. Can you please post this on the website so others don't make the same mistake?
Ok. I can chalk this up to practice and a learning experience. Yes - we're looking to use sqlalchemy in a Py3-only package set for first release sometime this week (we can depend on a svn tree for now). Is basic ORM, mapping, etc ready in svn rel_0_6? Backwards compatibility isn't needed since we're implementing new code. Yes - we'd be happy to contribute towards getting most/all the tests to pass on Py3, especially as needed for our purposes but more generally toward helping with community migration. So 0.6 is planned to have a tarball release specific for Py3, or otherwise installable for Py3 using setup.py? On Tue, Mar 17, 2009 at 12:40 PM, Michael Bayer <[email protected]>wrote: > > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
