Python and the Principle of Least Astonishment

Post by mixmastamyk » Sun, Jul 10, 2011, 2:54 AM UTC

julian37 wrote: post #49

aston wrote: post #40

Earlier quoted context omitted.

The better explanation is that there are a series of fallback actions for all of the top level functions that delegate to the .__whatever__ methods. For example, if you write a class that quacks like a collection that has a length (it implements .__len__) Python can use that to get a value for bool() even if you didn't implement .__nonzero__.

When people inquire about the len() function it is mainly because it is (or at least looks like) a global function rather than an object method. In short, people wonder why you have to call len(x) instead of x.len(). This is a valid concern seeing that Python's standard library is, by and large, object oriented (c.f. string methods like "upper" or list methods like "append" or file methods like "read"). Neither the a…

Post by dalke » Mon, Jul 11, 2011, 9:36 AM UTC

Kilimanjaro wrote: post #34

dalke wrote: post #33

Earlier quoted context omitted.

Would you mean this to be a namespace which only the Python implementation could access? For example, if the protocol "it:next" is added (which is equivalent to next(it)) then is there any way to support that syntax in an older version? With next() as a builtin it's easy; try: next except NameError, and in case of exception, implement the function yourself. But if I can't implement it myself then there's no good migr…

"is there any way to support that syntax in an older version" Nop, that is exactly what I meant with decisions haunting you forever. You better start a new language than radically change the current implementation. With regard to my particular choice of ':' there are three solutions: 1. pick any of the 100k unicode chars for internal methods but imperative is to differentiate them to freely use attributes and methods…