[Python-Dev] Re: Python-checkins digest, Vol 1 #370 - 8 msgs

[Guido van Rossum]

> > Am I responsible for everybody else's bad coding style?
> >
> > If it's not in the docs, where does everybody get the idea that this
> > is legal?  (The few cases in the std library are unlikely to be the
> > only source; they were in pretty obscure places.)
> 
> I think you're responsible for a little bit of the confusion.  Most
> people read the docs at the beginning to learn the basics, and then
> experiment with the interpreter.  The fact that it worked is naturally
> interpreted by users as meaning that it should work.  Very few of
> Python's semantics are accidental, so people "believe" the interpreter.

It's a fair cop.

> Teaching people when ()'s are necessary in Python and when they're not
> is not a trivial task if you're talking to someone who'se never heard
> the difference between a parse tree and a pear tree.  In my courses I
> typically say "()'s are sometimes optional" and leave it at that -- I
> expect the students' experience to guide them.  That experience will be
> interaction-driven, not doc-driven.

Yes -- and this is one reason why I want to fix append().  I should've
fixed it years ago.

> max/min() is another example, btw.  What's the "right" way?  To call
> them with N arguments where N > 1, or with a sequence argument?  If I
> look it up in the doc, I can tell (it's the latter, folks) -- but it
> seems arbitrary.  After all, the max/min calls/macros typically used in
> other languages require 2 arguments, so extending that to N arguments is
> conceptually at least as easy as shrinking it to a sequence argument.

This is different.  Maybe the docs are wrong; I always intended for
both max(a, b, ...) and max(seq) to be valid.

(BTW, perhaps the __contains__ changes should be extended to __max__
and __min__?  They share many of the same issues.)

--Guido van Rossum (home page: http://www.python.org/~guido/)