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 :smiley:

[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: https://github.com/earl/beanstalkc/issues/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.

[Rogdham]

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"

For me, there are two ways to deal with this:

1. Always use bytes in Python 3
2. Do the encoding/decoding automagically in Python 3, but have an option to allow to switch to bytes only

The second option is implemented in #57. It does not change anything for Python 2, and converts to str automagically in Python 3, unless the encoding=None is chosen.

The first steps of implementing option 2 have being done in #65, but there was way less community interraction about that one, maybe because the implementation has not being finished.

@earl do you have any preference between options 1 and 2 above? As the maintener of this repo, you are the one to make that choice I believe. As far as I'm concerned, both options are good, with option 2 having the benefit of being already implemented (with users running that code base). IMHO, the only bad choice is to do nothing about it, as it would divide the community on the long run.

Finally, you mentionned this is the main issue, anything else in mind?

Several users have already offered their help, so if you find a blocking point somewhere that would need to be adressed, do ask for help if you don't have time to tackle it yourself.

[johnchristopherjones]

I didn't say anything about it on #65, but my biggest problem getting to "complete" was getting everything to pass the doctests under both Python 2 and Python 3. The doctests would silently hang under circumstances that were hard for me to predict. My commit at johnchristopherjones/beanstalkc@596b331 was my latest activity along this route.

[MartinMikita]

Do you have some date for releasing this library that works with Python 3?