John Eikenberry has taken over work on ZMySQLDA for some time now and has released ZMySQLDA 3.1. I don't have any ongoing Zope deployment except some Zenoss, and use MySQLdb directly, so I'm not a good test candidate. Superficially, there don't seem to be any outstanding issues.
Since Python 2.6 and 3.0 were released, there has been a lot of demand for prepackaged MySQLdb for those versions. MySQLdb-1.2.2 seems to throw some warnings on Python 2.6, due to a new Python set type (and the old Set module being deprecated), and some old-style exception usage. These problems should be fixed in the SVN version (MySQLdb-1.2 branch). MySQLdb was originally developed for Python 1.5 so some old crufty stuff is still hiding out in there. There are also some build fixes for Mac and Windows.
MySQL-1.2.3 is not too far off. There are probably a couple more fixes that need to go into the 1.2 branch. This will almost certainly be the last release in the 1.2 series. One outstanding question is what versions of Python should be supported in 1.2.3? I've settled on no longer supporting Python 2.3, but I won't go out of my way to break it yet (i.e. decorators, generator expressions). Python 2.4 seems reasonable to support. My current development platform (Ubuntu) has Python 2.5.2 so that's what I'm going to test against. I also plan to test against Python 2.6.
Python 3.0 is a different beast. I'm not sure if it will be possible to have a single version of MySQLdb that works on both Python 2.x and 3.x yet. I'm assuming not. I don't think I'll have Python 3.x support until Python 3.1 at least, though that seems to be not too far off. Guido van Rossum has indicated that Python 3.x will have a faster release cycle than Python 2.x; see PEP-3000. We might even see some early 3.1 releases by PyCon 2009.
MySQLdb-1.3, the precursor to 2.0 and the SVN trunk, is on hold for right now. Some of the fixes that are in the 1.2 branch need to be backported. Currently it does not do any type conversion; this has been removed from the C module and will be done in Python. I don't expect this to adversely affect performance. A lot more will be done using generators and more modern Python-isms. The question here is do I support Python 2.x or only Python 3.x. I'm inclined to say I'll develop it now for Python 3.x, and save backporting for later.
MySQL-5.1 was finally released. There are no big C API changes that I've seen (maybe no small ones either), so you should be able to build against it. For that matter, if you have MySQLdb built against the 5.0 client, I expect it to work fine with a 5.1 server, so save yourself some trouble and don't upgrade if you don't have to.
Similarly, if your OS vendor supplies packages for MySQLdb, use them. MySQLdb is known to be in a lot of Linux distributions, including Fedora, RHEL, Debian, Ubuntu, Gentoo, and others. It's also in the various *BSD distributions.
If you are running Windows or Mac OS X, I still don't use those platforms so I won't be building my own packages for them. If you want to contribute your own packages, I'll host them on SourceForge. Make sure you specify what version of Python and what version of MySQL it is built against.
I am planning a short sprint at PyCon 2009; it will not go any longer than Tuesday, unless there is a lot of unanticipated demand. In light of this, this is the approximate release schedule:
Late February 2009: MySQLdb-1.2.3 beta 1
Late March 2009: Sprint
Early April 2009: MySQLdb-1.2.3 release candidate 1
Mid-April 2009: MySQLdb-1.2.3 final
In order for a sprint to be effective, it can't be just me. I need people to help find, report, test, and fix bugs. I don't think we need more than two days to do this. I suspect we can get a lot done before the official sprint starts. We can probably make the trunk usable. If I could get one or two committed people at the sprint (not counting myself), I'd be happy.
Lastly, MySQLdb development is entirely funded by donations. Nobody pays me to work on it. I've been working on it for the past 10 years, 8 years on SourceForge. I have to plan development around my work schedule to avoid any conflict of interest or intellectual property issues. For the same reason, I am attending PyCon out of my own pocket. Donations are appreciated, though I could also use some interested developers. One or two have come forward lately; the important thing is that you submit patches through the bug/patch tracker. If your patches are good quality, I'll probably give you write access to SVN.
Feedback is solicited and welcomed.
Since Python 2.6 and 3.0 were released, there has been a lot of demand for prepackaged MySQLdb for those versions. MySQLdb-1.2.2 seems to throw some warnings on Python 2.6, due to a new Python set type (and the old Set module being deprecated), and some old-style exception usage. These problems should be fixed in the SVN version (MySQLdb-1.2 branch). MySQLdb was originally developed for Python 1.5 so some old crufty stuff is still hiding out in there. There are also some build fixes for Mac and Windows.
MySQL-1.2.3 is not too far off. There are probably a couple more fixes that need to go into the 1.2 branch. This will almost certainly be the last release in the 1.2 series. One outstanding question is what versions of Python should be supported in 1.2.3? I've settled on no longer supporting Python 2.3, but I won't go out of my way to break it yet (i.e. decorators, generator expressions). Python 2.4 seems reasonable to support. My current development platform (Ubuntu) has Python 2.5.2 so that's what I'm going to test against. I also plan to test against Python 2.6.
Python 3.0 is a different beast. I'm not sure if it will be possible to have a single version of MySQLdb that works on both Python 2.x and 3.x yet. I'm assuming not. I don't think I'll have Python 3.x support until Python 3.1 at least, though that seems to be not too far off. Guido van Rossum has indicated that Python 3.x will have a faster release cycle than Python 2.x; see PEP-3000. We might even see some early 3.1 releases by PyCon 2009.
MySQLdb-1.3, the precursor to 2.0 and the SVN trunk, is on hold for right now. Some of the fixes that are in the 1.2 branch need to be backported. Currently it does not do any type conversion; this has been removed from the C module and will be done in Python. I don't expect this to adversely affect performance. A lot more will be done using generators and more modern Python-isms. The question here is do I support Python 2.x or only Python 3.x. I'm inclined to say I'll develop it now for Python 3.x, and save backporting for later.
MySQL-5.1 was finally released. There are no big C API changes that I've seen (maybe no small ones either), so you should be able to build against it. For that matter, if you have MySQLdb built against the 5.0 client, I expect it to work fine with a 5.1 server, so save yourself some trouble and don't upgrade if you don't have to.
Similarly, if your OS vendor supplies packages for MySQLdb, use them. MySQLdb is known to be in a lot of Linux distributions, including Fedora, RHEL, Debian, Ubuntu, Gentoo, and others. It's also in the various *BSD distributions.
If you are running Windows or Mac OS X, I still don't use those platforms so I won't be building my own packages for them. If you want to contribute your own packages, I'll host them on SourceForge. Make sure you specify what version of Python and what version of MySQL it is built against.
I am planning a short sprint at PyCon 2009; it will not go any longer than Tuesday, unless there is a lot of unanticipated demand. In light of this, this is the approximate release schedule:
Late February 2009: MySQLdb-1.2.3 beta 1
Late March 2009: Sprint
Early April 2009: MySQLdb-1.2.3 release candidate 1
Mid-April 2009: MySQLdb-1.2.3 final
In order for a sprint to be effective, it can't be just me. I need people to help find, report, test, and fix bugs. I don't think we need more than two days to do this. I suspect we can get a lot done before the official sprint starts. We can probably make the trunk usable. If I could get one or two committed people at the sprint (not counting myself), I'd be happy.
Lastly, MySQLdb development is entirely funded by donations. Nobody pays me to work on it. I've been working on it for the past 10 years, 8 years on SourceForge. I have to plan development around my work schedule to avoid any conflict of interest or intellectual property issues. For the same reason, I am attending PyCon out of my own pocket. Donations are appreciated, though I could also use some interested developers. One or two have come forward lately; the important thing is that you submit patches through the bug/patch tracker. If your patches are good quality, I'll probably give you write access to SVN.
Feedback is solicited and welcomed.
10 comments:
Andy: This is just the kind of project that snakebite.org might be able to help with if you can rope someone in to help, particularly on the Windows side.
Good luck getting contributions, you certainly deserve them for all the work you have put in to MySQLdb. I'll be donating myself.
thanks for the donation, Steve! I already owed you a beer from last PyCon,
Something seems not quite right with snakebite.org though, or else I'm missing the point,
Hey Andy,
Ted Leung is "the guy in charge of Python at Sun": http://www.sauria.com/blog/.
Since Sun now owns MySQL, it makes sense for them to invest some time in the Python driver. Why don't you send email to Ted and tell him JJ said hi :)
-jj
Hi Andy,
Where is the best place to supply feedback, file bug reports, etc? I couldn't find anywhere linked from the project page. It may be worth adding something on that page.
We're having trouble compiling the latest subversion head on Solaris 10 and I was wondering if you could help. Version 1.2.2 compiles fine. Python.h and my_config.h are now both included by the MySQL-Python src/mysqlmod.h file, and these files on our system both define SIZEOF_LONG (or rather Python.h includes pyconfig.h, which does). When we compile, we get:
Sun Studio:
root MySQL-python-head (f01): /opt/SUNWspro/bin/cc -DNDEBUG -g -O3 -fPIC "-Dversion_info=(1, 3, 0, 'final', 0)" -D__version__=1.3.0 -I/opt/webstack/mysql/include/mysql -I/opt/ec/inclue/python2.6 -c src/mysqlmod.c -o build/temp.solaris-2.10-i86pc-2.6/src/mysqlmod.o -xarch=386 -xchip=pentium -xspace -xildoff -xc99=none -xnorunpath -m32 -DBIG_TABLES -DHAVE_RWLOCK_T
"/opt/webstack/mysql/include/mysql/my_config.h", line 1038: warning: macro redefined: SIZEOF_LONG
Gnu CC has a bit more info:
root MySQL-python-head (f01): gcc -DNDEBUG -shared -O3 -fPIC "-Dversion_info=(1, 3, 0, 'final', 0)" -D__version__=1.3.0 -I/opt/webstack/mysql/include/mysql -I/opt/ec/include/python2.6 -c src/mysqlmod.c -o build/temp.solaris-2.10-i86pc-2.6/src/mysqlmod.o -xarch=386 -xchip=pentium -xspace -xildoff -xc99=none -xnorunpath -m32 -DBIG_TABLES -DHAVE_RWLOCK_T
gcc: warning: `-x norunpath' after last input file has no effect
In file included from src/mysqlmod.h:12,
from src/mysqlmod.c:3:
/opt/webstack/mysql/include/mysql/my_config.h:1038:1: warning: "SIZEOF_LONG" redefined
In file included from /opt/ec/include/python2.6/Python.h:8,
from src/mysqlmod.h:4,
from src/mysqlmod.c:3:
/opt/ec/include/python2.6/pyconfig.h:889:1: warning: this is the location of the previous definition
MySQL is version 5.0, supplied by Sun Web Stack, and Python is version 2.6, compiled by ourselves.
The interesting thing is that both those files define different sizes:
/opt/webstack/mysql/include/mysql/my_config.h:
/* The size of a `long', as computed by sizeof. */
#define SIZEOF_LONG 8
/opt/ec/include/python2.6/pyconfig.h:
/* The size of `long', as computed by sizeof. */
#define SIZEOF_LONG 4
This could be due to the fact that Sun compile both a 64bit and 32bit version of their MySQL, with 64bit binaries in [bin|lib]/amd64 subfolders. I'm not an autoconf guru, but if autoconf is generating the config.h files and using sizeof, then you'd need two my_config.h files, one for the 64bit libraries and one for the 32bit libraries. I could be talking out my arse here though, I haven't coded C in over 5 years.
I've looked on a Linux system, and there are no SIZEOF_ definitions in my_config.h or pyconfig.h.
Do you have any suggestions of how to fix this? I'd be keen to avoid recompiling MySQL as the Sun Web Stack one is supported by Sun.
Cheers,
Alasdair
If you look under Tracker or Public, you should see where the bug tracker is.
http://sourceforge.net/tracker/?group_id=22307&atid=374932
Also there is a link for Forums.
http://sourceforge.net/forum/forum.php?forum_id=70461
Looks to me like you have 64-bit MySQL and 32-bit Python which isn't gonna hook up.
Hi Andy,
Ahh great - thanks for the links. I missed those on the sourceforge projet page, didn't think to click around on those tabs.
You're right about the 64bit vs 32bit issue. Sun do a crazy thing with their MySQL, and compile up both 32bit and 64bit libraries and binaries, and put them in the same package. But they only supply a 64bit my_config.h file. We solved the problem by compiling our own MySQL client library and linking against this.
There's also an issue on Solaris where if Python is compiled with one compiler, and MySQL is compiled with another (eg Sun Studio on one, gcc the other), MySQL-python may pass the wrong compiler arguments to whatever compiler is being used. Not a bug/issue with MySQL-python, just something people may need to watch out for. I've done a blog post about the experiences we had here:
http://blogs.everycity.co.uk/alasdair/2009/03/compiling-mysql-python-on-solaris-10/
Hi Andy, hope to see MySQLdb for python3.x soon, my project is depending on it!
It's not clear yet if we can use the same version of MySQLdb on Python 2 and Python 3, but I'm assuming not. I'm expecting to fork after 2.0 and then MySQLdb-3.0 will be for Python 3.
Hi!
I found a pymysql for Python3
http://sourceforge.net/projects/mypysql/
I think share this link... Works fine for me...
Hi,
I wanted to hear if there is any update on the Python 3 version?
I suppose not, because development seemed to have stopped on the 1.2.3-beta and you mentioned to make version 3 python 3 compatible.
So realistically I suppose it will be python 3 compatible in 1-3 years, right?
... and I do not blame you (if you don't get support + no one donates)!
Did you actually try once to compile/run against python3? Maybe its not that bad?
If its not too bad or I have support I might be willing to help with the python3 port.
Post a Comment