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
Port python bindings to Python 3 #66
Conversation
+ @mrovner to help take a look. |
return _install(tarball, _build_install_args(options)) | ||
|
||
if __name__ == '__main__': | ||
sys.exit(main()) |
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.
+1. Replacing the old, Python2-only 'ez_setup.py' with one from the setuptools bitbucket repo is definitely the Right Thing. FTR, the permalink for "latest and greatest" ez_setup.py
is: https://bootstrap.pypa.io/ez_setup.py
#The first input has to be a string, and literals are unicode | ||
MyProtoClass = reflection.GeneratedProtocolMessageType(str('MyProtoClass'), | ||
(message.Message,), | ||
{'DESCRIPTOR': mydescriptor}) |
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.
Is this change related to the Python3 port, or is it just ensuring better coverage of what the testcase name says it is about?
Yes, we still have 2.5 clients. On Tue, Nov 18, 2014 at 8:53 AM, Ilya Kulakov notifications@github.com
Thanks, |
@tseaver Please edit your reviews given that answer :) |
@mrovner I thought the question was about keeping 2.6 support: are you saying that we need to ship a protobuf that spans 2.5 through 3.4? Would bumping a major version to signal dropping 2.5 support while adding 3.x support be reasonable? Users stuck on Python 2.5 would then stay with |
@@ -610,7 +624,10 @@ def FindInitializationErrors(self): | |||
return self._cmsg.FindInitializationErrors() | |||
|
|||
def __str__(self): | |||
return str(self._cmsg) | |||
if PY2: |
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.
Might make more sense to move this block up to line 44, instead of having the if statement down here.
Is there any way to support this pull request? |
I note that the master is no aiming at a |
@@ -172,6 +172,7 @@ def run(self): | |||
'google.protobuf.internal.message_listener', | |||
'google.protobuf.internal.python_message', | |||
'google.protobuf.internal.type_checkers', | |||
'google.protobuf.internal.utils', |
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.
Given that we rely on setuptools
(boostrapping from ez_setup.py
if it isn't present), we should be able to use its find_packages()
rather than enumerating modules by hand.
Hi, Until support of python, I share my workaround, a script to convert to python3:
2to3 is a tool provide by python3. |
@mrovner I believe this PR can be closed without merging. Please confirm. |
@Kentzo protobuf now officially doesn't need to support python 2.5 and 2.6. Would you like to rebase this such that only 2.7+ is supported? |
@tamird I don't have time to review that right now. We don't plan to migrate to 2.6 anytime soon. Any help is welcome :) |
@haberman probably time to close this guy :) |
Ah yes, this has been addressed in other changes. Closing now. |
Fix email links
Here I'm going to address remaining issues by merging changes from my diverged fork that made Protobuf 2.5.1 compatible with Python 3 by retaining compatibility with all other supported versions.
I kindly ask authorized developers to review and leave comments and I'll try to address them as soon as I can.
A few questions: