| msg243166 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2015-05-14 09:51 |
| A signature Parameter object only exposes its name, not its index in the signature. I think that would be a useful information to have. |
|
|
| msg243195 - (view) |
Author: Yury Selivanov (yselivanov) * |
Date: 2015-05-14 15:40 |
| Do you have any good use case for this? In one of the first iterations of PEP 362 we had Parameter.index. However, we later redesigned the object to work as a building block -- immutable, and explicitly detached from its parent Signature. This way there is nothing wrong in taking a parameters from one signature, and using them to build a new one. And since (I think) I'm doing this kind of things in my own code, adding this attribute (or even reference to the parent Signature) to Parameter might break things, or even introduce strange side effects. Another reason is that we don't preserve the order of keyword arguments. And having things like '*args' further disconnects parameters indexes from arguments indexes. We can add an 'index(name)' or 'index(param)' method to the Signature class, but I don't know any good use case why would we need that. |
|
|
| msg243199 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2015-05-14 15:44 |
| Le 14/05/2015 17:40, Yury Selivanov a écrit : > > Do you have any good use case for this? Passing a parameter around without having to pass the index separately :-) > In one of the first iterations of PEP 362 we had Parameter.index. However, we later redesigned the object to work as a building block -- immutable, and explicitly detached from its parent Signature. This way there is nothing wrong in taking a parameters from one signature, and using them to build a new one. I see. That might be annoying in that case, indeed. > Another reason is that we don't preserve the order of keyword arguments. What do you mean? In Signature or in BoundArguments? I would hope that Signature keeps it. > And having things like '*args' further disconnects parameters > indexes from arguments indexes. Not necessarily. In my case, I treat a stararg parameter as a single parameter. |
|
|
| msg243201 - (view) |
Author: Yury Selivanov (yselivanov) * |
Date: 2015-05-14 15:49 |
| > What do you mean? In Signature or in BoundArguments? I would hope that Signature keeps it. I mean during the actual call, as **kwargs aren't ordered. I think having indexes for parameters would make sense for a language like JS or C, where there are no keyword arguments, and indexes of parameters match indexes of arguments. |
|
|
| msg243203 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2015-05-14 15:58 |
| Le 14/05/2015 17:49, Yury Selivanov a écrit : > >> What do you mean? In Signature or in BoundArguments? I would hope >> that > Signature keeps it. > > I mean during the actual call, as **kwargs aren't ordered. > > I think having indexes for parameters would make sense for a language > like JS or C, where there are no keyword arguments, and indexes of > parameters match indexes of arguments. As mentioned in the issue, when re-implementing function calls, you have to flatten the arguments into a simple argument list (because the function parameters are actually a sequence (*), despite Python's rich function call possibilities). (*) at least for pure Python functions, where the arguments are simply pushed sequentially on the ceval stack |
|
|
| msg243206 - (view) |
Author: Yury Selivanov (yselivanov) * |
Date: 2015-05-14 16:02 |
| > As mentioned in the issue, when re-implementing function calls, you have to flatten the arguments into a simple argument list [..] Then you probably need indexes for BoundArguments, not Parameters. > (*) at least for pure Python functions, where the arguments are simply pushed sequentially on the ceval stack TBH I think this is a very special use case. I'm -0.5 on including this to the stdlib. |
|
|
| msg243209 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2015-05-14 16:29 |
| Given the drawback you mentioned above, I agree that this may be a hard sell :) |
|
|
| msg243213 - (view) |
Author: Yury Selivanov (yselivanov) * |
Date: 2015-05-14 18:16 |
| OK, I'm closing this one. |
|
|