Update for Python 3k compatibility

[amorphic]

This PR updates the jsonrpclib package for Python 3.x (py3k) compatibility.

Most of the commits are syntax updates. Some libraries must also be imported differently depending on whether the Python version is 2.x or 3.x.

The UnixTransport was using httplib.HTTP - a very outdated means of establishing a HTTP connection which was deprecated in 2.x, (but still included for 1.5.2 compatibility) and completely removed in 3.x. This transport has thus been updated to funciton in a similar way to the latest xmlrpc.client code. It should work, but I have no simple means of testing it.

[amorphic]

Any chance you could take a look at this and release a new version? I need this before I can submit a PR to update tornadorpc for py3k compatibility.

[amorphic]

It turns out that my original PR wasn't passing tests. My bad. I did a little more work trying to get it over the line but then it occurred to me that I might be flogging a dead horse. Here's why:

jsonrpclib has been specifically designed to mirror xmlrpclib and this works really well in py2.x. But in py3k xmlrpclib has been split into xmlrpc.client and xmlrpc.server, so the paradigm is broken.

What's really required is an entirely new, py3k-only package called jsonrpc containing the modules jsonrpc.client and jsonrpc.server. Unfortunately this name is already taken by an old package which hasn't been updated since 2012 and doesn't seem to by py3k-compatible.

The most up-to-date JSON-RPC package is currently json-rpc and it does support py3k, though it does not attempt to mirror the py3k xmlrpc package.

My original goal was a JSON-RPC implementation of Tornado's WebsocketHandler so I think I might go down the path of writing one based on json-rpc.

[joshmarshall]

James --

Thanks for the work on it, I apologize I was out all week at a conference.
If you want to upgrade tornadorpc to use json-rpc, etc. (or even add
WebSocket capabilities there) I'll be happy to accept that as well.

On Thu, Sep 17, 2015 at 12:15 AM, James Stewart notifications@github.com
wrote:

It turns out that my original PR wasn't passing tests. My bad. I did a
little more work trying to get it over the line but then it occurred to me
that I might be flogging a dead horse. Here's why:

jsonrpclib has been specifically designed to mirror xmlrpclib and this
works really well in py2.x. But in py3k xmlrpclib has been split into
xmlrpc.client and xmlrpc.server, so the paradigm is broken.

What's really required is an entirely new, py3k-only package called
jsonrpc containing the modules jsonrpc.client and jsonrpc.server.
Unfortunately this name is already taken by an old package
https://pypi.python.org/pypi/jsonrpc/1.2 which hasn't been updated
since 2012 and doesn't seem to by py3k-compatible.

The most up-to-date JSON-RPC package is currently json-rpc
https://pypi.python.org/pypi/json-rpc/ and it does support py3k, though
it does not attempt to mirror the py3k xmlrpc package.

My original goal was a JSON-RPC implementation of Tornado's
WebsocketHandler so I think I might go down the path of writing one based
on json-rpc.

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

[efokschaner]

@amorphic It would be nice to have that symmetry between jsonrpc and xmlrpc in python 3. I have a few ideas that might help achieve this.

1. I believe you can put multiple packages on pypi that deliver the same importable package name (obviously installing multiple would cause issues). Only the name used on pypi (thus by pip) needs to be unique.
2. You can have multiple root import packages in a single pypi package. So json-rpc package could deliver both a jsonrpclib importable package and a jsonrpc(.client/server) importable package in one bundle and share implementation. The entry points (jsonrpclib and jsonrpc) could either support both python 2 & 3 or assert that they are only loaded on the respective version (if it saves work...).
3. If having the original old jsonrpc package floating around on pypi or github causes you other issues, you could reach out to the documented owners to negotiate for custody of their project / package if they're not interested in it anymore. If this fails, I've heard it's possible to reach out to pypi, they may have a process for reassigning authority over a package that's important to the community where the owners are unresponsive / unhelpful. Github may also be sympathetic to such things and (again unconfirmed) may be able to help funnel users to a more relevant fork of an old project.

Just some thoughts...