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

brett.cannon python-checkins at python.org
Thu Aug 24 00:16:11 CEST 2006

Author: brett.cannon
Date: Thu Aug 24 00:16:10 2006
New Revision: 51529

Add __str__() and bind() to Signature and __str__() to Parameter.

Modified: peps/trunk/pep-0362.txt
--- peps/trunk/pep-0362.txt	(original)
+++ peps/trunk/pep-0362.txt	Thu Aug 24 00:16:10 2006
@@ -57,6 +57,12 @@
     List of the parameters of the function are represented by
     Parameter objects (see `Parameter Object`_ for their
+* __str__() -> str
+    Return the string representation of the signature as it might
+    appear in source code.
+* bind(\*args, \*\*kwargs) -> dict
+    Create a mapping from argument to parameter for the signature (see
+    `Open Issues`_ for question of how to handle tuples).
 The Signature object is stored in the ``__signature__`` attribute of
 the function.  When it is to be created is an `Open Issues`_.
@@ -95,6 +101,9 @@
     attribute does not exist.  This is done so that the attribute is
     not accidentally used if no default value is set as any default
     value could be a legitimate default value itself.
+* __str__() -> str
+    Return the string representation of the parameter as it might
+    appear in source code in a function signature.
@@ -107,6 +116,11 @@
 methods this is stored directly on the im_func function object since
 that is what decorators will work with).
+For the `Open Issues`_ question of how to handle tuples, the current
+implementation does the best it can to determine if the argument will
+unpack properly, raising TypeError if it cannot reliably prove either
+way if the argument can be unpacked.
 Relation With Other PEPs
@@ -142,6 +156,27 @@
 needed, and then return the value of ``__signature__``.
+How to handle tuples for ``Signature.bind()``?
+Tuples pose an interesting problem for generating the mapping from
+arguments to parameters.  If one wants ``Signature.bind()`` to do the
+full mapping, then the unpacking of an argument tuple's values must be
+done and then have those values bound to the proper parameter.  This
+could be a problem since this would require using the iterator to
+verify the binding and thus could possibly make the iterator worthless
+for actual use in a function call later.
+But if one wants parameters to be based on what is a single positional
+argument, then the tuple should not be unpacked.  This means that for
+tuples one can do the best they can to verify that the argument will
+unpack properly without running an iterator.  But if an object is
+passed in that does not define ``__len__()`` and ``__getitem__()`` for
+verifying unpacking, then one can either just assume that if it
+defines ``__iter__()`` it might be okay, or raise an exception stating
+that the binding could not be calculated with full confidence.

More information about the Python-checkins mailing list