-
Notifications
You must be signed in to change notification settings - Fork 18
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
First attempt to port the repo from python2 to python3 with 2to3 #79
base: master
Are you sure you want to change the base?
Conversation
@grumpyhome/reviewers: Maybe we should talk about supporting Python 3.X host at least. Not about supporting code, this is about the interpreter that runs the transpilation tools. This branch allows a machine with Python 3 installed to run Grumpy. We will need to talk about pythonparser and stdlib issues, but it should occur someday. |
Caution: 2to3 often breaks Python 2 code to achieve Python 3 functionality. Given that we want code that is compatible with BOTH Python 2 AND Python 3, I would advise avoiding 2to3 and going with http://python-future.org or https://python-modernize.readthedocs.io instead. I like futurize but others might disagree. |
I think the same. @cgl coded a proof of concept, if I understood correctly. Looks like is not that hard to make Grumpy work with a Python 3 host. |
To be clear: I am not proposing to merge something that works for Py3 and breaks the Py2 tests. At least not on this decade It is for talking about how to support Py3 host too, given that it is possible. |
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.
A few areas where 2to3 breaks Python 2.
@@ -96,19 +96,19 @@ def _RunOneBenchmark(name, test_func): | |||
"""Runs a single benchmark and returns a _TestResult.""" | |||
b = _Benchmark(test_func, 1) | |||
result = _TestResult(name) | |||
print name, | |||
print(name, end=' ') |
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.
if from __future__ import print_function
is not placed at the top of this file before all other imports then this line will by a syntax error in Python 2.
traceback.print_exc() | ||
else: | ||
result.status = 'passed' | ||
ops_per_sec = b.N / b.duration | ||
result.properties['ops_per_sec'] = ops_per_sec | ||
print 'PASSED', ops_per_sec | ||
print('PASSED', ops_per_sec) |
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.
if from future import print_function is not placed at the top of this file before all other imports then this line will print something different that expected in Python 2.
@@ -18,7 +18,7 @@ | |||
|
|||
# Test Add | |||
assert "foo" + "bar" == "foobar" | |||
assert "foo" + u"bar" == u"foobar" | |||
assert "foo" + "bar" == "foobar" |
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 removal is unnecessary in all currently supported versions of CPython (2.7, 3.4, 3.5, 3.6, 3.7)
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.
The meaning changed. Should be b"foo" + u"bar" == u"foobar"
I guess.
Given that is about Xmas and we are far from getting Py 2.7 compliance, how do you feel about changing the whole toolchain and target to, lets say, Python 3.4 ? |
Why target 3.4 when it's EOL date is just 3 months after Python 2's?? My vote would be a direct shift from Python 2.7 to Python 3.7. It is going to take us years to get there and anything less than Py37 will already be EOL by the time we reach the finish line. EOL dates are https://devguide.python.org/#branchstatus |
I see. You are right on this point. My concern is that implementing syntax changes is yet hard for me. I am still struggling to properly get Docstrings to work. 3.5 includes async/await, that are really awesome and have a great fit with the Go programming style. But will take looong to be done, for example. At least 2.7 syntaxes are done, and up to 3.4 I do not remember anything bizarre that got added. |
I think it would be great to teach grumpy to determine which python we are, so in to continue transcode based on this environment. So py7 functionality can stay unchanged. At the same time, everyone who can not wait to teach grumpy Py3 (me too) could debug it for the main branch. What do you think? |
@andgrew it mostly works, but the tests infrastructure do compare system Python output to Grumpy output, and Grumpy will be different than Py3k at the 1st moment at least. Your idea is reasonable, but how to handle this? |
I think we should keep working tests for the py2 environment, while at the same time correcting breaking tests for the py3 environment step by step. I can take the task of introducing such system with your consent. Or it's yours, @alanjds ? Although I have not yet figured out all the mechanisms of Grumpy, but here everything is clear, so it is just need to implement. and it's interesting for me. |
Consent? :P Go ahead!. My actual task is to reimplement the Go ahead. I will help as much as I can. Open issues, send PRs, ask for help. I really liked the approach @cclauss suggested about using https://python-modernize.readthedocs.io on the whole codebase. But I would do it per-module instead, to be able to bissect the bugs between the commits. |
Also here is a small how to install the repo for development :)