New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python 2-3 compatibility and gotchas #451

Open
marwahaha opened this Issue Jan 19, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@marwahaha
Contributor

marwahaha commented Jan 19, 2018

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

This comment has been minimized.

Contributor

rgaiacs commented Jan 19, 2018

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

This comment has been minimized.

Contributor

marwahaha commented Jan 19, 2018

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

This comment has been minimized.

Contributor

rgaiacs commented Jan 20, 2018

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 annefou added the discussion label Mar 3, 2018

@annefou

This comment has been minimized.

Collaborator

annefou commented Mar 3, 2018

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

This comment has been minimized.

Autoplectic commented Jun 29, 2018

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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment