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

Discussion in 'Python' started by Doug Holton, Aug 6, 2004.

  1. Doug Holton

    Doug Holton Guest

    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):
    ...
    Doug Holton, Aug 6, 2004
    #1
    1. Advertising

  2. Re: compromise? keywords for static/class,move decorators to top of function

    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
    Michael Ekstrand, Aug 6, 2004
    #2
    1. Advertising

  3. Doug Holton

    Arthur Guest

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

    On Fri, 6 Aug 2004 13:15:52 -0500, Michael Ekstrand
    <> 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
    Arthur, Aug 7, 2004
    #3
  4. Doug Holton

    Larry Bates Guest

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

    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" <> wrote in message
    news:...
    > 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):
    > ...
    Larry Bates, Aug 9, 2004
    #4
  5. Re: compromise? keywords for static/class, move decorators to top of function

    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
    Hallvard B Furuseth, Aug 9, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. AFN
    Replies:
    2
    Views:
    1,794
    bruce barker
    Jun 15, 2004
  2. Boki
    Replies:
    22
    Views:
    792
  3. Arien Malec

    PEP 318 decorators are not Decorators

    Arien Malec, Aug 13, 2004, in forum: Python
    Replies:
    11
    Views:
    559
    Arien Malec
    Aug 16, 2004
  4. Replies:
    9
    Views:
    383
    David Thompson
    Jul 1, 2007
  5. Eduardo78
    Replies:
    0
    Views:
    237
    Eduardo78
    Nov 3, 2005
Loading...

Share This Page