compromise? keywords for static/class, move decorators to top offunction

[Doug Holton]

First let me say please see the wiki page about python decorators if you
haven't already: http://www.python.org/cgi-bin/moinmoin/PythonDecorators

I propose (and others have) that built-in features have keyword support,
like static and class methods. Also, I believe it is more readable if
decorators, especially longer ones, are moved to the top of the function
body, just like docstrings, instead of coming before the function is
even declared. Whether you use @ or [] is still open.

def classmethod getratio (arg1, arg2):
@accepts(int,int)
@returns(float)
...

def classmethod getratio (arg1, arg2):
[accepts(int,int), returns(float)]
...

This has these advantages: the function declaration itself is still the
first and most important thing, decorators are indented just like the
body of the function so it is more clearly a part of the function.

In the future though, if you add an "as" keyword for adapters, you could
just say:

def classmethod getratio (arg1 as int, arg2 as int) as float:
...

contrast that simple example with this, which is kind of ugly:

@accepts(int,int)
@returns(float)
@classmethod #has to be last in order?
def getratio (arg1, arg2):
...

[Michael Ekstrand]

On Friday 06 August 2004 12:54, Doug Holton wrote:

I propose (and others have) that built-in features have keyword
support, like static and class methods. Also, I believe it is more
readable if decorators, especially longer ones, are moved to the top
of the function body, just like docstrings, instead of coming before
the function is even declared. Whether you use @ or [] is still
open.

def classmethod getratio (arg1, arg2):
@accepts(int,int)
@returns(float)
...

Ooh... I like, I like...

This seems to be the most reasonable, readable proposition I've seen so
far. And I'd favor @ for this - it makes it clear that this is
"something different".

-Michael

[Arthur]

On Fri, 6 Aug 2004 13:15:52 -0500, Michael Ekstrand
<py****@elehack.net> wrote:

On Friday 06 August 2004 12:54, Doug Holton wrote:

I propose (and others have) that built-in features have keyword
support, like static and class methods. Also, I believe it is more
readable if decorators, especially longer ones, are moved to the top
of the function body, just like docstrings, instead of coming before
the function is even declared. Whether you use @ or [] is still
open.

def classmethod getratio (arg1, arg2):
@accepts(int,int)
@returns(float)
...

Ooh... I like, I like...

This seems to be the most reasonable, readable proposition I've seen so
far. And I'd favor @ for this - it makes it clear that this is
"something different".

It seems to me that Python is at its best when the naive approach, and
the schooled approach, coalesce.

I can only speak for the naive approach.

And - within the context of Python as it is -the possiblity of
requiring the placement of essential information related to defining a
method amd its behavior somewhere outside the method's body would
never occur to me.

Doesn't readibility require that you have the ability to move in a
direction down the page, and, if so, why am I getting information
about a method prior to the existence of the method, before a proper
introduction has been made, i.e. before I even know its name.

In short, I would agree with both points, built-in support to
disambiguate certain common cases from the case of something truly
meta-like and implementation specific going down, and the balance in
the method body.

Just repeating a thought - but it seems unnatural to be introduced to
lots of other information about something, before the normal
forrmalities have been attended to. Name please.

Art

[Larry Bates]

There are a lot of people talking about decorators
that I'm certain are a LOT smarter than me but here
goes:

Couldn't we use a dictionary construct like the one
used in classes to hold the dictionaries attributes.
I'm talking about __dict__ construct.

def getratio(arg1, arg2):
__decorators__['getratio']={} # Maybe this is automatic?
# or __decorators__['getratio']=__decoratorbase__.copy()
__decorators__['getratio']['classmethod']=True
__decorators__['getratio']['accepts']=(int, int)
__decorators__['getratio']['returns']=(float)
__decorators__['getratio']['metadata1']="some metadata"
...

I'm sure I'm missing something but this seems to
be 1) Easy on my eye, 2) Extensible (any metadata
that you want), 3) Consistent with something I'm
already comfortable with.

I'm certain that I'm missing something very important, but
I have to agree with many others, the '@' syntax just
doesn't feel correct.

Regards,
Larry Bates
Syscon, Inc.

"Doug Holton" <in****@spam.here> wrote in message
news:Oo********************@comcast.com...

First let me say please see the wiki page about python decorators if you
haven't already: http://www.python.org/cgi-bin/moinmoin/PythonDecorators

I propose (and others have) that built-in features have keyword support,
like static and class methods. Also, I believe it is more readable if
decorators, especially longer ones, are moved to the top of the function
body, just like docstrings, instead of coming before the function is
even declared. Whether you use @ or [] is still open.

def classmethod getratio (arg1, arg2):
@accepts(int,int)
@returns(float)
...

def classmethod getratio (arg1, arg2):
[accepts(int,int), returns(float)]
...

This has these advantages: the function declaration itself is still the
first and most important thing, decorators are indented just like the
body of the function so it is more clearly a part of the function.

In the future though, if you add an "as" keyword for adapters, you could
just say:

def classmethod getratio (arg1 as int, arg2 as int) as float:
...

contrast that simple example with this, which is kind of ugly:

@accepts(int,int)
@returns(float)
@classmethod #has to be last in order?
def getratio (arg1, arg2):
...

[Hallvard B Furuseth]

Larry Bates wrote:

Couldn't we use a dictionary construct like the one
used in classes to hold the dictionaries attributes.
I'm talking about __dict__ construct.

def getratio(arg1, arg2):
__decorators__['getratio']={} # Maybe this is automatic?
(...)
I'm certain that I'm missing something very important,

Yes: Decorators should be set before the function is called. Your
code is executed after function is called. Or if you define some
magic to avoid that, it still looks like it is.

--
Hallvard