2014-12-17 23:05 GMT-08:00 Nick Coghlan <ncoghlan@gmail.com>:
On 18 December 2014 at 12:57, Guido van Rossum <guido@python.org> wrote:
> On Wed, Dec 17, 2014 at 6:15 PM, Antony Lee <antony.lee@berkeley.edu> wrote:
>>
>> The discussion has drifted towards improving OrderedDict (something I
>> certainly approve), but the semantic question is still there: why should
>> BoundArguments.arguments be ordered by the parameter order?  For example,
>> the recipe just below in the docs, for filling in the remaining default
>> arguments, breaks that ordering, without even mentioning that.
>
>
> Given that the answer hasn't been answered yet, perhaps nobody remembers the
> reason any more. But why does it bother you so much? In my experience the
> inspect module wasn't written for performance but for functionality. If it
> really hurts your ability to do something that you need to be fast, perhaps
> you can supply a patch? Make sure to run the tests and update the docs as
> needed.
Actually the second example in PEP362 uses bind as an argument type-checker, which should arguably be as fast as possible.  I'm opening an issue with a patch right now. 

As far as I'm aware, it's an ordered dictionary because that makes the
default repr() predictable when binding arguments for a given function
(in the absence of after-the-fact manipulation like the example in the
docs that injects the default values as explicitly bound arguments).
That can't really be the case as BoundArguments doesn't define a __repr__... (and OrderedDict's __repr__ is a bit too verbose IMO, but that's another issue and little can be done about it anyways).  Now that I delved into the details of BoundArgument's implementation, I'll also note that __eq__ also checks the arguments order, and again additional binding will mess that up:

s = signature(lambda x=None, y=None: None)
ba0 = s.bind()
ba1 = s.bind(x=None)
ba2 = s.bind(y=None)
<apply recipe to add default arguments to ba0, ba1 and ba2>

Should ba0, ba1 and ba2 compare now equal or not?  As it is, we'll have ba0 == ba1 != ba2, which doesn't strike me as particularly reasonable.

Antony


The inspect.signature() machinery includes quite a few things like
that where the serialisation as a human readable string is considered
as important then the programmatic representation.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia