. Python 2.1 function attributes

[Tim Peters]

[Roy Katz]
> I find this explanation in need of more clarification:
>
>
> You did not address the issue of multiplying entities.  I personally
> see nothing wrong with function objects; they are light, and we can deal
> with them.  Why add yet *another* way of doing things?
> ...

Because the technique you suggest has been available for a decade, yet in
practice people refused to use it, preferring instead to abuse docstrings.
Have you read the PEP?  "Practicality beats purity" in Python:  an elegant
solution that masses of experienced Pythoneers refuse to use is an excellent
predictor of future language change.  And, for example, metaclasses are in
that boat too.

> # note: compared with f(), this implementation is an extra line
>
> class G:
>     attr = 0
>     def __call__(self): pass
>
> g = G() long
>
> ---VERSUS---
>
> def f():
>   { 'attr':0 }
>   pass

Note that the latter example is a fantasy:  it has not been implemented, and
I strongly doubt it ever will be.  What *is* in the 2.1 codebase (read the
PEP) is

def f():
    pass
f.attr = 0

I expect that this way of spelling it is instantly understandable to every
Python programmer.  The intent is obvious.  The point to the convolution in
your first way of writing it is well hidden.  You've also made life
supernaturally easy for yourself by not trying to add an attr to a *method*;
in 2.1 it works the same clean way as for a top-level function:

>>> class C:
...     def meth(self):
...         print 42
...     meth.attr = "hi!"
...
>>> c = C()
>>> c.meth.attr
'hi!'
>>>

> So the claim here is that saving a line of code justifies carving Python
> with Occam's Razor? Say it ain't so!

Best I can tell, that one line of code costs about a million brain cells to
reverse-engineer every time it appears.  Since people have historically
refused to do it that way, it's not an idiom, so it's not easy to recognize
for anyone save (possibly) its author.  Rewrite class C above and see
whether even you understand it anymore <wink>.

> I find the argument for function attributes weak.

Guido did too, but strong enough to approve.

> Hell, I wish to abolish .__doc__ for functions as well.

Fine, don't write docstrings, and run Python with -OO to remove other
peoples' documentation too.

> It just doesn't seem consistent.

Which was an argument in *favor* of adding general function attributes.
There's nothing special about func.__doc__ anymore, except the magical way
it gets set.

> Functions are functions, classes are classes.

That's still true.  Even better, you'll no longer be tempted to disguise
your functions *as* classes just to attach some data to them, and everyone
will find your code easier to read as a result.

> It seems to me even kludgier than print>>.

Barry also added code to Python 2.1 to let you write, e.g.,

    def f() >> x:
        x = 1
        y = 2

as a short way to spell "whatever the value of x is at the end of the
function, return that".  I'm sure you'll agree that's much cleaner than the
clumsy

    def f():
        x = 1
        y = 2
        return x

people suffer with today.

hoping-a-truly-bad-idea-adds-some-perspective<wink>-ly y'rs  - tim