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

[Terry Reedy]

"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