Python 3.0
greno
Michael Bayer
The two main issues with this are DBAPI availability, and code
migration. I have been waiting for Py3K to be generally stable
before even attempting to migrate the code, its going to be a huge
job. We're still settling into Python 2.6 compatibility to even get
on board there.
sqlite3 seems to be present in Py3K so that would allow some testing
to occur. I dont see anything for psycopg2 nor anything for MySQLdb
(and I'm assuming that explicit conversions would be needed for
those). So as of yet the impetus to push for 3K compatibility
doesn't seem to be there yet.
Of course we'd be thrilled for volunteers to take on this task and
begin identifying issues. We've already seen issues such as Py3K's
inconvenient treatment of __hash__() may make it fairly complicated.
greno
one month. I was hoping to see projects like SQLAlchemy being almost
ready for 3.0 but it seems people were waiting for final release. I
guess if you have the code running under 2.6 and you have all the Py3k
warnings resolved then you can run the 2to3 tool on it and it should
convert it to 3 syntax.
Michael Bayer
there's little or no DBAPIs available. There won't be widespread use
before that happens in any case. If current DBAPIs don't provide for
Py3K and new contenders step in, then that complicates things even
further as our dialects are somewhat specific to their current DBAPI.
While we do have a branch which will resolve this, its still in
progress and is associated with the 0.6 SQLA series.
Also I'm pretty sure 2to3 is not going to be nearly enough. I'm
hoping we'll be able to automate the 2to3 process entirely on our side
but it will take some engineering beyond what 2to3 provides.
Michael Bayer
On Nov 16, 2008, at 2:38 PM, Michael Bayer wrote:
>
> there's little or no DBAPIs available. There won't be widespread use
> before that happens in any case. If current DBAPIs don't provide for
> Py3K and new contenders step in, then that complicates things even
> further as our dialects are somewhat specific to their current DBAPI.
for example:
http://mail.python.org/pipermail/python-list/2008-September/508112.html
"months to years".
Christian Heimes
It's realistic to assume that some packages will never be ported to
3.0. C Extensions lile most DBA are going to take several days of
serious work or several months of slow migration.
In order to port SA to 3.0 you have to
* wait until 2.6.1 is released. 2to3 in 2.6.0 is broken and breaks on
SA 0.5rc2
* get SA working on 2.6.1
* get SA working on 2.6.1 with the -3 warning options w/o triggering
a warning
* run 2to3 and pray ;)
Christian
Michael Bayer
On Nov 16, 2008, at 6:06 PM, Christian Heimes wrote:
>
> * wait until 2.6.1 is released. 2to3 in 2.6.0 is broken and breaks on
> SA 0.5rc2
rc4 runs on the current 2.6 release, I've been experimenting today.
> * get SA working on 2.6.1 with the -3 warning options w/o triggering
> a warning
I've got most of the tests running with the -3 flag as well, and have
gotten rid of the warnings which are to the effect of "method XXX will
not be available" as well as other patterns which are explicitly
forbidden. There are a lot of warnings which don't necessarily seem
to be things we have to change, like instrumenting __setslice__ on a
collection - it just won't be called in Py3.
> * run 2to3 and pray ;)
waiting for 2to3, however the main thing to work on is this
__hash__(), __eq__() business. I've added a branch which dramatically
changes how we use dicts and sets throughout the library. We
actually rely very heavily on elements being hashed strictly on their
__hash__() value, with the assumption that __eq__() is never called as
long as __hash__() is distinct. This is the behavior in all the
cPythons between 2.3-2.5, if you try out http://paste.pocoo.org/show/91414/
for example.
The language regarding __hash__() seems a lot more strict in py3k so
the branch is just to see how hard it would be to not rely upon this
behavior if we had to, so the branch abstracts away all dict/set usage
to special versions which hash on a __sa_hash_key__(). It works but
introduces a fair amount of overhead.