function attributes are like function objects

[Tim Peters]

[/F]
> well, if people are too lazy to write
>
>     def f(...):
>        ...
>     a[f] = "something"
>
> do you really think they'll find it much easier to write:
>
>     def f(...):
>         ...
>     f.a = "something"

[Tim]
> Believe it or not, I do.  Bets?  Don't forget methods when
> deciding how easy the first alternative is, and that decorating
> methods (not top-level functions) is the primary cause of
> docstring abuse.

[/F]
> Works for methods too:
>
>     class Spam:
>         a = {}
>         def f(...):
>             ...
>         a[f] = "something"

Now, now, let's be serious:

> You can dig it out with a one-liner

Yes, and if you *showed* that one-liner, the "easier" would be shot all to
pieces.  These aren't meant to be write-only attributes <wink>.

> (or 2-3 lines, if you want a more general version

Or, under Barry's patch, simply

    C.f.a

> -- put it in the "code" module, where it belongs...)

Na, C.f.a is too simple to hide in "code" <wink>.

> ...
> Sure looks like "because we can" to me...

Well, my employer is famous for using the presence or absence of a docstring
to determine whether a method "is publishable".  It's handier and cleaner to
have an attribute for that instead.  You want to use a dict, and then there
are multiple dicts, and then multiple "conceptual" attributes get
distributed in an unhelpful way.  Like the trick of hiding a function in a
class, it's an alternative that's been available for years, and people
simply won't do it.

Heading on 50 years ago, early LISP systems had the radical idea that you
could "attach" any number of key+value pairs to any symbol, via setprop,
getprop, remprop functions.  Python has objects instead of symbols, and
dicts instead of association lists, and attr notation instead of functional,
but other than those it's the same ancient idea (except still less general
in Python!).  Nothing bad happened to LISP as a result, and it was handy for
all sorts of things.

> Or maybe "because it's more fun to hack the core than to hack
> the library".  (For some reason, the python-devers seem to prefer
> writing C/Java over Python...)

And writing code rather than docs; and anything rather than volunteer to
investigate a bug report.  They're developers <0.6 wink>.

> On the other hand, this isn't such a big deal, especially not com-
> pared to some of the stuff I've seen on python-dev lately.  I'm
> pretty sure a third-party python implementer can ignore function
> attributes, and nobody will ever notice...

We would certainly notice the absence of function.__doc__, and any 3rd-party
implementer realizing that first would likely take a much more uniform
approach to implementing object attributes than did Guido at the start.
Remember that func.__doc__ didn't exist at the start, so got backstitched in
as an afterthought.  One hopes that later implementers might even learn from
that <wink>.

hope-springs-eternal-ly y'rs  - tim