On 9/27/2010 11:48 AM, Marco Gallotta wrote:
Hi there
I'm sure you get a lot of "2 or 3" questions, but here's another.
Umonya [1] uses Python to introduce school kids to programming. The
initiative is only 15 months old and up till now we've been using
existing notes and exercises and thus Python 2. But we're at the stage
where we can either stick with 2 for the next few years, or go to 3
now.
We received a grant from Google to reach 1,000 kids in South Africa
with our course in 2011. People have also shown interest in running
the course in Croatia, Poland and Egypt. We're also eyeing developing
African countries in the long-term. As such, we're taking the time now
to write our very own specialised course notes and exercises, and we
this is why we need to decide *now* which path to take: 2 or 3? As we
will be translating the notes we'll probably stick with out choice for
the next few years.
I would absolutely, definitely, move to Python3, with the the intention
of using 3.2 when it comes out in a few months. I suspect that most of
your exercise code will need little change beyond what 2to3 does for you.
Since these are kids, we feel the nice changes in 3 such as removing
integer division will help in teaching.
There are several half-finished transitions in late 2.x. Removal of
old-style classes, not only as the default, but completely, removes a
source of confusion. The range/xrange confusion is gone. The
input/raw_imput confusion is gome. I think most important for an
international project is the shift to unicode as the default text type,
including for identifiers. Kids who are not masters of English will want
to write identifiers in their own language.
> It will also remove confusion
when they go to download Python and grab the latest version. Since
they're just starting, chances are almost none will be hit by the
limited library support for at least a year or two.
I personally consider this pretty irrelevant for teaching programming to
kids. There is a *lot* in the stdlib to work with. And stdlib
improvement is getting special emphasis for 3.2. Bug fixes may be
backported, feature additions are not.
Even if one disagrees, 3rd-party library support is improving and will
continue to improve especially after 3.2 is released. For instance, the
recent release of numpy for 3.1 enables conversions that were blocked
waiting for that.
http://sourceforge.net/projects/numpy/files/NumPy/1.5.0/numpy-1.5.0-win32-superpack-python3.1.exe/download
For another example, the web-sig appears to have agreed on a minimal,
backward-compatible extension to PEP 333 to make wsgi work with Python3.
This will be PEP 3333. (It appears the problem was too many choices
rather than no choice. Discussion continues on more extensive
non-compatible changes.) This will allow existing wsgi tools to both
work with Python3 *and* continue to be intercompatible. (The latter was
the problem. If each tool made its own non-standard choice for Python3,
that latter property would be lost.)
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
