[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