[Python-ideas] Why does BoundArguments use an OrderedDict?

[Brett Cannon]

 On Thu, Dec 18, 2014, 04:46 Antony Lee <antony.lee at berkeley.edu> wrote:

2014-12-17 23:05 GMT-08:00 Nick Coghlan <ncoghlan at gmail.com>:

On 18 December 2014 at 12:57, Guido van Rossum <guido at python.org> wrote:
> On Wed, Dec 17, 2014 at 6:15 PM, Antony Lee <antony.lee at 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 the author of PEP 362 I can tell you that was an example and not
something to optimize for. If you want to type check your code then you
should do it offline or only during debugging in which case performance is
not an issue.

-Brett


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 at gmail.com   |   Brisbane, Australia


_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141219/1c6e6256/attachment.html>