[Python-Dev] Arbitrary attributes on funcs and methods

[Tim Peters]

Lisp systems for 40+ years traditionally supported user-muckable "property
lists" on all symbols, which were basically arbitrary dicts w/ a clumsy
syntax.  No disaster ensued; to the contrary, it was often handy.

So +0 from me on the add-attrs-to-funcs idea.  The same idea applies to all
objects, of course, but attrs-on-funcs has some bang for the buck (adding a
dict to e.g. each int object would be a real new burden with little
payback).

-1 on any notion of restricting attr values to be immutable.

[Gordon]
> Having to be explicit about the method <-> regex / rule would
> severely damage SPARK's elegance.

That's why I'm only +0 instead of +1:  SPARK won't switch to use the new
method anyway, because the beauty of abusing docstrings is that it's
syntactically *obvious*.  There already exist any number of other ways to
associate arbitrary info with arbitrary objects, and it's no mystery why
SPARK and Zope avoided all of them in favor of docstring abuse.

> It would make Tim's doctest useless.

This one not so:  doctest is *not* meant to warp docstrings toward testing
purposes; it's intended that docstrings remain wholly for human-friendly
documentation.  What doctest does is give you a way to guarantee that the
elucidating examples good docstrings *should have anyway* work exactly as
advertised (btw, doctest examples found dozens of places in my modules that
needed to be fixed to recover from 1.6 alpha no longer sticking a trailing
"L" on str(long) -- if you're not using doctest every day, you're an idiot
<wink>).

If I could add an attr to funcs, though, *then* I'd think about changing
doctest to also run examples in any e.g. func.doctest attrs it could find,
and that *new* mechanism would be warped toward testing purposes.  Indeed, I
think that would be an excellent use for the new facility.

namespaces-are-one-honking-great-etc-ly y'rs  - tim