1. I think you absolutely *must* address the option of purely syntactic sugar in the PEP. It will come up on python-dev, so address it now. a[b, c=f, e=f:g:h] -> a[b, 'c':d, 'e':slice(f, g, h)] The rationale is readability and being both backwards and forwards compatible - existing __getitem__ designed to abuse slices will continue to work, and __getitem__ designed to work with the new syntax will work by abusing slices in older versions of Python. Pandas could be cited as an example of an existing library that could potentially benefit. It would be good if there were precise examples of Pandas syntax that would benefit immediately, but I don't know it beyond a cursory glance over the docs. My gut feeling from that is that if the syntax were available Pandas might be able to use it effectively. 2. I think you're at the point that you need to pick a single option as your preferred option, and everything else needs to be in the alternatives. FWIW, I would vote: +1 for syntax-sugar only (zero backwards-compatibility concerns). If I were starting from scratch this would not be my preferred option, but I think compatibility is important. +0 for a keyword(key, value) parameter object i.e. a[b, c=d, e=f:g:h] -> a[b, keyword('c', d), keyword('e', slice(f, g, h))] My objection is that either __getitem__ will be more complicated if you want to support earlier versions of Python (abuse slices for earlier versions, use keyword object for current) or imposes an additional burden on the caller in earlier versions (need to create a keyword-equivalent object to call with). If we were starting from scratch this would be one of my preferred options. -1 to any option that loses the order of the parameters (I'm strongly in favour of bringing order to keyword arguments - let's not take a backwards step here). -0 to any option that doesn't allow arbitrary ordering of positional and keyword arguments i.e. any option where the following is not legal: a[b, c=d, e] This is something we can do now (albeit in a fairly verbose way at times) and I think restricting this is likely to remove options for DSLs, etc. -0 for namedtuple (BTW you might want to mention that collections.namedtuple() already has precedent for _X positional parameter names) My objection is that it's not possible to determine definitively in __getitem__ if the the call was: a[b, c] or a[_0=b, _1=c] which might be important in some use cases. The same objection would apply to passing an OrderedDict (but that's got additional compatibility issues). Cheers, Tim Delaney