PEP 318: Can't we all just get along?

[Michael J. Fromberger]

In article <mailman.1945.1092911723.5135.python-list at python.org>,
 Paul Morrow <pm_mon at yahoo.com> wrote:

> Michael J. Fromberger wrote:
> > 
> > Oh, I see it just fine -- but I still disagree with the idea of 
> > including any such implicit magic in the language.  
> > 
> > In fact, I don't like some of the magic that is already there -- such 
> > as, for instance, the automatic mangling of class members whose names 
> > begin with a double underscore to get "private" semantics.  But that, at 
> > least, is easy to avoid, if one doesn't want to use it.
> > 
> 
> Unless of course you want a method to be private/semi-private.  How do 
> you feel about the way we can create/manipulate lists and dictionaries 
> using special (magical) syntax?  Why is that different (acceptable)?
> 
> 	x = [10, 20, 30]
> 
> is shorthand for what would be much more code in other languages. Is 
> that syntax ok but
> 
> 	def __iAmPrivate(): pass
> 
> isn't?  Why?

I'm glad you asked this question -- you have highlighted an important 
distinction we should all heed.  In short:  The special syntax for list 
construction (to use your example) is "explicit magic" rather than 
"implicit magic."

Use of a square-bracketed tuple for list construction is almost 
completely orthogonal to other language features (modulo indexing), it 
correlates well to other familiar notations for lists, and it improves 
the readability of the code without obscuring anything.  These are some 
key hallmarks of good syntax.

By contrast, the special leading-double-underscore convention for class 
members and the idea to identify instance, static, or class methods 
based on the name of their first parameter, are not even a visibly 
syntactic change.  Each of these ideas specially overloads the single 
most common programming-language operation -- interpretation of a 
variable name -- under particular circumstances.  This technique is (as 
far as I know) nearly unprecedented in other languages, so it would be 
surprising to most programmers.  Furthermore, I think it makes code less 
readable, by hiding important facts inside an implicit assumption about 
the content of non-keyword identifiers, which are otherwise never 
special.

Many people respond to this by saying, "The programmer has to be careful 
anyway, so what is one more thing?"  You could ask the same question 
about drivers and beer.  Little distractions add up to big mistakes.

Let me add that I do not intend to assert that all syntactic sugar is 
bad (even if, as Alan Perlis suggested, "syntactic sugar causes cancer 
of the semi-colon" :)   However, the simple fact is, unless there is a 
really good reason, we shouldn't make programmers (i.e., ourselves) 
memorize more special cases.  Going back to your example:  There is an 
excellent case for a compact and orthogonal list construction notation.  
There is no good case for magically overloading non-keyword identifiers 
in certain contexts -- especially when there is a better and more 
explicit way to do it.

Thank you for your good example, Paul.

Cheers,
-M

-- 
Michael J. Fromberger             | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/  | Dartmouth College, Hanover, NH, USA