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/)