[Python-Dev] Re: Python-Dev Digest, Vol 13, Issue 77

[Peter Harris]

Andrew Durdin wrote:

    Message: 6
    Date: Sat, 7 Aug 2004 22:36:59 +1000
    From: Andrew Durdin <adurdin at gmail.com>
    Subject: [Python-Dev] Decorators with arguments are curries!
    To: python-dev at python.org
    Message-ID: <59e9fd3a04080705361b6314be at mail.gmail.com>
    Content-Type: text/plain; charset=US-ASCII

    Having waded through all the decorator syntax discussions recently,
    and some of the historical ones, I haven't found this point mentioned
    before, so I'll bring it up now:

    Consider the following code:

    def foo(bar):
    return 1

    a = foo
    a = foo(bar)

    The first assignment to a is binding a reference to a function; the
    second is calling the function. This is a very significant difference
    in python, and I'm concerned that all the current proposed decorator
    syntaxes[*] are liable to cause confusion on this point. For example:

    def foo_decorator(func):
    print "no params to this"
    return func

    def bar_decorator(func, param):
    print param
    return func

    @foo_decorator
    @bar_decorator("one param here")
    def decorated_func():
    pass

    Here the first decorator statement is bare, while the second one
    includes parentheses and an argument; the first one looks like a
    function reference, while the second looks like a function call.
    I find this confusing; semantically, this appears to equivalent to
    (assuming expressions are allowed in decorator statements):

    # using curry as proposed in PEP 309 [**]
    @foo_decorator
    @curry(bar_decorator, "one param here")
    def decorated_func():
    pass

    Most of my concern here is that this aspect of decorator syntax
    appears to be implicitly introducing a currying syntax in one special
    circumstance, which is then *not* transferable to currying functions
    in normal situations, as it would conflict with function calling. And
    if a currying syntax (or built-in) was introduced down the track, then
    these decorators would be inconsistent with them.

    Has anyone else noticed this issue?

    Andrew Durdin

    [*] Except those which don't allow for arguments
    [**] For a nice coincidence, PEP 309 suggested using '@' to mark curries

Hmm.  I sort of see what you're on about, but please note:

PEP309 no longer proposes (and didn't for long) using '@'.

The callable class in PEP309 is called partial() not curry() because
it's not technically a curried function in the narrow computer-science
sense, and if we mis-named it the Haskell folks would point and laugh.

You could use partial() on decorators as well as functions and classes,
and though it would melt my brain, I'm sure someone out there would see
a beautifully elegant use for it.

PEP309 is accepted but not checked in;  @ decorators are checked in but
tentative.

On topic:   @ is OK but I prefer the recently suggested |.
  pie, pipe = (+0.5, +1)

Peter Harris