Decorators proposal

[RebelGeekz]

Just my humble opinion:

def bar(low,high):
meta:
accepts(int,int)
returns(float)
#more code

Use a metadata section, no need to introduce new messy symbols, or
mangling our beloved visual cleanliness of python.

Please, let common sense guide your passion.

"When in doubt, copy python"

;-)

 

[Daniel Dittmar]

Just my humble opinion:

def bar(low,high):
meta:
accepts(int,int)
returns(float)
#more code

Use a metadata section, no need to introduce new messy symbols, or
mangling our beloved visual cleanliness of python.

+1

This also allows to set function properties inside of the function
def handler (match):
meta:
pattern = re.compile (...)

equivalent to

def handler (match):
...
handler.pattern = re.compile (...)

Daniel

 

[Christopher T King]

+1

This also allows to set function properties inside of the function
def handler (match):
meta:
pattern = re.compile (...)

Ooh, perty! I especially like the extension of this idea into function
attributes; it looks even cleaner than the .attribute syntax I like.

The only problem I see with this is that Guido seems to want decorators to
be more prominent than the function signature itself, so he probably
certainly won't go for "hiding" then in a doubly-nested block. (I write
"hiding" in quotes because I'm of the opinion that placing decorators
after a one- or two-line function signature does nothing to obscure the
decorators.)

 

[Jeff Shannon]

Ooh, perty! I especially like the extension of this idea into function
attributes; it looks even cleaner than the .attribute syntax I like.

The only problem I see with this is that Guido seems to want decorators to
be more prominent than the function signature itself, so he probably
certainly won't go for "hiding" then in a doubly-nested block.

More to the point, GvR seems to have decided that decorators, as
something that *wraps* a function, belong *outside* the function def
rather than inside it. Being inside the def implies that it's internal
to the function, which decorators are not.

I can see the logic in that, but I really dislike the contorted prefix
syntax that's necessary to support the alternative.

Jeff Shannon
Technician/Programmer
Credit International

 

[Brian van den Broek]

Jeff Shannon said unto the world upon 2004-08-10 14:52:

More to the point, GvR seems to have decided that decorators, as
something that *wraps* a function, belong *outside* the function def
rather than inside it. Being inside the def implies that it's internal
to the function, which decorators are not.

I can see the logic in that, but I really dislike the contorted prefix
syntax that's necessary to support the alternative.

Jeff Shannon
Technician/Programmer
Credit International

Hi all,

I'm far too new to programming and Python for my opinion to have even
feather-weight. I'd been wondering about something similar to the above
the last few days, but hadn't posted as I didn't feel informed enough
about the issues. Now that this sort of solution is under some discussion,
though, I cannot resist.

From reading much of the @-explosion in the python-dev list it seemed to
me that Guido's main objection to any syntax that put the decorators after
the def was that it made it look like the decorators were part of the
executing function, rather than run only when the def is first run.
(Similar reasoning seemed behind the expression of regret that docstrings
aren't above defs.)

Both for decorators and docstrings, putting them above seems odd to
me--documenting and modifying what exactly? Oh, something lower down :-|
This way seems to separate them from the function's executable code, yet
put them where my brain seems to expect them. And, the extra indent makes
them fairly prominent to my eye.

The other objection I've seen a lot to the general sort of thing proposed
above would be that it takes a new keyword (though I've read Guido
relaxing the "no new keyword for decorators" restriction). Could that be
met either by using a bare ':' or by having ':meta'? (Maybe I am wrong,
but :name isn't legal outside of slicing is it? And certainly not as the
start of a line? Thus, wouldn't this eliminate any conflict between this
use of 'meta' and any possible use of 'meta' as a variable?)

Anyway, conceptually and aesthetically this sort of proposal seems the
best I've read about. Here's hoping someone with more credibility,
knowledge, and a better sense of pythonic politics [not meant with any
snide tone] decides to champion it.

Best to all,

Brian vdB