A decorator syntax not yet mentioned (I think!)

[Michael Sparks]

Peter Hansen wrote:
> Carl Banks wrote:
>> One thing that's different is that, in all those cases, the second
>> block has a keyword that can't appear alone.  You can't have an
>> except without a try, or an else without an if, but you could have a
>> def without a decorate.
...
> is this an argument based on presumed difficulties in
> implementing the idea?

Looking at the wiki it states (as negative points):
   1 New keyword
   2 Overkill for the simple case like classmethod
   3 Many people felt it was wrong use of an identation suite.
   4 Has the same problem as 5.A, in that the decorate block implicitly
     affects the following def. This does not occur elsewhere in Python.
   5 Technical problems with the current grammar parser if a suite
     *starts* with an optional part. (Ending with an optional part, such
     as "else:" is OK, but starting with one is not.) 
   6 No implementation currently exists. 

1 isn't a huge issue if the syntax has significant benefits - but I
suspect that they would have to be significant to warrant the change.
(Guido says he's more relaxed about the idea, but that might me a
relaxation to just "No" rather than "no way, no how, buzz off" kind of
feeling :)

As per the comment on the wiki regarding 2), I'm not convinced that:

decorate:
   staticmethod
def somefunction(some, args):
   """some 
   multi line
   comment"""
   x=function(call)
   if x = ...
      ...
   etc...

is worse than:

def somefunction(some, args):
   """some 
   multi line
   comment"""
   x=function(call)
   if x = ...
      ...
   etc...
somefunction = staticmethod(somefunction)

It *is* marginally longer than @staticmethod, but I don't think it's any
worse ?  On the positive side the "decorate" approach appears to me
MUCH clearer in complex cases, which strikes me as more pythonic. I
love perl and python about as much as each other, but for different
reasons - with one of the things I like about python is that when code
gets complex it generally stays readable.

Item 3 is opinion, but I don't know where the arguments are leading to
that point, so I'll just take that at face value. I'm not convinced,
but hey :)

Regarding 4, it strikes me that this isn't the case (unless it strictly
means "block"!). An import at the beginning of a block changes the
meaning of a block. Similarly a class statement changes the meaning of
the defs immediately following it. I'd agree that it's not ideal, but
the argument that code preceding the def isn't allowed because it
changes the meaning of the def doesn't make sense to me - that's what
the @ syntax does.

Item 6 is always the case for any new feature, so I doubt that's the
real problem - the real problem here strikes me as item 5. 

I do wonder how difficult it would be to add though... 


Michael.
-- 
Michael.Sparks at rd.bbc.co.uk    
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.