preparsing print into python3 format

[edgarcosta]

Hello,

Given that we are trying to move into python3, should we preparse

print foo

into

print(foo)

with deprecation warning?

This will make sure that old code, written in python2 style could still run, and not fail because of a miserable print.

Cheers,

Edgar

CC: @kevindilks @jplab @kcrisman

Component: python3

Keywords: days88

Reviewer: Matthias Koeppe

Issue created by migration from https://trac.sagemath.org/ticket/23674

[jdemeyer]

comment:1

I don't think we should go that way. It should not be the goal of Sage to do that. Just use the Python 3 syntax in your own code, possibly with from future import print_function.

[edgarcosta]

comment:2

I understand your point of view, however, with that approach, a lot of homemade code will get broken whenever we do the switch because of a print.

Just consider the case of someone running a long term computation and at the end, it will fail because the user tried to print the result. However, his code run totally fine in the previous version of sage.

[edgarcosta]

Changed keywords from none to days88

[fchapoton]

comment:4

In my mind, the idea is the following.

At some point (hopefully, but this may never happen given the amount of remaining work and the sparsity of workers) there will be a release of sage working and passing all tests with python3. At this point, development of sage for python2 will stop. Users will have the choice either to continue using the "old python2 sage" or to switch to the "new python3 sage". This will imply that they need to refresh their code, and this will be advertised LOUDLY. Transition to python3 is a pain, and we cannot avoid to impose this pain to our users.

[kevindilks]

comment:5

Another potential issue could be pre-made notebooks for educational purposes that aren't necessarily being actively maintained.

I think there are lots of people using Sage that won't be reached without deprecation warnings in the code itself no matter how loudly we advertise.

[jdemeyer]

comment:6

Replying to @edgarcosta:

Just consider the case of someone running a long term computation and at the end, it will fail because the user tried to print the result.

You should never do a long term computation without testing small cases first. If you test your own code properly, what you describe shouldn't happen.

Besides, there are many more ways how a long term computation could break.

[edgarcosta]

comment:7

I think there are lots of people using Sage that won't be reached without deprecation warnings in the code itself no matter how loudly we advertise.

I agree an alternative is to deprecate the

print foo

just before we switch to python3.

[jhpalmieri]

comment:8

Replying to @edgarcosta:

just before we switch to python3.

Or well before.

[haraldschilly]

comment:9

I just got pointed to this ticket. What's the current status? I think it's a real problem if existing textbooks and student assignments (used year after year for teaching) will no longer work because of that change. IMHO it would be ideal to let the preparser understand old print statements. I don't care if there is a deprecation warning or not, just that those old code snippets still work.

[nbruin]

comment:10

Making print a function is straightforward:

It basically boils down to making from future import print_function the default in the sage interface if we want to do it before switching to Py3 and doing nothing if we don't.

Now for the preparser bit (that's the relatively hard part):

It's very easy to detect if there's a print-statement related syntax error: That's just print<not followed by whitespace*\(> (a regex should be able to do that). The tricky bit is to decide what to do next. If we assume that this is indeed a print statement, I guess that whatever comes after it (until newline of ";") must be the argument, so probably a reasonable guess is to put that whole thing between parentheses.
Doing that should probably be accompanied with a warning.

I think this is actually not that bad to do: we're only rewriting code that would otherwise be a syntax error.

Of course there are cases we don't catch, because there are print statements in python2 that are also valid syntax in python3, but with a different result:

Python 2:

>>> print(1,2)
(1, 2)

Python3:

>>> print(1,2)
1 2

I don't think there's anything we can do about that. Our only option is to interpret it as valid Py3.

Note: It's tempting to reach into "2to3" and use its fixer for print. I don't think that will work very well, because 2to3 actually constructs a parse tree. Probably sage's preparser would be much nicer if it did that too, but it doesn't. So integrating 2to3's fixer would be painful.

[dkrenn]

comment:11

Replying to @jdemeyer:

I don't think we should go that way. It should not be the goal of Sage to do that. Just use the Python 3 syntax in your own code, possibly with from future import print_function.

Replying to @fchapoton:

In my mind, the idea is the following.

At some point (hopefully, but this may never happen given the amount of remaining work and the sparsity of workers) there will be a release of sage working and passing all tests with python3. At this point, development of sage for python2 will stop. Users will have the choice either to continue using the "old python2 sage" or to switch to the "new python3 sage". This will imply that they need to refresh their code, and this will be advertised LOUDLY. Transition to python3 is a pain, and we cannot avoid to impose this pain to our users.

I agree with these two comments. The change to Python 3 will most likely break Python 2 written code as there are a lot more incompatible changes than print. I do not think, that print should be an exception here.

Therefore a -1 for using the preparser for this.

[DaveWitteMorris]

comment:13

I think this ticket is obsolete.

[mkoeppe]

Reviewer: Matthias Koeppe

[mkoeppe]

comment:14

I agree, let's close it