Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork8.1k
Stop relying on 2to3 and usesix.py for compatibility instead#2226
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
pelson commentedAug 12, 2013
And the fact that we would have a single code base which users of Python3 can actually contribute against... |
mdboom commentedAug 13, 2013
Well, I'm not sure that using |
mdboom commentedAug 14, 2013
Ok -- here it is. This is going to make some merges harder, unfortunately. Also, we should probably get#2281 (which is against 1.3.x) finished and merged with this before finalizing this. Some of these changes may be surprising, and I'll try to notate them here in this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
My thinking here is to always include this in every file to make moving code around easier. The things it has are "core" enough that they should probably be considered "built-ins".
efiring commentedAug 14, 2013
Mike, |
mdboom commentedAug 14, 2013
For some of these, there are many instances of them, and I wouldn't want to comment them in each place. But perhaps a "writing portable code" document in the developer docs is in order. |
WeatherGod commentedAug 14, 2013
And a reference to that document in the relevant source files for the most |
Stop relying on 2to3 and use `six.py` for compatibility instead
…terstoo long according to pep8. This bulk-fixes this by breakingthe import up into 4 seperate lines.
…achterstoo long according to pep8. This bulk-fixes every file in the library.
This is a significant amount of work, but will pay off (primarily in shorter build times) in the end.