Rewritten a bit for clarity, add a note about what you can set
func.__dict__ to, added a note in the open issues about support for built-in function attributes, and included a link to the SF patch #103123.
This commit is contained in:
parent
1a99d9c3ac
commit
2e3839e1ed
54
pep-0232.txt
54
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
|
||||
|
|
Loading…
Reference in New Issue