search5 / solrpy

Automatically exported from code.google.com/p/solrpy
Other
40 stars 17 forks source link

Python 3 support. #41

Closed agpar closed 8 years ago

agpar commented 8 years ago

I've added support for Python3 to solrpy. The root of the repo has been split into python2 and python3 subdirs. All the tests of the Python2 version have been appropriately updated and are 100% passing on Python3.

I've also updated setup.py so that it will install the correct version of solrpy given the version of Python the user is running.

I updated solrpy to run on python3 around Septmber, and the python3 version has been running on the Elvis Database since then. I only just updated the tests and setup this week, and feel it's ready to pull.

This version is currently hosted on Pypi as solrpy3, but I think it would be great to add these changes to the main solrpy dist. The repo is already set up to support both python 2 and python 3 installs from Pypi.

-Alex

edsu commented 8 years ago

Wow, this is a lot of work. Was there a reason you opted not to use six instead of duplicating so much of the code?

agpar commented 8 years ago

Hi Ed,

It's actually probably not as much work as it looks like... Essentially I ran 2to3 on the python2 distribution and spent a couple hours debugging back in September, then this week I finally got around to finding all the bugs in the tests and got the new version passing.

I didn't use six because I haven't used it before--yours was the first module that I found I depended on for a project and needed to move to Python3. In retrospect, two completely distinct distributions is a less-elegant way to do things, but I didn't originally plan to port the module for anyone but myself. Still, I think it's a nice module, and it might be useful to share the work I'd done to get it running on py3.

In any case, the tests for 3 appear to be passing, and I haven't touched any of the code in the python2 distro. You can try pip install solrpy3'ing from a py2 or py3 env, and you should get the correct version.

edsu commented 8 years ago

I just worry about any further changes to one will require changes to other. It seems less manageable somehow. I would actually somewhat prefer having separate repositories I think.

What do other people think?

torfsen commented 8 years ago

If you want to continue to support Python 2 (which I strongly suggest you should do) then using six or future is by far the better way to go, since this will allow you to maintain a single code base instead of two. The choice between six and future is mostly one of personal taste in my opinion, but you should choose one and stick to it. If you can afford to only support Python 2.6+ and 3.3+ (usually not a problem) then I suggest using future because it basically lets you write Python 3 code that is compatible with Python 2. To run your tests on all supported versions of Python I strongly suggest that you use tox.

edsu commented 8 years ago

I'm sorry but the code duplication in this PR really is not manageable going forward. I think an approach like in #43 is more viable.