From e0b47c7f77009c5a76aef13e7abc24d5a5a55f2f Mon Sep 17 00:00:00 2001
From: Brett Cannon <bcannon@gmail.com>
Date: Fri, 7 Sep 2007 02:19:39 +0000
Subject: [PATCH] Update PEP 362.

---
 pep-0362.txt | 47 ++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/pep-0362.txt b/pep-0362.txt
index 27c41ab08..4b578e5bf 100644
--- a/pep-0362.txt
+++ b/pep-0362.txt
@@ -25,10 +25,16 @@ function's signature.
 
 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 @@ A Signature object has the following structure attributes:
     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 @@ Implementation
 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 @@ object along with the sequence constructor (e.g., ``list`` or
 ``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
 ==========