[Edu-sig] New edu-sig page: first draft completed

[kirby urner]

On Wed, Apr 15, 2009 at 5:45 PM, David MacQuigg
<macquigg at ece.arizona.edu> wrote:
> Hi Andre,
>
> Nice work.  I have two suggestions, and a few minor edits.
>
> On the choice between Python 2 and 3, I would say teach both, but limit the Python 2 syntax to your specific needs.  Most students will see the print statement as the only difference, and learning both is not much burden, particularly if we make it an object lesson in not painting yourself into a corner with an inflexible initial design, which breaks backward compatibility when the enhancements to the original syntax get to be too much.
>

I'm not sure this is the object lesson.  Rather, a language designer,
no matter how brilliant, is likely to make at least a few basic design
choices which she or he later regrets, but the fixing of which would
by this time break backward compatibility, as the suggested changes
are rather primitive (some of them).  So then one builds a break point
into the time line, has a __future__ convention, gets people ready
well ahead of time.  Spoofing the Y2K hysteria was a final stroke of
brilliance.  Now we've successfully made the leap, fixed some base
problems, and the previous dino Pythons are still there, a veritable
Jurassic Park of living monsters, happy to take the stress of 2.x code
piles for eons to come (where eon is somewhat undefined in this
namespace).

I think your parody picture, of Python becoming top-heavy with
syntactic sugar and toppling over in a mess, leaving us needing to
teach two versions to noobs, with print() the only real difference, is
more a mockery of the actual situation.  In actual fact, it's somewhat
easier to go 3-to-2 than 2-to-3, and 3 really does fix some problems
(like division, and not having two kinds of classes -- "classic
classes", somewhat a spoof on "classic coke", need to go away).

If you're a fresh face around Python Nation, and not trying to join an
existing commit team already committed to an older version, then green
field development is the name of your game.  Or maybe you're waiting
for a library to catch up.  In my case, that's somewhat true, as
VPython is not yet available for 3.0, so our Vector class sits
languishing.  I'm field testing a class decorator solution, to
retrofit the visual API to my Vector and Edge objects, both investors
in the OpenGL cylinder concept.  I ran that by PPUG earlier today in
fact, for peer review.

Kirby


> On the use of a terminal window instead of IDLE, I can't see any advantage, except in a few very special situations, like when I am editing a program that uses tkinter, and there is a conflict between the program and IDLE, so I edit in IDLE and run from the terminal window.  Those situations can be dealt with in whatever help file is guiding the student in each situation.  I don't see any need to say "if you like programming directly from a terminal window".
>
> Here are some suggested minor edits:
> prefer to rely on --> prefer to have
> If you are among this group, you might --> You might
> The purpose of this section ... but to focus only --> Here we will focus only
> potential interests for educators --> potential interest to educators
> The following may be of interest for children, --> For children,
> and get independent feedback --> and get immediate feedback
> much fewer people --> many fewer people
> much fewer free software --> much less free software
> for making game: --> for making games:
>
> -- Dave
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>