[Python-checkins] r58027 - peps/trunk/pep-0362.txt

[brett.cannon]

Author: brett.cannon
Date: Fri Sep  7 04:19:39 2007
New Revision: 58027

Modified:
   peps/trunk/pep-0362.txt
Log:
Update PEP 362.


Modified: peps/trunk/pep-0362.txt
==============================================================================
--- peps/trunk/pep-0362.txt	(original)
+++ peps/trunk/pep-0362.txt	Fri Sep  7 04:19:39 2007
@@ -25,10 +25,16 @@
 
 This PEP proposes an object representation for function signatures.
 This should help facilitate introspection on functions for various
-usese (e.g., decorators).  The introspection information contains all
+uses (e.g., decorators).  The introspection information contains all
 possible information about the parameters in a signature (including
 Python 3.0 features).
 
+This object, though, is not meant to replace existing ways of
+introspection on a function's signature.  The current solutions are
+there to make Python's execution work in an efficient manner.  The
+proposed object representation is only meant to help make application
+code have an easier time to query a function on its signature.
+
 
 Signature Object
 ================
@@ -68,7 +74,7 @@
     called with the given arguments.
 
 The Signature object is stored in the ``__signature__`` attribute of
-the function.  When it is to be created is discussed in
+a function.  When it is to be created is discussed in
 `Open Issues`_.
 
 
@@ -123,9 +129,10 @@
 An implementation can be found in Python's sandbox [#impl]_.
 There is a function named ``signature()`` which
 returns the value stored on the ``__signature__`` attribute if it
-exists, else it creates it bound to the Signature object for the
-function.  For methods this is stored directly on the im_func function
-object since that is what decorators will work with.
+exists, else it creates the Signature object for the
+function and sets ``__signature__``.  For methods this is stored
+directly on the im_func function object since that is what decorators
+work with.
 
 
 Open Issues
@@ -169,6 +176,36 @@
 ``tuple``).
 
 
+Remove ``has_*`` attributes?
+----------------------------
+
+If an EAFP approach to the API is taken, both ``has_annotation`` and
+``has_default`` are unneeded as the respective ``annotation`` and
+``default_value`` attributes are simply not set.  It's simply a
+question of whether to have a EAFP or LBYL interface.
+
+
+Have ``var_args`` and ``_var_kw_args`` default to ``None``?
+------------------------------------------------------------
+
+It has been suggested by Fred Drake that these two attributes have a
+value of ``None`` instead of empty strings when they do not exist.
+
+
+Deprecate ``inspect.getargspec()`` and ``.formatargspec()``?
+-------------------------------------------------------------
+
+Since the Signature object replicates the use of ``getargspec()``
+from the ``inspect`` module it might make sense to deprecate it in
+2.6.  ``formatargspec()`` could also go if Signature objects gained a
+__str__ representation.
+
+Issue with that is types such as ``int``, when used as annotations,
+do not lend themselves for output (e.g., ``"type 'int'>"`` is the
+string represenation for ``int``).  The repr representation of types
+would need to change in order to make this reasonable.
+
+
 References
 ==========