Opened 3 years ago

Last modified 20 months ago

#23674 new task

preparsing print into python3 format

Reported by: edgarcosta Owned by:
Priority: major Milestone: sage-8.1
Component: python3 Keywords: days88
Cc: kdilks, jipilab, kcrisman Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

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

Change History (12)

comment:1 Changed 3 years ago by 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.

comment:2 follow-up: Changed 3 years ago by edgarcosta

  • Cc kdilks jipilab added

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.

comment:3 Changed 3 years ago by edgarcosta

  • Keywords days88 added

comment:4 follow-up: Changed 3 years ago by chapoton

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.

comment:5 Changed 3 years ago by kdilks

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.

comment:6 in reply to: ↑ 2 Changed 3 years ago by jdemeyer

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.

comment:7 follow-up: Changed 3 years ago by edgarcosta

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.

comment:8 in reply to: ↑ 7 Changed 3 years ago by jhpalmieri

Replying to edgarcosta:

just before we switch to python3.

Or well before.

comment:9 Changed 21 months ago by schilly

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.

comment:10 Changed 20 months ago by nbruin

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.

Last edited 20 months ago by nbruin (previous) (diff)

comment:11 in reply to: ↑ 4 Changed 20 months ago by dkrenn

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

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.

comment:12 Changed 20 months ago by kcrisman

  • Cc kcrisman added
Note: See TracTickets for help on using tickets.