[Python-ideas] PEP pre-draft: Support for indexing with keyword arguments

[Tim Delaney]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140705/ba09ec93/attachment.html>