@decorators

[Mark Bottjer]

Peter Hansen wrote:
> Mark Bottjer wrote:
> 
> Mark, would your example still be acceptable to you if someone wrote
> it like this?:
> 
>> def sillyFunction( a, b, c):
>>     """\
>>     The silly function does nothing except get "decorated." classmethod
>>     determines the form of the first argument (class, object, or
>>     other). signature changes the call behavior, asserting the types
>>     passed to and returned from the function. Finally, transactional
>>     causes boilerplate code to be executed before and after the function
>>     body, ensuring that either all changes to database are applied, or
>>     none are. Seeing as this function does nothing, this is trivial :).
>>     """
>>     @classmethod
> 
>
>     # PLH 20040806112957: added new decorator here
> 
>>     # PLH 20040806130023: also changed last value     @signature( 
>> None, a=int, b=float, c=dict)
>>     @transactional( database)
>>     pass

FWIW, I considered adding this case, but thought the post was long 
enough already. And I knew someone would bring me to task on it in short 
order anyway. :)

Of course it is still hard to read, but I personally find it easier than 
the prefix syntax for one main reason: the decorators are confined 
inside the function they modify. If the language were to state (for 
example) that all decorators are to appear between the def line and the 
optional docstring, than it becomes easy (easier, anyway) to parse, and 
for the programmer to navigate: find function def; start looking for 
meta stuff; stop looking at the first non-meta statement. No look-ahead 
is required, and no buffering for a declaration not yet started.

> While I find merit in your idea, it's not entirely fair to discard
> the @ syntax because it *can* be written the way you showed, but then
> not to perform the same analysis on your own idea.

I wasn't attempting to discard it. I was attempting to show a border 
case I had not seen discussed anywhere (as others have done with the def 
foo (ARGS) [DECS]: variants). To that end, I tried to show just how bad 
it could be. To make sure it had been considered was the sole intent.

> To be entirely fair, I'm not sure that *any* of the proposed syntaxes
> cannot be written in such a way that they get buggered up by intervening
> whitespace and comments...  nor should this be a sole reason for
> discarding any one.

Agreed. I *personally* find it easier to understand code with the 
decorators infixed than with them prefixed. To me, knowing that 
everything I want to know about a function is somewhere *in* that 
function, as opposed to somewhere *near* it, is quite a powerful aide to 
understanding. YMMV.

   -- Mark