Update PEP 362.
This commit is contained in:
parent
2d37f3b888
commit
e0b47c7f77
47
pep-0362.txt
47
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
|
||||
==========
|
||||
|
||||
|
|
Loading…
Reference in New Issue