[Python-Dev] Re: method decorators (PEP 318): elevate ':'? (original) (raw)

Terry Reedy tjreedy at udel.edu
Sun Mar 28 15:49:08 EST 2004

"Skip Montanaro" <skip at pobox.com> wrote in message news:16486.54752.565545.542406 at montanaro.dyndns.org...

My argument against '@' expressions is simply that they will be confusing. They will appear to be part of the function body, and unlike doc strings will almost certainly involve evaluation of general expressions, at least in some cases. I think that will make it confusing (for newbies, at least) that those expressions are actually evaluated at function definition time and not at function execution time.

I think this and similar proposals for def-time code in the body would be very confusing for beginners and at least a little for most everybody (including me). Indeed, I don't especially like definition-time doc strings in what is otherwise the run-time body. (This is not a problem for modules and classes since their definition time is their run time.)

So I would instead propose that ':' be elevated from visual enhancement to essential separator of definition-time text/code from run-time code.

If this were done, then attribute assignment could be done with either a bare dict literal or perhaps better, as with classes, normal assignment statements. Post-processing calls could also be normal calls, which would eliminate the implicit l2r vx r2l issue. Multiple decorator call would be either explicitly nested or explicitly sequential on separate lines or separated by ';', just as now. For visuall emphasis, and to help the compiler and other tools, I also propose '::' as a marker for the presence of the optional definition-time post-processing suite. Example:

def meth(self, b, d):: 'a method with attribute and postprocessing'

retain abbreviation for doc = 'something'

author = 'me' # attached to original meth meth=classmethod(meth) boo = 'yes' # gets attached to new wrapper meth, not original function : #dedent? pass

PEP 318 and the various proposals therein do two things: 1) move the decoration code from after the body to before the body and 2) change it from normal, explicit, executable code to some new form of implicit declaration syntax , maybe with embedded expressions, maybe not. I suggest consideration, at least as a baseline, of a minimal change that would allow the relocation of decorator code as is.

Starting from this, it would be possible, though not necessary, to define a bare identifier such as 'classmethod', in this context, as a defaulted call and reassignment, as proposed. But I am not sure the keystroke saving is worth the inconsistency with the usual rules and the certain stimulation of requests for similar tricks elsewhere in the language. A plus for the abbreviation would be minimal decoration like this:

def f(self):: classmethod:

Perhaps the abbreviation could be defined valid only if it follows on the same line.

Doc strings: the current

def f(): 'doc' pass

would remain, perhaps indefinitely, and be defined as an abbreviation for

def f():: 'doc' # which abbreviates doc_ = 'doc' : pass

Terry J. Reedy

More information about the Python-Dev mailing list