Bill Janssen <janssen at parc.com> writes: >> In the discussion on decorators months ago, solutions involving >> special syntax inside the block were ruled out early on. Basically, >> you shouldn't have to peek inside the block to find out important >> external properties of the function. > > Guido, could you expand on this principle a bit? Just stated as it > is, it sounds as pointless (to my untutored mind, at least :-), as the > arguments about "@ is ugly, so it shouldn't be used". After all, > isn't "what the function does" an important external property of the > function, and don't you have to peek inside the block to determine > that? For instance, how do you know whether a function is a generator > unless you look for yield statements inside it? I'm not Guido (obviously), but: You look at the documentation. The fact that Python doesn't divorce interface declarations from implementation is convenient for authors, but in some ways a trap for readers/maintainers (this is not a design criticism -- it was probably the right design choice). I often have to look inside Python functions to understand them, and find that their authors expect me to do so. I think a style that cleanly delimits interface and implementation as much as possible should be encouraged. The fact that docstrings sit inside the function block make that harder to achieve; that's why I'm glad to hear that prefix decorators are being considered for docstrings. That said, I'm not sure that "immediately following the opening colon" is such a bad place for interface-y things. It's nice that you can find the whole function's declaration by looking forward from "def ..." today [except for the decorators, of course ;-(]. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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