Updated exception handling to be compatible with Python 2.x and 3.x

[svisser]

This change makes the exception handling compatible with Python 2.x and Python 3.x. More testing would be needed to ensure the project as a whole works in Python 3.x but at least the module can be imported in Python 3.x.

[earl]

Thanks!

Could you maybe check/verify to which Python 2.x version we still stay backwards-compatible with this change applied? (I.e. which previously potentially supported Python 2.x versions we are now sure to break for?) The Travis build verifies that 2.6 and 2.7 still work.

I think this syntax was only backported to 2.6 and is not available earlier, so using it would make beanstalkc depend on Python 2.6+. I'm basically fine with dropping 2.5 (and maybe even 2.4) support. For one, because those versions don't get any younger; second, because we have gone a long time without automatically (or even me manullay) verifying beanstalkc to work on those Python version. But I still want to be explicit about this. As in: 0.x version bump and an explicit remark in the release note that beanstalkc now requires Python 2.6+.

[svisser]

The "try ... except ... as" syntax was indeed backported to Python 2.6 so this change makes it 2.6+. So we know it'll break for Python 2.5 and older (simply due to unsupported syntax). We're already at Python 3.4 so I think it's reasonable to drop support for 2.5 and older. Users of those Python versions should consider upgrading to 2.6 or 2.7 anyway to remain compatible.

Each exception will also have an "args" attribute when it's a subclass of Exception (when you're not making further changes in the subclass); I just checked this in 2.6.8 and 2.7.8.

[earl]

Thanks for verifying that. Here's a changelog reference: https://docs.python.org/2/whatsnew/2.6.html#python-3-0

Just for context: http://canidepend.com/#python -- it's not just about the absolute version number but also about the ecosystem at large. Dropping support for 2.4 (but again, I haven't verified for a long time whether 2.4 even still works) means dropping support for the second most recent stable version of at least one major distro (SLES 10) and the current-2 stable version of another major distro (RHEL 5). Both of those distro versions are still under active support (SLES 10 until at least 2016, unless I'm mistaken; RHEL 5 until 2020).

So dropping support for earlier Python versions is not a decision I take too lightly. But SLES 12 is slated for later this year and once that's out, we'll have the current and previous versions of most major distros covered. So I think the time is indeed ripe to let go of 2.5 and earlier in the near future in the favour of getting the 3.x support working.

[svisser]

I don't see why that prevents us from creating a Python 2.6+ / 3.x+ version of beanstalkc today. What would be the benefit of waiting several months to release a 0.5.0 of beanstalkc? If needed, we can backport any bug and security fixes to both the 0.4.0 and 0.5.0 branches.

The recommended practise is to install projects within virtual environments so the system Python doesn't have to determine the Python version used when running a codebase. This is one of the packages preventing us from moving to Python 3.x so waiting another few months doesn't sound encouraging.

[earl]

I'm not sure where I implied that we'd have to wait "another few months" for a 0.5.0 version. So to be perfectly clear: we don't have to wait, not at all. I just wanted to clarify, why this change, benign as it looks, warrants additional care.

[svisser]

Oh, that's good news. I had read the following "in the near future" as that we'd wait until SLES 12 was out:

So I think the time is indeed ripe to let go of 2.5 and earlier in the near future in the favour of getting the 3.x support working.

I do agree it needs care. I'm happy to perform additional testing to make sure the code behaves as expected in Python 3.x.

[arturhoo]

I would very much like to see this merged into master and beanstalkc is indeed one of the few libraries preventing me to move to Python 3.

[earl]

Thanks again for your work on this, @svisser. The fix proposed herein is now obsoleted by the recent merge of @seveas's exception handling fix (e009355a28b2d0991439f2ba89a8f04ce9714ee4), which stays backwards compatible back to at least 2.4.

NB: Even though this now allows one to import the module on Python 3, this change alone won't give us a properly working beanstalkc. Please follow #13 for full Python 3 support.

[svisser]

Yes, I understand - thanks for taking care of this. One tested pull request would be better compared to merging several for Python 3.x compatibility.