diff --git a/pep-0232.txt b/pep-0232.txt index 848f3df58..8f85bb066 100644 --- a/pep-0232.txt +++ b/pep-0232.txt @@ -30,12 +30,11 @@ Background attribute. This convenience has been exploited over and over again, overloading docstrings with additional semantics. - For example, John Aycock[1] has written a system where docstrings - are used to define parsing rules. Zope's ZPublisher ORB[2] uses + For example, John Aycock has written a system where docstrings are + used to define parsing rules[1]. Zope's ZPublisher ORB[2] uses docstrings to signal "publishable" methods, i.e. methods that can - be called through the web. And Tim Peters[3] has developed a - system called doctest, where docstrings actually contain unit - tests. + be called through the web. And Tim Peters has developed a system + called doctest[3], where docstrings actually contain unit tests. The problem with this approach is that the overloaded semantics may conflict with each other. For example, if we wanted to add a @@ -45,9 +44,9 @@ Background Proposal - This proposal simply adds a new dictionary to function objects, - called func_dict (a.k.a. __dict__). This dictionary can be set - and get using ordinary attribute set and get syntax. + This proposal adds a new dictionary to function objects, called + func_dict (a.k.a. __dict__). This dictionary can be set and get + using ordinary attribute set and get syntax. Unbound methods also gain set and get attribute syntax, but they modify the dictionary of the underlying function object. When @@ -57,6 +56,10 @@ Proposal the bound method, they are really shared by all bound methods, via the underlying function object. + A function object's __dict__ can also be set, but only to a + dictionary object (i.e. setting __dict__ to UserDict raises a + TypeError). + Examples @@ -77,8 +80,8 @@ Examples class C: def a(self): 'just a docstring' + a.publish = 1 - C.a.publish = 1 c = C() if c.a.publish: publish(c.a()) @@ -86,7 +89,7 @@ Examples Other Uses - Paul Prescod enumerated a bunch of uses + Paul Prescod enumerated a bunch of other uses: http://mail.python.org/pipermail/python-dev/2000-April/003364.html @@ -96,10 +99,19 @@ Open Issues 1) Should function attributes be settable or gettable when in restricted execution mode? What about __dict__/func_dict? - 2) __doc__ is the only function attribute that currently has + 2) Should built-in functions have writable attributes? The + current patch only supports attributes on user defined + (i.e. Python) functions and methods. Adding support to + built-in functions isn't difficult -- it would essentially + mirror the implementation for user defined functions (i.e. we + add a PyObject* to the PyCFunctionObject struct and write + getattro and setattro functions to read and write them). + + 3) __doc__ is the only function attribute that currently has syntactic support for conveniently setting. It may be - worthwhile to enhance the language for supporting easy function - attribute setting. Here are some suggested syntaxes: + worthwhile to eventually enhance the language for supporting + easy function attribute setting. Here are some syntaxes + suggested by PEP reviewers: def a { 'publish' : 1, @@ -116,7 +128,8 @@ Open Issues } It isn't currently clear if special syntax is necessary or - desirable. + desirable. It would be sufficient to postpone syntactic + support for some future PEP. Dissenting Opinion @@ -134,9 +147,9 @@ Dissenting Opinion - other ways to do it (e.g. mappings as class attributes) - useless until syntactic support is included - Countering some of these arguments is the observation that, with - the current implementation, __doc__ can in fact be set to any type - of object, so some semblance of writable function attributes are + Countering some of these arguments is the observation that with + vanilla Python 2.0, __doc__ can in fact be set to any type of + object, so some semblance of writable function attributes are already feasible. But that approach is yet another corruption of __doc__. @@ -153,7 +166,12 @@ Dissenting Opinion Reference Implementation - A reference implementation will be uploaded to SourceForge soon. + The reference implementation is available on SourceForge as a + patch against the Python CVS tree (patch #103123). This patch + doesn't include the regrtest module and output file. Those are + available upon request. + + http://sourceforge.net/patch/?func=detailpatch&patch_id=103123&group_id=5470 References