A signature Parameter object only exposes its name, not its index in the signature. I think that would be a useful information to have.

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.

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.

> 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.

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

> 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.

Given the drawback you mentioned above, I agree that this may be a hard sell :)

OK, I'm closing this one.