chapter7: Support both Python 2 and Python 3

[cclauss]

Make the chapter 7 code syntax compatible with both Python 2 and Python 3.

$ futurize -f fix_print_with_import -w src/chapter7

[jeff5]

@cclauss: Please see the note on Jython-dev about our (my proposed) approach to maintaining the book.

At the moment, I'm cleaning up the base Jython 2.5 so it publishes cleanly.

I think we shall have a branch for each Python version we support, a frozen 2.5 and an active 2.7. A Python 3 book (branch) would go with a Jython 3 release, which is some time off, so I'm not sure of the value of cross-version code. MAybe when we have a 3 and 2.7 versions concurrently it will be useful. So this and #7, #8, #9, #10, #11 and #12 may languish a while.

[cclauss]

I'm not sure of the value of cross-version code.

The value is quite clear to me:

1. It is not a good idea to teach new users idioms and syntax that officially expire in 233 days.
2. It is a good idea to teach new users the techniques that they will need to span both worlds.
3. It is error prone and redundant to edit multiple repos that have similar but incompatible code when you can easily edit a single repo that contains code that works both in the past and in the future.
4. I have helped to port a lot of projects to Python 3 and incrementally upgrading code is the key to success. The more that developers see that the code in Jython repos is looking modern, the more that they will be willing to submit PRs that help you finish the Jython port to Python 3.

I see people in my company writing new code that will be incompatible with the future because they are building on Jython. Your book could be showing them best practices so that they stop writing legacy code.

[jeff5]

Good points.

At the moment my aim is to get clean representation of the 2010 book, that publishes with a minimum of errors. That's one reason to delay applying these.

After that, it will be necessary to have branches so that the Jython 2.5 version of the book remains accessible while creating Jython 2.7 and 3 versions. I'm assuming there are contributors willing to create those versions, or rather, I'm preparing for that possibility.

Most of what people need to know about Jython may be learned by reading about Python, including the CPython documentation. We fixed on the book, just recently, as a place to describe how Jython differs from CPython. This was because we didn't think we had the energy to maintain a divergent set of Python documentation (forked from CPython's).

Given that the source is stored in the repo of the book, I conclude that there will be a copy for each version. I would not expect much maintenance on v2.5 branch.

You make a good case for these patches in the v2.7 branch, in the files where you have applied them. I think I would not do it in the in-line examples because of the clutter, but it would be worth describing the technique. 233 days from now, and for a while after that, readers will be using Jython 2.7 alongside CPython 3.

[adamburkegh]

Hi @cclauss actually jython supports print() without the import from __future__, at least in 2.7

C:\Users\Adam\jython\jython4>dist\bin\jython.exe
Jython 2.7.2a1+ (, May 9 2019, 11:51:47)
[OpenJDK 64-Bit Server VM (Oracle Corporation)] on java11.0.1
Type "help", "copyright", "credits" or "license" for more information.
>>> print('hi')
hi
>>>

That should make the change less verbose. Thanks for taking the time to submit this and the other v3 compatibility PRs.

[cclauss]

Python porting best practice says that we should prevent compatibility regressions. This import changes the way that Python 2 operates so that print statements are now syntax errors while print() function continues to work as expected. This prevents Python 2 developers from writing code that breaks compatibility with Python 3.

Proof:

• $ python2 -c "print 'This works...'"
• $ python2 -c "from __future__ import print_function ; print '...but this raises a syntax error.'"

The import is also required in any print statement that contains an unquoted comma.

$ python2

>>> print "hello", "world"
hello world
>>> print("hello", "world")
('hello', 'world')

[adamburkegh]

Thank you for explaining. I can see the systematic logic to this and understand why it is in the porting guidelines now. I think there is still a decision around its impact on inline explanations in a reference book, as Jeff points out.

While on the topic it is also unfortunately a jython bug with __future__.print_function() when using from an interactive console which might compound confusion.

https://bugs.jython.org/issue2007

[cclauss]

Would it be possible to have two branches in this repo?

• Branch Jython-2.5 could be for the "frozen" 2.5 code for the 2010 book and
• Branch master could be where we land chapter7: Support both Python 2 and Python 3 #6 thru chapter15: Support both Python 2 and Python 3 #12 plus some basic lint tests to ensure that the code in this branch is syntax compatible with both Python 2.7 and Python 3.

Thoughts?

[jeff5]

I agree. I proposed this on jython-dev and no-one has objected. It's what I meant by referring to the 2.5, 2.7 and 3 branches above. You may have noticed the edition tags appeared. I think eventually we will want a pure v3 version, if there is time to write one, because the Java API is likely to change and we will not want to teach Python 2 idioms.

I'm hesitating to create v2.5 and v2.7 (new master) branches now while there seem to be significant problems with the single edition as we have it, including #14 . Branching now is likely to double the admin fixing them, and I have a few other calls on my time.