Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Functions implement the descriptor protocol so that when you access them as an attribute of a class they basically return a partially applied function.

Exactly. You just spoke like a true Pythonista: you used an implementation detail in the language to justify a language design decision. In my experience, people diving into Python will not care (or want to know) about the descriptor protocol (it's not mentioned in the majority of books about the language). They will not be messing with __get__ or __set__ the vast majority of the time. Only much later, when they want to start doing fairly magic things with attributes, will they even realize it exists. There is no analogue for the descriptor protocol in any other currently popular language. How can you consider a magic-method protocol that curries all functions when accessed as an attribute the "explicit" or "simple" way to design this?

I guess this is why proposing this is so hopeless. Methods do not have to be distinguished from functions to create an implicit self. Instead of having FooClass.bar() and foo_obj.bar() do any of this [1] (please tell me with a straight face that the average Python programmer knows or cares about any of that) have the former add to the local namespace FooClass as self and the latter add foo_obj as self when the function is called, defined as the behavior of the language's syntax. Like, I dunno, JavaScript, or PHP, or Java, or C#, or... For the 1% of people that care, allow it to be overridden by redefining __get__ and so on. Maybe even redefine the deprecated apply() [2] so people can specify a different self in the course of calling of function, like in JavaScript.

[1] http://docs.python.org/howto/descriptor.html#functions-and-m... [2] http://docs.python.org/library/functions.html#apply



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: