The problem with "as" [was "Re: PEP 318"]

[David MacQuigg]

On Tue, 23 Mar 2004 08:39:19 GMT, Joe Mason <joe at notcharles.ca> wrote:

>In article <slrnc5vrl2.vi6.joe at gate.notcharles.ca>, Joe Mason wrote:
>> Not a big fan of that syntax - I have to keep the parameter names and
>> types in sync by counting.
>> 
>>     def foo(x [accepts(int)], y [accepts(float)]) [returns(int)]:
>> 
>> is a little better, except now we're getting very verbose.
>> 
>> For decorators in general, I like
>> 
>>     def foo() as [decor1, decor2, decor3]:
>>     
>> You get an explicit list syntax, but it's set off by a keyword so they don't
>> run together to the eye.  Because the keyword keeps it unambiguous, you
>> could even allow a tuple instead of a list: "def foo() as (x, y, z)".
>> 
>> So I definitely favour a keyword, but perhaps "as" is to generic.  What
>> about "has" or "with"?

A less generic keyword will lead to odd phrases like "has int" or
"with staticmethod", or different keywords for each phrase.

The problem with using different keywords for each phrase is - after
we get a collection of them, it becomes a problem for beginners to
remember which one to use in each situation.  Even if you try to chose
a keyword which is self-explanatory, a lot of people don't get the
meaning you intended (e.g. 'yield' as in 'produce' rather than 'give
way', 'lambda' as in 'lambda calculus').  What we need is something
short, neutral in meaning, and usable in any situation where you need
to modify an existing syntax, i.e. a symbol.

Re-use of the same symbol to mean "modified syntax" in any context,
will avoid the Perl problem (too many symbols with idiosyncratic
meanings).  Beginners will learn very quickly that the special symbol
means "similar to the standard syntax, but RTFM if you don't yet know
this variation".  Locating the right documentation will be easy,
because it will always be at the end of the discussion on the normal
form of the statement.

I would give an example, but I worry it will degenerate this
discussion into a debate over whether it looks like something bad in
language X.  Let's see if we can discuss this on a higher level first.
Does it make sense to have a general symbol for modifications of the
simple standard syntax?

-- Dave

>Come to think of it, the verbose example with "has" becomes (assuming a
>shorter decorator name):
>
>    def foo(x has sig(int), y has sig(float)) has returns(int):
>
>Since you might not need the full list syntax for a single decorator.
>That's not too bad looking.
>
>(No, I'm not seriously proposing decorators on parameters at this point.)
>
>Joe