Enhanced Python 3 Support #2819
Conversation
agjohnson
added
PR: ready for review
PR: work in progress
|
Thanks for giving this a go! The larger issue is all of the dependencies that we have that are python 2 only and perhaps unmaintained. This is where I stopped last time I was working on python 3 support. This PR is going to be prone to breakage while it is still a WIP, as we can't easily do this change incrementally. |
|
Dependencies are obviously a potential source of headaches. I can report that as of right now, the changes I submitted are enough to get RTD installed and running under Gunicorn on FreeBSD 11 w/ Python 3.5. I've so far managed to sign up a new user (though it won't stay logged in; I suspect I've missed some config overrides) and am not seeing any actual exceptions. Since I'm only self-hosting, that's probably not enough to test all the integrations, etc. and flush out the bugs, but the changes I've submitted so far should be fairly safe for doing single codebase. It's consisted mostly of using I'd be happy to work through whatever process is appropriate for getting these changes more fully tested with the goal of getting the PR accepted, as well as to submit more enhancements to fix issues I find while running ReadTheDocs locally. --Hank |
|
Great! I'll check in next week, let us know how testing is going on this. As I recall, there were some old django packages that weren't looking like they would get python3 support -- slumber was the main package lacking python3 support though. Perhaps that has changed. The packages that were going to be a problem also weren't heavily used, so it might introduce some edge case bugs. It would help to have a core dev pull this down to run tests and QA once it's about ready. |
|
On the subject of dependencies, I found a tool—checkmyreqs—to automatically check the entries in a |
|
I believe we should be able to slowly upgrade the codebase to support Python 3 without breaking it on Python 2. Things like |
django-formtools is passing us the `items()` of a `dict`. In Python 2, this is a `list`, and can be directly indexed. In Python 3, it is a "View Object", which cannot be directly indexed. Since I thought it unlikely for there to be more than a few forms in this collection, I decided it was easier to simply wrap it in a `list` no matter what, rather than using `itertools.islice` to grab the first element.
Python 3 got rid of `unicode`; I used `six.text_type` to support 2 and 3 both. For Python 3-based projects, Python got rid of `__unicode__`. Now you use `__str__` and a decorator that is a no-op on Python 3 but maps things appropriately for Python 2.
…expects 'str' on Python 3.
* Docstring/PEP 257 fixes for the privacy app * Docstring/PEP 257 fixes for the profiles app * Docstring/PEP 257 fixes for the projects app
Thanks for the fix! 🎉
…jango as of 1.8 and we're on 1.9.x
This will be required before migrating to 4.x, as well as picking up a few miscellaneous fixes.
…e vs. Bytes issues for us in test responses.
It's not defining either a `__str__` or `__unicode__` method, so it doesn't need that decorator (which defines the one in terms of the other on Python2, and is a no-op on Python3).
Python 3 removed it from `BaseException`. Checking the `str()` of an exception should be sufficient.
… problems related to removal of implicit relative imports.
|
Got this running locally: Will take a peek. |
|
This got me down to 17 failures: |
|
Pushed a couple fixes, which got my tests down to ~15 failing. Definitely still need to go through and clean up our unicode fails :) |
After inspecting `BuildCommand`, I determined that it always expects bytes from the `communicate` call, and attempts to decode them (as UTF-8) into a unicode string. Accordingly, I've changed these unit tests to explicitly mock the results of `communicate` as UTF-8 bytes, and to assert equality with unicode strings.
|
Closing this one because I made a different one that is way better. |
agjohnson
removed
the
PR: work in progress
I just set up a new instance of ReadTheDocs under Python 3.5 on FreeBSD. These are the changes I needed to make to complete the installation instructions. There are probably additional changes required to achieve comprehensive Python 3 support, but I hope this is seen as a good start.