Delegating `BoundArguments.__getitem__` to `BoundArguments.arguments.__getitem__`
Hi, I suggest delegating `BoundArguments.__getitem__` to `BoundArguments.arguments.__getitem__`, so instead of doing `bound_arguments.arguments['foo']` we could do `bound_arguments['foo']`. Since there isn't that much more to a `BoundArguments` object than its arguments I think it's nice to save some typing and be able to access the arguments directly. Thanks, Ram.
Hi, On 2014-10-03, 12:51 PM, Ram Rachum wrote:
And while we're at it, if the user tries to access an argument that isn't given but has a default, let's return the default.
No. There is a note on this in python docs re BoundArguments.arguments: "Contains only explicitly bound arguments." This is an important feature, because it gives you information of what exact set of arguments was bound in the first place. Also, when you use BoundArguments for RPC, you're interested in passing the minimal set of information for each call. If you want to change this behaviour, you're free to extend Signature class and return a customized BA instance. In 3.5 there is Signature.from_callable for making this easy, and there is a 3 line example in docs on how to bind defaults.
You'll also need to delegate __setitem__, keys(), __len__ and all other Mapping methods. And to be honest, I see absolutely no point in doing this.
Since there isn't that much more to a `BoundArguments` object than its arguments
For now yes. In future we might want to extend the API. Yury
On 4 October 2014 07:34, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
You'll also need to delegate __setitem__, keys(), __len__ and all other Mapping methods. And to be honest, I see absolutely no point in doing this.
I don't see a benefit either. Ram, please try to remember that shorter isn't better if it comes at a cost in clarity, and that *every single change to Python* comes at a substantial cost in terms of the long term ripple effect it has on the ecosystem. This is at the heart of the "one - and preferably only one - obvious way to do it" philosophy - avoiding redundancy wherever possible promotes consistency, which reduces the number of things that folks need to learn how to *read*. As a result, adding a redundant spelling of an existing feature has to offer an *extraordinarily* compelling readability benefit for it to ever be worthwhile. Saving a few characters when typing is almost never going to be sufficiently compelling. In this particular case, it's also worth noting that we explicitly moved *away* from a similar "implicit subcontainer access" model for exception arguments in order to eliminate the redundancy: # Python 2
# Python 3
Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi, On 2014-10-03, 12:51 PM, Ram Rachum wrote:
And while we're at it, if the user tries to access an argument that isn't given but has a default, let's return the default.
No. There is a note on this in python docs re BoundArguments.arguments: "Contains only explicitly bound arguments." This is an important feature, because it gives you information of what exact set of arguments was bound in the first place. Also, when you use BoundArguments for RPC, you're interested in passing the minimal set of information for each call. If you want to change this behaviour, you're free to extend Signature class and return a customized BA instance. In 3.5 there is Signature.from_callable for making this easy, and there is a 3 line example in docs on how to bind defaults.
You'll also need to delegate __setitem__, keys(), __len__ and all other Mapping methods. And to be honest, I see absolutely no point in doing this.
Since there isn't that much more to a `BoundArguments` object than its arguments
For now yes. In future we might want to extend the API. Yury
On 4 October 2014 07:34, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
You'll also need to delegate __setitem__, keys(), __len__ and all other Mapping methods. And to be honest, I see absolutely no point in doing this.
I don't see a benefit either. Ram, please try to remember that shorter isn't better if it comes at a cost in clarity, and that *every single change to Python* comes at a substantial cost in terms of the long term ripple effect it has on the ecosystem. This is at the heart of the "one - and preferably only one - obvious way to do it" philosophy - avoiding redundancy wherever possible promotes consistency, which reduces the number of things that folks need to learn how to *read*. As a result, adding a redundant spelling of an existing feature has to offer an *extraordinarily* compelling readability benefit for it to ever be worthwhile. Saving a few characters when typing is almost never going to be sufficiently compelling. In this particular case, it's also worth noting that we explicitly moved *away* from a similar "implicit subcontainer access" model for exception arguments in order to eliminate the redundancy: # Python 2
# Python 3
Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Nick Coghlan -
Ram Rachum -
Yury Selivanov