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

_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

Reply via email to