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