[meta] Python3 vs Python2

[rgaiacs]

DISCLAIMER: I don't want to start a flame war.

Related with: #71 and #105.

I know that lots of Python packages are incompatible with Python3 and maybe never will be but lots of them already are (e.g. Numpy, Scipy, matplotlib, IPython, ...).

What about the Python lessons start using only Python3 print syntax?

Short version of why using Python3 print syntax

$ python2
Python 2.7.5 (default, Sep  6 2013, 09:55:21) 
[GCC 4.8.1 20130725 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print 'foo'
foo
>>> print('foo')
foo
>>> quit()
$ python3
Python 3.3.2 (default, Sep  6 2013, 09:30:10) 
[GCC 4.8.1 20130725 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print 'foo'
  File "<stdin>", line 1
    print 'foo'
              ^
SyntaxError: invalid syntax
>>> print('foo')
foo
>>> quit()

Long version of why using Python3 print syntax

Since Software Carpentry are teaching scientists how to better programming I think that keep using features that will be deprecated in "short" time instead of another that are back compatible isn't the way to show how to improve your programming skills.

[wking]

On Sun, Jun 29, 2014 at 02:36:43AM -0700, khinsen wrote:

The obstacles that were cited were almost exclusively little-used domain-specific libraries that nevertheless were essential for someone's work. A controller for a specific piece of lab equipment, or a library to read some weird file format. The kind of libraries written by a thesis student and then never maintained, often not even published.

This sounds like a good reason for us to be teaching Python 3 and maintainable code. Perhaps it will allow folks to unstick (and publish!) this sort of stagnant library. There are unlikely to be many external dependencies or reliance on Python 2's string/bytes ambiguity. Sticking your nose into someone else's first project is a difficult place to start learning to code yourself, but if the software is critical to your research, somebody has to start maintaining it.

[ahmadia]

+1 to a lot of the points made in this discussion, especially that many of the major libraries have moved over, but that the majority of code being written today is still not Python 3 compliant, and there is going to be some pain for students who are learning Python 3 but working with Python 2 code.

I think we have two options for handling the transition.

• We can pay about the same amount of attention to Python 2 that we currently pay to Python 3. That is, we mention that the print and exception statements work differently, but we don't spend any effort on writing Python 2-compliant code, and we don't explain what is needed.
• We work using the "single codebase" approach. That is, we only teach in code that will work in either a Python 2 or Python 3 interpreter. Since the core Software Carpentry lessons are either batteries-included Python or libraries that have already been ported to Python 3, this should not be difficult to support. This requires that we use the from __future__ import statements for both print and division, but will otherwise not be too bad. This has the added advantage that students working with legacy Python 2 code will have a better chance at being able to make it compatible with Python 3. @asmeurer has written a rather good article describing some of the points concerning this from a library author standpoint: http://asmeurersympy.wordpress.com/2013/08/22/python-3-single-codebase-vs-2to3/

Given all the risks everyone is bringing up, I think we need to seriously consider the second approach, even though it was voted against last year when we were considering how to make our code more compatible with Python 3.

Also, it gets hard to follow an issue when it gets long (and changes topics slightly). Should we open a new issue to discuss this?

[asmeurer]

The disadvantage there is that you can't teach any features that are Python 3 only (I have a presentation about that).

[fperez]

BTW, @takluyver and I will be running a BoF at SciPy'14 regarding issues about the py3 transition. Of particular note is that Nick Coghlan, core Python developer, will participate and help us brainstorm with his knowledge. He's spent a ton of energy on the python 3 transition (as you can see from his extensive notes on the matter), so I am optimistic this will be a productive discussion.

We'll obviously post a summary of whatever we learn and good ideas may come out of that session.

[takluyver]

And as I may already have mentioned, any of you who're going to Scipy should come to the BoF to discuss these issues. I think teaching is a critical part of the transition. I'll also be at EuroSciPy at the end of August, and I'd be happy to have a discussion there.

[wking]

On Sun, Jun 29, 2014 at 01:31:50PM -0700, Aron Ahmadia wrote:

This requires that we use the from __future__ import statements for both print and division, but will otherwise not be too bad.

I'm fine with “Python 3 only” or this “compatible with both” approach.

[khinsen]

@wking Concerning the importance of maintenance, this is something we'd need to teach PIs. It's rarely the PhD student returning from a bootcamp who gets to decide if time and money will be invested into maintenance. Did anyone ever consider a bootcamp for PIs, project managers, funding agencies, etc.?

[khinsen]

@fperez @takluyver That BoF sounds great. I'll watch out for notes and blog posts about it.

[takluyver]

We've started making notes for discussion here: https://github.com/ipython/ipython/wiki/Sprints:-SciPy2014-Py3-BoF

I've tried to summarise the most important points from this thread - it's a wiki page, so feel free to add questions and ideas. I'll report back on what happens.

[takluyver]

To inform this, in a recent workshop at Berkeley, we tried converting the Python parts of the course to Python 3 and teaching with that. It all basically went smoothly. A couple of people showed up with Python 2 installed despite the instructions, but they could follow along OK. I've noticed in recent workshops that some people show up with Python 3 when the course is using Python 2, and they usually have more problems than our Python 2 users did.

This was with a more intermediate group, I hope to try the experiment for a beginner level course as well.

We even managed to work the differences between Python versions into the testing session; @katyhuff got them to push tests to Github and set up Travis CI (which is pretty amazing, I don't think I've ever seen a workshop get that far before). They could then see the tests fail on Python 2 because of integer division, push a fix and watch them pass.

[takluyver]

(my comment seems to have unassigned @ahmadia - Github bug?)

[rgaiacs]

To inform this, in a recent workshop at Berkeley, we tried converting the Python parts of the course to Python 3 and teaching with that.

Thanks. We are now keeping the Python lesson at https://github.com/swcarpentry/python-novice-inflammation/. And I think that this year we are finally porting the lesson to Python3.

(my comment seems to have unassigned @ahmadia - Github bug?)

I don't see how.

[astrojuanlu]

According to Microsoft, Python 3 is winning. As the end of Python 2 approaches, more projects are making plans to drop Python 2 support in 2020 or earlier and encouraging users to switch. I'm sure all or almost all of you are already aware of these efforts, but just wanted to drop some links here one year after the last comment :)