First attempt to port the repo from python2 to python3 with 2to3

[cgl]

Also here is a small how to install the repo for development :)

brew install go

Fork and clone the repo

cd grumpy-tools-src/
python setup.py develop

cd grumpy-runtime-src/
python setup.py develop

pip install pytest pytest-cov

pytest

[alanjds]

@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.

[cclauss]

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.

[alanjds]

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.

[alanjds]

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 :trollface:

It is for talking about how to support Py3 host too, given that it is possible.

[alanjds]

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 ?

[cclauss]

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

[alanjds]

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.

[andgrew]

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?

[alanjds]

@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?

[andgrew]

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.

[alanjds]

Consent? :P

Go ahead!. My actual task is to reimplement the _codecs interface in pure-python. But I believe that Py3 support will unlock more people to help. Is hard to convince anyone to install something that will be deprecated by the end of this year (2019).

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.