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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
