Update based on questions made by Jim Jewett.

pep-0362.txt

@@ -25,9 +25,8 @@ function's signature.
 
 This PEP proposes an object representation for function signatures.
 This should help facilitate introspection on functions for various
-uses (e.g., decorators).  The introspection information contains all
-possible information about the parameters in a signature (including
-Python 3.0 features).
+uses.  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
@@ -36,6 +35,23 @@ proposed object representation is only meant to help make application
 code have an easier time to query a function on its signature.
 
 
+Purpose
+=======
+
+An object representation of a function's call signature should provide
+an easy way to introspect what a function expects as arguments.  It
+does not need to be a "live" representation, though; the signature can
+be inferred once and stored without changes to the signature object
+representation affecting the function it represents (but this is an
+`Open Issue`_).
+
+Indirecation of signature introspection can also occur.  If a
+decorator took a decorated function's signature object and set it on
+the decorating function then introspection could be redirected to what
+is actually expected instead of the typical ``*args, **kwargs``
+signature of decorating functions.
+
+
 Signature Object
 ================
 
@@ -63,6 +79,12 @@ A Signature object has the following structure attributes:
     The keys are of the variable parameter with values of the
     annotation.  If an annotation does not exist for a variable
     parameter then the key does not exist in the dict.
+* has_annotation : bool
+    Signifies whether the function has an annotation for the return
+    type.
+* annotation : object
+    If present, the attribute is set to the annotation for the return
+    type of the function.
 * parameters : list(Parameter)
     List of the parameters of the function as represented by
     Parameter objects in the order of its definition (keyword-only
@@ -190,6 +212,8 @@ 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.
+The answer to this question will influence what the defaults are for
+other attributes as well.
 
 
 Deprecate ``inspect.getargspec()`` and ``.formatargspec()``?
@@ -206,6 +230,16 @@ string represenation for ``int``).  The repr representation of types
 would need to change in order to make this reasonable.
 
 
+Have the objects be "live"?
+---------------------------
+
+Jim Jewett pointed out that Signature and Parameter objects could be
+"live".  That would mean requesting information would be done on the
+fly instead of caching it on the objects.  It would also allow for
+mutating the function if the Signature or Parameter objects were
+mutated.
+
+
 References
 ==========