Today we had a bug report that one of the tests failed. The as-keyword was used in exception handling, which is only supported since Python v2.6.
Currently, MySQL Connector/Python should work with Python v2.4 and greater, but not Python v3.x. The Connector/Python README said we supported v2.3, but that's not the case (anymore) since decorators are used, e.g. @classmethod.
I'll have to pull the trigger, but I think it's safe to say that we're only going to support Python v2.4 and greater. For Python v3 we'll probably have to make an additional branch and release later on. I still have to check what the impact is.
If anyone has compelling reasons why we still should support Python v2.3 or earlier, please let us know. Also, tips on making it backward compatible are welcome.
Currently, the status of compatibility is as follows (output of shell script):Checking Python v2.3.. Failed! Checking Python v2.4.. Success! Checking Python v2.5.. Success! Checking Python v2.6.. Success! Checking Python v3.0.. Failed! Checking Python v3.1.. Failed!
4 comments:
The following should work in Python 2.4 to Python 3.1:
....try:
........raise Exception("Oops!")
....except:
........e = sys.exc_info()[1]
........# Do things with ``e``
I'd try to stay compatible with the python version RHEL$LATEST_STABLE provides. Fortunately I don't have to work with RHs limited support of packages but it's safer to stay with this as a lot of people depend on it.
As for Py3K I'd honestly do it the other way around. Start developing for Py3K and then backport to 2.x.
Maintaining forwards compatibility is more of a nightmare than maintaining backwards compatibility...
When could we get 3.0/3.1 support? Thanks.
For me, it's 2.4 - 2.6, and 3.1.
However, you still do find old pythons on old web hosts...
cpanel in 2008 had python2.3 being used as the default python (but also had 2.4 available as a separate path).
2.4 onwards is a nice balance at this point I think.
Everyone who supports py3k gets a special prize!
Post a Comment