-
Notifications
You must be signed in to change notification settings - Fork 46
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
Feature python3 compat #298
Conversation
…balizing" the basestring keyword
I did a pull request for this to better discuss the issues. See inline comments. |
Needs rebase (and most likely a few more fixup ) after the merge of #295. |
@@ -237,10 +247,10 @@ class HttpRemoteSync: | |||
else: | |||
hashList = json.loads(urlopen(hashListUrl).read()) | |||
pkgList = json.loads(urlopen(pkgListUrl).read()) | |||
except URLError, e: | |||
except URLError as e: |
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.
This is not compatible with python 2.4, which is currently used by slc5 (sigh). Can we factor this change out? We have in the plans to move to 2.6, but I still would like to do it separately.
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.
I think the only way to support the different syntaxes is to have separate files that are loaded by "globally compatible" (i.e. super simple/trivial) executable scripts (aliBuild, etc).
I think it would be possible to use the 2to3 script to minimize (human) code duplication. I don't know if it would be easy to apply to whole modules (such as the local yaml module).
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.
You misunderstood me. I'd like the python 2.4 compatible changes to be in a separate PR from the python 2.6 only ones. This way we can easily revert the latter if we have problems with it.
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.
Ah, I see; just to make merging easier down the line, not for simultaneous py3/py2.4 compatibility, which I don't think can happen easily.
Yeah I can create a new branch/pull request & cherry pick compatible changes. Should I also rebase this branch? I don't know if rebasing will break the pull request.
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.
Correct. It's just to simplify merging. As I said I suspect you will have conflicts as I refactored a bit aliDoctor to improve user experience and to make it behave exactly like aliBuild
Not needed anymore, I think. I have most of them handled in the new next branch. |
v1.4.0.rc1, which was just released, should work with python 3. |
No description provided.