[Python-Dev] PEP 362: 4th edition (original) (raw)

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. * bindpartial(*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 ascall 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