[Python-Dev] A syntax for function attributes?

[Michael Chermside]

Pat Miller writes:
> I can imagine:
> 
> def sqr [inline=true](x):
>    return x*x
      [...]
> I think it essential to use some dense syntax.  It would be messy if it
> were
> 
> def sqr(x):
>     return x*x
> sqr.inline = true

I don't object to a syntax for function attributes... in fact, I've seen no
specific proposal to object to. But I find your point above HIGHLY
unconvincing:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> version_1 = """def sqr [inline=true] (x):
...    return x*x
... """
>>> version_2 = """def sqr(x):
...     return x*x
... sqr.inline = true
... """
>>> len(version_2) - len(version_1)
4

Here's what WOULD convince me. Mark Nottingham writes:
> I would very much like to use function 
> attributes for associating metadata with functions and methods, but the 
> lack of such syntactic support precludes their use, so I end up 
> (ab)using __doc__.

Rather than introducing the syntax first, let's start by making it
POSSIBLE somehow, even if the syntax is awkward. That's already been
done -- functions can have attributes. THEN, let's write some cool
code that uses feature, and we'll learn how it works out in practice.
Only once we see how very useful this really is should we consider
introducing special syntax for it, because the less special syntax
that Python has, the better it is (if we keep functionality constant).

Notice that this is the approach that Guido used for classmethod and
its ilk, and we're still working out what the right "special syntax"
is for those, but in the meantime we're seeing that they are getting
lots of use.

I think this approach (first prove it's useful for Python, THEN add 
syntax to the language) is preferable for ALL new "special syntax"
except in three cases. One exception is features like generators,
which are instantly recognized by all as being enormously useful,
so we skipped the "whether to do it" stage and went right to the
discussion of _what_ the special syntax should be. Another exception
is features which simply CAN'T be done without introducing new
syntax... like PEP 310 where we prevent the race condition. And the
third exception is cases where the proponants claim that the syntax
change itself is what makes the difference -- for instance those
who point to ruby's blocks as very useful while Python's lambda's
have just a little bit too much typing. (Not that I agree, necessarily,
but they're entitled to make their point.)

Other than that, let's always try things out before adding special
syntax.

Now-my-fourth--no-AMONGST-my-exceptions-lly yours,

-- Michael Chermside