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

[David MacQuigg]

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