MySQL-python version 0.9.3 (or 1.0.0) should be released sometime this summer, probably before OSCon 2003 (http://conferences.oreilly.com/oscon/). As last year, I will be giving a tutorial on Python and Relational Databases, Featuring MySQL (http://conferences.oreillynet.com/cs/os2003/view/e_sess/4133).
Based current developments with both Python and MySQL, I've decided to make the following development fork:
MySQL-python-1.0.0 will support all Python versions from 1.5.2 through 2.2.2 and probably also 2.3.x. MySQL versions 3.22.x (x>19), 3.23.x, and 4.0.x will be supported. 4.1.x and newer probably won't be supported.
MySQL-python-2.0.0 will only support Python versions 2.3 and newer and MySQL versions 4.1 and newer.
Why? There's a fair bit of cruft and conditional compilation required to get things to work with older versions of Python (pre-2.2). Similarly, in MySQL-4.1 , a new API is added which directly supports parameter binding. While the old API will still be supported, I believe that supporting both APIs is going to be painful. Also, there are a number of Python features that I am unable to make use of due to having to support 1.5.2, such as string methods (1.6/2.0), generators (2.2/2.3), and the new standard Set type (2.3).
MySQL-python-2.0.0 will likely be a complete ground-up rewrite for tihs reason. But don't worry, because MySQLdb will still use the Python DB-API, so it is unlikely that existing applications will need to be modified. This is not true for the _mysql low-level API: That is likely to change a lot, since it mimics the old MySQL C API, and the new version will be based on the new MySQL prepared statement C API ( http://www.mysql.com/doc/en/C_API_Prepared_statements.html).
The 1.0.0 series may yet support Python versions newer than 2.3.x and MySQL versions newer than 4.0.x, but it won't support new features of MySQL 4.1.x or newer. If MySQL AB drops the old C API from 5.x (for example), those versions will only be supported by the 2.0.0 series.