[Python-Dev] PEP 362: 4th edition

Yury Selivanov yselivanov.ml at gmail.com
Sun Jun 17 00:30:29 CEST 2012


Jim,

On 2012-06-15, at 11:56 PM, Jim J. Jewett wrote:
> because:
>    def f(*, a=4, b=5): pass
> 
> and:
>    def f(*, b=5, a=4): pass
> 
> should probably have equal signatures.

That's a very good catch -- I'll fix the implementation.

>> * bind(\*args, \*\*kwargs) -> BoundArguments
>>    Creates a mapping from positional and keyword arguments to
>>    parameters.  Raises a ``BindError`` (subclass of ``TypeError``)
>>    if the passed arguments do not match the signature.
>> * bind_partial(\*args, \*\*kwargs) -> BoundArguments
>>    Works the same way as ``bind()``, but allows the omission
>>    of some required arguments (mimics ``functools.partial``
>>    behavior.)
> 
> Are those descriptions actually correct?
> 
> I would expect the mapping to be from parameters (or parameter names)
> to values extracted from *args and **kwargs.
> 
> And I'm not sure the current patch does even that, since it seems to
> instead return a non-Mapping object (but with a mapping attribute)
> that could be used to re-create *args, **kwargs in canonical form.
> (Though that canonicalization is valuable for calls; it might even
> be worth an as_call method.)
> 
> 
> I think it should be explicit that this mapping does not include
> parameters which would be filled by default arguments.  In fact, if
> you stick with this interface, I would like a 3rd method that does
> fill out everything.

You're right, the fact that the defaults are left out should be
manifested in the PEP.

I'm not sure that we need a separate method for defaults though.
It's just a matter of 3-4 lines of code to iterate through parameters
and add defaults to 'BoundArguments.arguments'.  Let's keep the API
clear.

> But I think it would be simpler to just add an optional attribute
> to each Parameter instance, and let bind fill that in on the copies,
> so that the return value is also a Signature.  (No need for the
> BoundArguments class.)  Then the user can decide whether or not to
> plug in the defaults for missing values.

Too complicated.  And doesn't make the API easier to use.

>> It's possible to test Signatures for equality.  Two signatures
>> are equal when they have equal parameters and return annotations.
> 
> I would be more explicit about parameter order mattering.  Perhaps:
> 
>    It's possible to test Signatures for equality.  Two signatures are
>    equal when their parameters are equal, their positional parameters
>    appear in the same order, and they have equal return annotations.

OK.

Thanks,
-
Yury


More information about the Python-Dev mailing list