Functions and methods are first class objects, and they already have
attributes, some of which are writable. Why should __doc__ be
special? Just because it was the first such attribute to have
syntactic support for easily defining? Think about my proposal this
way: it actual removes a restriction.
What I don't like about /F's approach is that if you were building a
framework, you'd now have two conventions you'd have to describe:
where to find the mapping, and what keys to use in that mapping. With
attributes, you've already got the former: getattr(). Plus, let's say
you're handed a method object `x', would you rather do:
if x.im_class.typemap[x.im_func] == 'int':
...
or
if x.__type__ == 'int':
...
And what about function objects (as opposed to unbound methods).
Where do you stash the typemap? In the module, I supposed. And if
you can be passed either type of object, do you now have to do this?
if hasattr(x, 'im_class'):
if hasattr(x.im_class, 'typemap'):
if x.im_class.typemap[x.im_func] == 'int':
...
elif hasattr(x, 'func_globals'):
if x.func_globals.has_key('typemap'):
if x.func_globals['typemap'][x] == 'int':
...
instead of the polymorphic elegance of
if x.__type__ == 'int':
...
Finally, think of this proposal as an evolutionary step toward
enabling all kinds of future frameworks. At some point, there may be
some kind of optional static type system. There will likely be some
syntactic support for easily specifying the contents of the __type__
attribute. With the addition of func/meth attrs now, we can start to
play with prototypes of this system, define conventions and standards,
and then later when there is compiler support, simplify the
definitions, but not have to change code that uses them.
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4