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

[kirby urner]

Yeah, I like those programs with (args, kwargs) for everything (not).
A catchall eat_your( **spinach ) could be the signature of this
programming style.  Better that than a lot of side-effects though.  I
agree with Patrick O'Brien (missed seeing this year) that FoxPro was
too reliant on globals, still gave a lot of power to DB managers
though.

http://www.ibm.com/developerworks/library/l-pyint.html

[ Patrick worked on wxPython tools inspiring more introspective shell
genre, went on to pioneer Schevo, a worthy target of study for any CS
major looking for something interesting I would imagine ]

http://www.schevo.org/wiki/ObjectRelationalDivide

Anyway, I just wanted to encourage our herding of noobs (could be
experienced LISPers) into the 3.x tunnel, as the 2.x tunnel is
deprecated for theoretical work i.e. if you're "in it for the
language" (like a connoisseur of fine wines) then Python 3.x is simply
a better Python, at least so far.  Better unicode handling for one
thing (top-level Chinese if you like (a focus of my Python for
Teachers, now out in 57 and 3 min formats (creature feature, short
teaser))).

Kirby

On Thu, Apr 16, 2009 at 12:17 PM, David MacQuigg
<macquigg at ece.arizona.edu> wrote:
> At 07:07 PM 4/15/2009 -0700, kirby urner wrote:
>
>>> 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.
>
> There may be two lessons to learn from the breakage of the print statement.  One, as you suggest, is that even the most brilliant designer can make mistakes.  The lesson I had in mind is much more specific and "actionable".  When you design a function, use keyword arguments to allow for future modifications.  New keywords can be added, and old ones deprecated, without breaking existing programs.  The same lesson can be emphasized with examples comparing lists to dictionaries, or looking at the syntax in common protocols like SMTP.  Never assume things won't change.  Design for the future.  Make it a habit.
>
> It is amazing to me how this lesson is ignored by professional programmers, "design-by" committees, and even programmers working on big projects they know will be around for years.  Look at the original design of SMTP.  The HELO command had no allowance for extra parameters.  They had to change to a whole new EHLO command, and mandate an awkward recovery sequence to be used when an old receiver choked on the new EHLO command.
>
> Guess what.  They still didn't allow any flexibility in the syntax of the new EHLO command!!  Spammers took over email, and we have now wasted 10 years debating how a transmitter should declare the domain accepting responsibility for a requested mail session.  Wouldn't it be nice if we could just add a few characters to the request, like 'ID=yahoo.com'.  This substring would be interpreted correctly by new receivers, and ignored by old ones.
>
> Sorry to ramble on about my pet peeves, I'm sure anyone with experience can come up with their own examples.
>
> -- Dave
>
>