At 09:23 AM 6/26/04 -0500, Jeff Bone wrote: >>Uh, the WHOLE POINT we want this is to have side-effects. If it doesn't >>make the function act in a different way, it might as well live in the >>doc string or something. > >Declarative vs. imperative. Design-time *definitional* modification of >behavior vs. runtime. I don't really think you want side-effects in the >literal sense. Actually, he very well might, and a number of other people definitely do. One use case repeatedly mentioned on Python-Dev has been to register functions or classes with frameworks, therefore definitely involving a literal side-effect (i.e. modification to an unrelated data structure). (I wonder if I should submit a patch for PEP 318 to add this to the motivation section, because it seems a lot of people keep repeating this "no side-effects metadata" misconception.) >E.g. "classmethod" isn't a side-effect, it's a definitional thing. If you >really want side-effecting operations on functions, you've already got >that given higher-order / first-class functions. Please read the current "Motivation" section of PEP 318. The point isn't that such operations aren't possible, it's that they're not very readable in standard Python syntax. In contrast, most other languages with first-class functions allow function definitions to be used as *expressions*, which means that they can be nested within a decoration expression, giving the reader a context for understanding the function definition. PEP 318 seeks to remedy this clarity/readability issue, by providing an alternative syntax for expressions that will "wrap" a function definition that follows.
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