<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-12-17 23:05 GMT-08:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 18 December 2014 at 12:57, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Wed, Dec 17, 2014 at 6:15 PM, Antony Lee <<a href="mailto:antony.lee@berkeley.edu">antony.lee@berkeley.edu</a>> wrote:<br>
>><br>
>> The discussion has drifted towards improving OrderedDict (something I<br>
>> certainly approve), but the semantic question is still there: why should<br>
>> BoundArguments.arguments be ordered by the parameter order?  For example,<br>
>> the recipe just below in the docs, for filling in the remaining default<br>
>> arguments, breaks that ordering, without even mentioning that.<br>
><br>
><br>
> Given that the answer hasn't been answered yet, perhaps nobody remembers the<br>
> reason any more. But why does it bother you so much? In my experience the<br>
> inspect module wasn't written for performance but for functionality. If it<br>
> really hurts your ability to do something that you need to be fast, perhaps<br>
> you can supply a patch? Make sure to run the tests and update the docs as<br>
> needed.<br></div></div></blockquote><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
</div></div>As far as I'm aware, it's an ordered dictionary because that makes the<br>
default repr() predictable when binding arguments for a given function<br>
(in the absence of after-the-fact manipulation like the example in the<br>
docs that injects the default values as explicitly bound arguments).<br></blockquote><div>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:</div><div><br></div><div>s = signature(lambda x=None, y=None: None)</div><div>ba0 = s.bind()</div><div>ba1 = s.bind(x=None)</div><div>ba2 = s.bind(y=None)</div><div><apply recipe to add default arguments to ba0, ba1 and ba2></div><div><br></div><div>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.</div><div><br></div><div>Antony</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The inspect.signature() machinery includes quite a few things like<br>
that where the serialisation as a human readable string is considered<br>
as important then the programmatic representation.<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</div></div></blockquote></div></div></div>