By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,645 Members | 1,048 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,645 IT Pros & Developers. It's quick & easy.

Decorators proposal

P: n/a
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"

;-)
Jul 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
RebelGeekz wrote:
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


Jul 18 '05 #2

P: n/a
On Tue, 10 Aug 2004, Daniel Dittmar wrote:
RebelGeekz wrote:
Just my humble opinion:

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


+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.)

Jul 18 '05 #3

P: n/a
Christopher T King wrote:
RebelGeekz wrote:

Just my humble opinion:

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


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

Jul 18 '05 #4

P: n/a
Jeff Shannon said unto the world upon 2004-08-10 14:52:
Christopher T King wrote:
RebelGeekz wrote:
Just my humble opinion:

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

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


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

Jul 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.