Decorators for paramters (was Re: The problem with "as")

[Joe Mason]

In article <mailman.290.1080058037.742.python-list at python.org>, Skip Montanaro wrote:
>     Joe> Not a big fan of that syntax - I have to keep the parameter names
>     Joe> and types in sync by counting.
> 
> Here's a dummy example from the in-progress version of the PEP:

<snip>

>     def func3(arg1, arg2, *rest, **kwds):
>         r = arg1 + arg2
>         print "r:", r
>         print "rest:", rest
>         print "kwds:", kwds
>         if 'result' in kwds:
>             return kwds['result']
>         return r
>     func3 = accepts(int, int)(func3)
>     func3 = returns(int)(func3)
> 
>     print func3(3,5,'a','b','c',other="47")
>     print func3(3,5,'a','b','c',result=47)
> 
> Note that check_accepts() does the counting for you.  If you wanted type
> declarations in the language I agree it would be more natural for the
> arguments and their types to be side-by-side, but then it wouldn't be
> Python. ;-)

No, you still have to count when you're actually writing the accepts()
call.  It's the same as the complaints against the print "%s%s" % (this,
that) syntax.

Type declarations isn't a great example, because nobody really wants
them in Python, but I'm sure we can come up with decorators that would
be worthwhile for parameters.  Markers for IDL or SWIG could be straight
passthroughs that are only there for the parser, for instance.  (Of
course, normally you'd just make them comments...)

>     Joe> For decorators in general, I like
> 
>     Joe>     def foo() as [decor1, decor2, decor3]:
>     
>     Joe> You get an explicit list syntax, but it's set off by a keyword so
>     Joe> they don't run together to the eye.  Because the keyword keeps it
>     Joe> unambiguous, you could even allow a tuple instead of a list: "def
>     Joe> foo() as (x, y, z)".
> 
> I don't understand how
> 
>     def foo() as [decor1, decor2, decor3]:
> 
> is somehow less ambiguous than
> 
>     def foo() [decor1, decor2, decor3]:

It's not any less ambiguous, it's just easier to read.

    def foo(blah, asfa, abble, gabble, spelunk)[blah, blagh, briggle]:
        pass
    def bar(blah, asfa, abble, gabble, spelunk, blah, blagh)[briggle]:
        pass
    def baz(blah, asfa, abble, gabble)[spelunk, blah, blagh, briggle]:
        pass

Can you tell how many parameters each of those has without peering
closely?

    def foo(blah, asfa, abble, gabble, spelunk) as [blah, blagh, briggle]:
        pass
    def bar(blah, asfa, abble, gabble, spelunk, blah, blagh) as [briggle]:
        pass
    def baz(blah, asfa, abble, gabble) as [spelunk, blah, blagh, briggle]:
        pass

That's still horrible, horrible style, but it's easier to take in.

> I'd prefer prepositional keywords actually be consistent with their English
> usage.  It's just line noise and is likely to provide some stumbling block
> of programmers whose command of the English language is not stellar.  What
> we really would say in English is
> 
>     Define function foo taking no arguments as modified by decor1, decor2
>     and decor3.
> 
> No single preposition is going to read correctly as a replacement for "as
> modified by", nor do we need all those other bits of English ("function",

I think "using" and "with" would both read correctly that way, if not
completely.  Also "has", but less so.  "as", not at all.

Joe