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

[Arthur]

On Fri, 6 Aug 2004 13:15:52 -0500, Michael Ekstrand
<python at 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