Which Python versions should MySQL Connector/Python support?

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!

Comments

Carlos Valiente

Wed Oct 7 2009, 12:37

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

serverhorror

Wed Oct 7 2009, 13:54

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…

享受生活 - Enjoy life

Wed Oct 7 2009, 14:18

When could we get 3.0/3.1 support? Thanks.

illume

Wed Oct 7 2009, 15:14

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!

regebro

Tue Feb 16 2010, 06:16

There's so much FUD when it comes to Python 3. Sure, supporting Python 3 can be a lot of work, especially if you use doctests. There are some problems in handling binary data vs strings, since that's separate datatypes in Python 3. Otherwise 2to3 works reasonably well, and porting is usually not a big deal. Distribute has support for running 2to3 on code during the build, and makes the porting easier.

There is no need to use sys.exc_info(), and porting to Python 3 and then backporting means you can't use 2to3.

Hopefully the January Issue of Python Magazine should come out sometime in February (in typical Python Magazine style), I start an article series on Python 3 porting there.

Carlos Valiente: Wed Oct 7 2009, 12:37

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
serverhorror: Wed Oct 7 2009, 13:54

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…
享受生活 - Enjoy life: Wed Oct 7 2009, 14:18

When could we get 3.0/3.1 support? Thanks.
illume: Wed Oct 7 2009, 15:14

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!
regebro: Tue Feb 16 2010, 06:16

There's so much FUD when it comes to Python 3. Sure, supporting Python 3 can be a lot of work, especially if you use doctests. There are some problems in handling binary data vs strings, since that's separate datatypes in Python 3. Otherwise 2to3 works reasonably well, and porting is usually not a big deal. Distribute has support for running 2to3 on code during the build, and makes the porting easier.

There is no need to use sys.exc_info(), and porting to Python 3 and then backporting means you can't use 2to3.

Hopefully the January Issue of Python Magazine should come out sometime in February (in typical Python Magazine style), I start an article series on Python 3 porting there.