python 2-3 compatibility and gotchas

[marwahaha]

compatibility

Perhaps this has been previously discussed. It would be great to ensure that all code is compatible with python 2 and python 3. This ensures that the installation version does not hinder the learning. The syntax is similar enough that we should not take a purists' stance here.

gotchas

There are simple things that may confuse instructors used to one version, but the students report a different output. It may be useful to add to the lessons as notes to instructors on some brief/potential gotchas:

• print(range(3)) (one prints a list, one doesn't; can be fixed with print(list(range(3))))
• np_array*2.0 (do you need to multiply by floats in both versions?)
• print 'hello' vs print('hello')
• 5/2 and integer division

I used to maintain a list of differences that beginners commonly run into, perhaps we can incorporate some of this: http://python.berkeley.edu/learn/

[rgaiacs]

Perhaps this has been previously discussed.

It was.

It would be great to ensure that all code is compatible with python 2 and python 3.

As far as I remember, we are supporting and teaching Python 3. We signed the Python 3 statement which says

For all of these reasons, the following projects have pledged to drop support for Python 2.7 no later than 2020

As far as I remember, we are requiring/recommend learners to install Python 3 for more than a year. I expect that instructors teach using Python 3 (from their default installation or using a virtual environment) to avoid different output from the learners.

[marwahaha]

I think our lessons should be Python 2 compatible and Python 3 compatible.

For example, this fahr_to_kelvin lesson should work for both Python 2 and 3.
http://swcarpentry.github.io/python-novice-inflammation/06-func/

This can be mitigated easily with a 5.0 or 9.0. This can be so frustrating to the novice programmer! I'd rather a working solution be in our initial examples, as opposed to the function "breaking" for Python 2 users and a "pinned note" for the instructor.

Encourage Python 3, but don't break Python 2 if we don't have to, and warn instructors about gotchas - this feels robust.

[rgaiacs]

I think our lessons should be Python 2 compatible and Python 3 compatible.

I disagree. When I learnt Fortran I hate that my instructor was enforcing our code to be Fortran 77 compatible.

For example, this fahr_to_kelvin lesson should work for both Python 2 and 3.
http://swcarpentry.github.io/python-novice-inflammation/06-func/

This can be mitigated easily with a 5.0 or 9.0.

Realistic, except for significant figures reasons, who does write 5.0 or 9.0 when coding or in reports? By default coders are lazy and will avoid type as much as possible.

I'd rather a working solution be in our initial examples, as opposed to the function "breaking" for Python 2 users and a "pinned note" for the instructor.

If a learner is using Python 2 for what ever reason, they should be aware of the differences between Python 2 and Python 3. Otherwise, we don't need to cover it.

Encourage Python 3, but don't break Python 2 if we don't have to, and warn instructors about gotchas

This is the case of print-function vs print-statement. We use parenthesis to avoid it. For the division, I prefer that we "support" Python 2 by using

from __future__ import division

[annefou]

Thanks for contributing to the discussion.

I definitely agree with @rgaiacs
I think the mission of "The Carpentries" is to teach modern programming and trying to make our lesson python 2 "compatible" would not send the right "signal" to our learners.

@marwahaha do you mind if I close this issue?

[Autoplectic]

I believe we should stick to teaching python 3. There are several reasons for this:

• Making code cross-compatible tends to make it less elegant and readable.
• As per the BDFL, python 2 EOL is 1/1/2020, which is in only 18 months. python 2 will not even receive security updates at that point. It is a disservice to our learners to lead them into thinking it's OK to start new work on python 2.
• A note in setup that the inclusion of a from __future__ import division will make most simple mathematical code cross-compatible for those who insist on using legacy python should be sufficient.
• Continuing with backwards compatibility disallows use of any python 3 only features, should any be deemed sufficiently useful and simple enough for inclusion with a SC lesson (for example, perhaps f-strings at some point in the future).