> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4