-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8-bit transparency under Python 3 #60
Comments
If encoding or decoding fails, should we raise Python's built-in exceptions or wrap them in a I think wrapping them with a raise SubclassBeanstalkcException from exc |
@earl poke. Any comments? |
I think it might be incorrect to support string encoding/decoding for beanstalkc. Beanstalkd is a lot like socket; it has no real knowledge (as far as I know) about the contents of a job; it just stashes bytes. There's no real way (or need) for beanstalk to know the encoding of a string job, or even that the job is a string. What if beanstalkc only speaks bytes? The user would have to explicitly encode/decode on put/reserve, but I'm not sure that's a significant burden. We're implicitly relying on us-ascii/utf-8 being the same thing as byte strings most of the time in the Python 2 interface. Acknowledging that explicitly seems like the way to go. That sidesteps the 8-bit byte transparency issue entirely. Adding automatic encoding/decoding for strings is a convenience that can be added later. |
Pull request #57 adds python 3 compatibility, but always tries to decode job bodies. Given that arbitrary byte strings may be put in the body, this is suboptimal.
For other protocol messages, only ascii content is accepted, so encoding/decoding automatically is fine.
I propose the following:
Connection.__init__
, defaulting tosys.getdefaultencoding
For put:
And for reseve/peek etc. (_read_body):
None
, return a bytes objectIf this design is acceptable, I'll rebase and amend the pull request to follow this design.
The text was updated successfully, but these errors were encountered: