Strategy “Strict dictionary”

This strategy acknowledges that__getitem__ is special in accepting onlyone object, and the nature of that object must be non-ambiguous in itsspecification of the axes: it can be either by order, or by name. As a resultof this assumption, in presence of keyword arguments, the passed entity is adictionary and all labels must be specified.

C0.a[1];a[1,2]->idx=1;idx=(1,2)C1.a[Z=3]->idx={"Z":3}C2.a[Z=3,R=4]->idx={"Z":3,"R":4}C3.a[1,Z=3]->raiseSyntaxErrorC4.a[1,Z=3,R=4]->raiseSyntaxErrorC5.a[1,2,Z=3]->raiseSyntaxErrorC6.a[1,2,Z=3,R=4]->raiseSyntaxErrorC7.a[1,Z=3,2,R=4]->raiseSyntaxError

Strategy “mixed dictionary”

This strategy relaxes the above constraint to return a dictionary containingboth numbers and strings as keys.

C0.a[1];a[1,2]->idx=1;idx=(1,2)C1.a[Z=3]->idx={"Z":3}C2.a[Z=3,R=4]->idx={"Z":3,"R":4}C3.a[1,Z=3]->idx={0:1,"Z":3}C4.a[1,Z=3,R=4]->idx={0:1,"Z":3,"R":4}C5.a[1,2,Z=3]->idx={0:1,1:2,"Z":3}C6.a[1,2,Z=3,R=4]->idx={0:1,1:2,"Z":3,"R":4}C7.a[1,Z=3,2,R=4]->idx={0:1,"Z":3,2:2,"R":4}

Strategy “named tuple”

Return a named tuple foridx instead of a tuple. Keyword arguments wouldobviously have their stated name as key, and positional argument would have anunderscore followed by their order:

C0.a[1];a[1,2]->idx=1;idx=(_0=1,_1=2)C1.a[Z=3]->idx=(Z=3)C2.a[Z=3,R=2]->idx=(Z=3,R=2)C3.a[1,Z=3]->idx=(_0=1,Z=3)C4.a[1,Z=3,R=2]->idx=(_0=1,Z=3,R=2)C5.a[1,2,Z=3]->idx=(_0=1,_2=2,Z=3)C6.a[1,2,Z=3,R=4]->(_0=1,_1=2,Z=3,R=4)C7.a[1,Z=3,2,R=4]->(_0=1,Z=3,_1=2,R=4)or(_0=1,Z=3,_2=2,R=4)orraiseSyntaxError

The required typename of the namedtuple could beIndex or the name of theargument in the function definition, it keeps the ordering and is easy toanalyse by using the_fields attribute. It is backward compatible, providedthat C0 with more than one entry now passes a namedtuple instead of a plaintuple.

Strategy “New argument contents”

In the current implementation, when many arguments are passed to__getitem__,they are grouped in a tuple and this tuple is passed to__getitem__ as thesingle argumentidx. This strategy keeps the current signature, but expands therange of variability in type and contents ofidx to more complex representations.

We identify four possible ways to implement this strategy:

• P1: uses a single dictionary for the keyword arguments.
• P2: uses individual single-item dictionaries.
• P3: similar toP2, but replaces single-item dictionaries with a(key,value) tuple.
• P4: similar toP2, but uses a special and additional new object:keyword()

Some of these possibilities lead to degenerate notations, i.e. indistinguishablefrom an already possible representation. Once again, the proposed notationbecomes syntactic sugar for these representations.

Under this strategy, the old behavior for C0 is unchanged.

C0:a[1]->idx=1# integera[1,2]->idx=(1,2)# tuple

In C1, we can use either a dictionary or a tuple to represent key and value pairfor the specific indexing entry. We need to have a tuple with a tuple in C1because otherwise we cannot differentiatea["Z",3] froma[Z=3].

C1:a[Z=3]->idx={"Z":3}# P1/P2 dictionary with single keyoridx=(("Z",3),)# P3 tuple of tuplesoridx=keyword("Z",3)# P4 keyword object

As you can see, notation P1/P2 implies thata[Z=3] anda[{"Z":3}] willcall__getitem__ passing the exact same value, and is therefore syntacticsugar for the latter. Same situation occurs, although with different index, forP3. Using a keyword object as in P4 would remove this degeneracy.

For the C2 case:

C2.a[Z=3,R=4]->idx={"Z":3,"R":4}# P1 dictionary/ordereddictoridx=({"Z":3},{"R":4})# P2 tuple of two single-key dictoridx=(("Z",3),("R",4))# P3 tuple of tuplesoridx=(keyword("Z",3),keyword("R",4))# P4 keyword objects

P1 naturally maps to the traditional**kwargs behavior, however it breaksthe convention that two or more entries for the index produce a tuple. P2preserves this behavior, and additionally preserves the order. Preserving theorder would also be possible with an OrderedDict as drafted byPEP 468.

The remaining cases are here shown:

C3.a[1,Z=3]->idx=(1,{"Z":3})# P1/P2oridx=(1,("Z",3))# P3oridx=(1,keyword("Z",3))# P4C4.a[1,Z=3,R=4]->idx=(1,{"Z":3,"R":4})# P1oridx=(1,{"Z":3},{"R":4})# P2oridx=(1,("Z",3),("R",4))# P3oridx=(1,keyword("Z",3),keyword("R",4))# P4C5.a[1,2,Z=3]->idx=(1,2,{"Z":3})# P1/P2oridx=(1,2,("Z",3))# P3oridx=(1,2,keyword("Z",3))# P4C6.a[1,2,Z=3,R=4]->idx=(1,2,{"Z":3,"R":4})# P1oridx=(1,2,{"Z":3},{"R":4})# P2oridx=(1,2,("Z",3),("R",4))# P3oridx=(1,2,keyword("Z",3),keyword("R",4))# P4C7.a[1,Z=3,2,R=4]->idx=(1,2,{"Z":3,"R":4})# P1. Pack the keyword arguments. Ugly.orraiseSyntaxError# P1. Same behavior as in function calls.oridx=(1,{"Z":3},2,{"R":4})# P2oridx=(1,("Z",3),2,("R",4))# P3oridx=(1,keyword("Z",3),2,keyword("R",4))# P4

Strategy “kwargs argument”

__getitem__ accepts an optional**kwargs argument which should be keyword only.idx also becomes optional to support a case where no non-keyword arguments are allowed.The signature would then be either

__getitem__(self,idx)__getitem__(self,idx,**kwargs)__getitem__(self,**kwargs)

Applied to our cases would produce:

C0.a[1,2]->idx=(1,2);kwargs={}C1.a[Z=3]->idx=None;kwargs={"Z":3}C2.a[Z=3,R=4]->idx=None;kwargs={"Z":3,"R":4}C3.a[1,Z=3]->idx=1;kwargs={"Z":3}C4.a[1,Z=3,R=4]->idx=1;kwargs={"Z":3,"R":4}C5.a[1,2,Z=3]->idx=(1,2);kwargs={"Z":3}C6.a[1,2,Z=3,R=4]->idx=(1,2);kwargs={"Z":3,"R":4}C7.a[1,Z=3,2,R=4]->raiseSyntaxError# in agreement to function behavior

Empty indexinga[] of course remains invalid syntax.

Use a method

One could keep the indexing as is, and use a traditionalget() method for thosecases where basic indexing is not enough. This is a good point, but as alreadyreported in the introduction, methods have a different semantic weight fromindexing, and you can’t use slices directly in methods. Compare e.g.a[1:3,Z=2] witha.get(slice(1,3),Z=2).

The authors however recognize this argument as compelling, and the advantagein semantic expressivity of a keyword-based indexing may be offset by a rarelyused feature that does not bring enough benefit and may have limited adoption.

Emulate requested behavior by abusing the slice object

This extremely creative method exploits the slice objects’ behavior, providedthat one accepts to use strings (or instantiate properly named placeholderobjects for the keys), and accept to use “:” instead of “=”.

>>>a["K":3]slice('K', 3, None)>>>a["K":3,"R":4](slice('K', 3, None), slice('R', 4, None))>>>

While clearly smart, this approach does not allow easy inquire of the key/valuepair, it’s too clever and esotheric, and does not allow to pass a slice as ina[K=1:10:2].

However, Tim Delaney comments

“I really do think thata[b=c,d=e] should just be syntax sugar fora['b':c,'d':e]. It’s simple to explain, and gives the greatest backwardscompatibility. In particular, libraries that already abused slices in thisway will just continue to work with the new syntax.”

We think this behavior would produce inconvenient results. The library Pandas usesstrings as labels, allowing notation such as

>>>a[:,"A":"F"]

to extract data from column “A” to column “F”. Under the above comment, this notationwould be equally obtained with

>>>a[:,A="F"]

which is weird and collides with the intended meaning of keyword in indexing, thatis, specifying the axis through conventional names rather than positioning.

Pass a dictionary as an additional index

>>>a[1,2,{"K":3}]

this notation, although less elegant, can already be used and achieves similarresults. It’s evident that the proposed Strategy “New argument contents” can beinterpreted as syntactic sugar for this notation.

Relevance of ordering of keyword arguments

As part of the discussion of this PEP, it’s important to decide if the orderinginformation of the keyword arguments is important, and if indexes and keys canbe ordered in an arbitrary way (e.g.a[1,Z=3,2,R=4]).PEP 468tries to address the first point by proposing the use of an ordereddict,however one would be inclined to accept that keyword arguments in indexing areequivalent to kwargs in function calls, and therefore as of today equallyunordered, and with the same restrictions.

Need for homogeneity of behavior

Relative to Strategy “New argument contents”, a comment from Ian Cordascopoints out that

“it would be unreasonable for just one method to behave totallydifferently from the standard behaviour in Python. It would be confusing foronly__getitem__ (and ostensibly,__setitem__) to take keywordarguments but instead of turning them into a dictionary, turn them intoindividual single-item dictionaries.” We agree with his point, however it mustbe pointed out that__getitem__ is already special in some regards when itcomes to passed arguments.

Chris Angelico also states:

“it seems very odd to start out by saying “here, let’s give indexing theoption to carry keyword args, just like with function calls”, and then comeback and say “oh, but unlike function calls, they’re inherently ordered andcarried very differently”.” Again, we agree on this point. The moststraightforward strategy to keep homogeneity would be Strategy “kwargsargument”, opening to a**kwargs argument on__getitem__.

One of the authors (Stefano Borini) thinks that only the “strict dictionary”strategy is worth of implementation. It is non-ambiguous, simple, does notforce complex parsing, and addresses the problem of referring to axes eitherby position or by name. The “options” use case is probably best handled witha different approach, and may be irrelevant for this PEP. The alternative“named tuple” is another valid choice.

Having .get() become obsolete for indexing with default fallback

Introducing a “default” keyword could makedict.get() obsolete, which would bereplaced byd["key",default=3]. Chris Angelico however states:

“Currently, you need to write__getitem__ (which raises an exception onfinding a problem) plus something else, e.g.get(), which returns a defaultinstead. By your proposal, both branches would go inside__getitem__, whichmeans they could share code; but there still need to be two branches.”

Additionally, Chris continues:

“There’ll be an ad-hoc and fairly arbitrary puddle of names (some will godefault=, others will say that’s way too long and godef=, except thatthat’s a keyword so they’ll usedflt= or something…), unless there’s astrong force pushing people to one consistent name.”.

This argument is valid but it’s equally valid for any function call, and isgenerally fixed by established convention and documentation.

On degeneracy of notation

User Drekin commented: “The case ofa[Z=3] anda[{"Z":3}] is similar tocurrenta[1,2] anda[(1,2)]. Even though one may argue that the parenthesesare actually not part of tuple notation but are just needed because of syntax,it may look as degeneracy of notation when compared to function call:f(1,2)is not the same thing asf((1,2)).”.