[Python-ideas] Why does BoundArguments use an OrderedDict?
antony.lee at berkeley.edu
Thu Dec 18 13:45:22 CET 2014
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>
> >> 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
> >> 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
> > 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
> > really hurts your ability to do something that you need to be fast,
> > 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.
> 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.
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas