Make beanstalkc work with Python 3

[earl]

[menezes-]

I'll be more than happy to redirect https://github.com/menezes-/pystalkd to beanstalkc once we have python3 support.

[arturhoo]

Hi @earl,

Thanks for the continued interest in making the library as OS comprehensive as possible. Again, I'd love to see the necessary changes merged and version 0.5 released.

[seveas]

Those interested in python 3 support: please test pull request #57. I've tested it myself and travis is green, but more eyeballs won't hurt 😃

[schickling]

+1

[CtrlC-Root]

+1

[svisser]

@seveas given that beanstalkc isn't 3.x compatible yet, would you be okay with the code in your pull request as a package on PyPI (i.e., a fork of beanstalkc, say, beanstalkc_py3)? I'm happy to do it and make it a wheel file as well.

This seems the easiest solution to have a 3.x compatible beanstalkc ready for use. pystalkd introduces additional changes beyond 3.x compatibility and beanstalkc doesn't appear to be worked on. This means I can tick off another package as 3.x compatible on my list of packages to be ported.

[seveas]

I wouldn't object to doing that, but it's way too early to do such a hostile fork, my PR is only 3 months old.

[svisser]

Not your work but Python 3.x compatibility for this library has been going on for years: #33. Unless something happens things just appear to have stalled.

[earl]

The main open issue related to Python 3 support that still needs to be addressed is that beanstalkc currently is "8-bit transparent" / "binary-clean": you can pass binary data thru beanstalkc & beanstalkd without it getting corrupted. Many beanstalkc users rely on this behaviour, so it's a design issue that needs to be addressed in a Python 3 port as well.

[arturhoo]

hi @earl, thanks for coming back to this issue. I am not one of those folks who rely on that behaviour, so I don't know if @seveas' PR handles that. I'd think it does, since all tests are passing. Cheers,

[earl]

@arturhoo Unfortunately, 8-bit transparency is not currently tested for in the test suite.

[johnchristopherjones]

What does 8-bit transparency testing look like with the current test suite, which looks to be comprised of doctests?

Would it be permissible to introduce a dependency like python-future (pip install future) for 2.6+ support or six (pip install six) for 2.4+ support? One convenient feature of beanstalkc is that it works as a standalone module, but a non-standard library inclusion would most likely break that feature. It doesn't seem like a very important with modern practices, but I know there are a lot of legacy python codebases using beanstalkc. Python-future would make it easier to update beanstalkc and maintain 2-3 compatibility.