python-checkins at python
Jun 7, 2012, 7:18 AM
Post #1 of 1
(30 views)
Permalink
|
|
peps: Update from Yury for PEP 362.
|
|
http://hg.python.org/peps/rev/f723e9fb778b
changeset: 4457:f723e9fb778b
user: Brett Cannon <brett [at] python>
date: Thu Jun 07 10:18:08 2012 -0400
summary:
Update from Yury for PEP 362.
files:
pep-0362.txt | 97 ++++++++++++++++++++++++---------------
1 files changed, 60 insertions(+), 37 deletions(-)
diff --git a/pep-0362.txt b/pep-0362.txt
--- a/pep-0362.txt
+++ b/pep-0362.txt
@@ -55,10 +55,8 @@
as listed in ``code.co_varnames``).
* bind(\*args, \*\*kwargs) -> BoundArguments
Creates a mapping from positional and keyword arguments to
- parameters.
-
-Once a Signature object is created for a particular function,
-it's cached in the ``__signature__`` attribute of that function.
+ parameters. Raises a ``BindError`` if the passed arguments
+ do not match the signature.
Changes to the Signature object, or to any of its data members,
do not affect the function itself.
@@ -86,19 +84,25 @@
True if the parameter is keyword-only, else False.
* is_args : bool
True if the parameter accepts variable number of arguments
- (``\*args``-like), else False.
+ (``*args``-like), else False.
* is_kwargs : bool
True if the parameter accepts variable number of keyword
- arguments (``\*\*kwargs``-like), else False.
+ arguments (``**kwargs``-like), else False.
* is_implemented : bool
True if the parameter is implemented for use. Some platforms
implement functions but can't support specific parameters
- (e.g. "mode" for os.mkdir). Passing in an unimplemented
+ (e.g. "mode" for ``os.mkdir``). Passing in an unimplemented
parameter may result in the parameter being ignored,
or in NotImplementedError being raised. It is intended that
all conditions where ``is_implemented`` may be False be
thoroughly documented.
+Parameter objects support testing for equality. Two Parameter
+objects are equal, when all their properties are equal. Those
+who need to test if one signature has the same parameters as
+another, can do a direct comparison of ``Signature.parameters``
+collections: ``signature(foo).parameters == signature(bar).parameters``.
+
BoundArguments Object
=====================
@@ -135,16 +139,58 @@
Implementation
==============
+The implementation adds a new function ``signature()`` to the ``inspect``
+module. The function is the preferred way of getting a ``Signature`` for
+a callable object.
+
+The function implements the following algorithm:
+
+ - If the object is not callable - raise a TypeError
+
+ - If the object has a ``__signature__`` attribute and if it
+ is not ``None`` - return it
+
+ - If it is ``None`` and the object is an instance of
+ ``BuiltinFunction``, raise a ``ValueError``
+
+ - If the object is a an instance of ``FunctionType``:
+
+ - If it has a ``__wrapped__`` attribute, return
+ ``signature(object.__wrapped__)``
+
+ - Or else construct a new ``Signature`` object and return it
+
+ - if the object is a method, construct and return a new ``Signature``
+ object, with its first parameter (usually ``self``) removed
+
+ - If the object is a class return ``signature(object.__init__)``
+
+ - Return ``signature(object.__call__)``
+
+Note, that the ``Signature`` object is created in a lazy manner, and
+is not automatically cached.
+
An implementation for Python 3.3 can be found here: [#impl]_.
A python issue was also created: [#issue]_.
-The implementation adds a new function ``signature()`` to the
-``inspect`` module. ``signature()`` returns the value stored
-on the ``__signature__`` attribute if it exists, otherwise it
-creates the Signature object for the function and caches it in
-the function's ``__signature__``. (For methods this is stored
-directly in the ``__func__`` function object, since that is what
-decorators work with.)
+
+Design Considerations
+=====================
+
+No Implicit Caching of Signature Objects
+----------------------------------------
+
+The first PEP design had a provision for implicit caching of ``Signature``
+objects in the ``inspect.signature()`` function. However, this has the
+following downsides:
+
+ * If the ``Signature`` object is cached then any changes to the function
+ it describes will not be reflected in it. However, If the caching is
+ needed, it can be always done manually and explicitly
+
+ * It is better to reserve the ``__signature__`` attribute for the cases
+ when there is a need to explicitly set to a ``Signature`` object that
+ is different from the actual one
Examples
@@ -311,31 +357,6 @@
return wrapper
-Open Issues
-===========
-
-When to construct the Signature object?
----------------------------------------
-
-The Signature object can either be created in an eager or lazy
-fashion. In the eager situation, the object can be created during
-creation of the function object. In the lazy situation, one would
-pass a function object to a function and that would generate the
-Signature object and store it to ``__signature__`` if
-needed, and then return the value of ``__signature__``.
-
-In the current implementation, signatures are created only on demand
-("lazy").
-
-
-Deprecate ``inspect.getfullargspec()`` and ``inspect.getcallargs()``?
----------------------------------------------------------------------
-
-Since the Signature object replicates the use of ``getfullargspec()``
-and ``getcallargs()`` from the ``inspect`` module it might make sense
-to begin deprecating them in 3.3.
-
-
References
==========
--
Repository URL: http://hg.python.org/peps
|
