[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    [Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
From:       Todd <toddrjen () gmail ! com>
Date:       2020-07-22 4:38:06
Message-ID: CAFpSVp+iKm-TLWfuM5nEnqvNL_Xqs0Yrj5MwuRZcwbXdP2Ye-w () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Tue, Jul 21, 2020 at 2:05 PM David Mertz <mertz@gnosis.cx> wrote:

> On Tue, Jul 21, 2020, 12:14 PM Sebastian Berg
>
>> First, using it for named dimensions, means you don't actually need to
>> mix it with normal tuple indexing, mixing both seems rather confusing?
>>
>>     temperature.loc(method="nearest")[longitude=longs, latitude=lats]
>>
>
> [*] In my opinion, passing the keyword argument using anything other than
> the standard **kws style sounds crazy. We have perfectly good ways to do
> that for every other function or method. Don't invent something new and
> different that only works with .__getitem__().
>

 It would also be possible to pass __getitem__ exactly one other argument,
a dict with all the named arguments.

So instead of __getitem__(inds, **kwargs) simply __getitem__(inds, kwargs)

"kwargs" would be the same in both cases, a dict with the key/value pairs.
In most cases a dict is what people are going to want anyway.  It avoids
having to unpack then repack the dict.  But it would make it slightly
harder for adding parameters to indexing, although I am skeptical of that
use-case to begin with.  It would also make it feasible to use labels that
aren't valid variable names, although it may not be desirable to support
that.

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul \
21, 2020 at 2:05 PM David Mertz &lt;<a href="mailto:mertz@gnosis.cx" \
target="_blank">mertz@gnosis.cx</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Tue, Jul 21, 2020, 12:14 PM Sebastian Berg  \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> First, using it for named dimensions, means \
you don&#39;t actually need to mix  it with normal tuple indexing, mixing both seems \
rather confusing?<br> <br>
      temperature.loc(method=&quot;nearest&quot;)[longitude=longs, \
latitude=lats]<br></blockquote></div></div><br><div dir="auto">[*] In my opinion, \
passing the keyword argument using anything other than the standard **kws style \
sounds crazy. We have perfectly good ways to do that for every other function or \
method. Don&#39;t invent something new and different that only works with \
.__getitem__().</div></div></blockquote><div><br></div><div>  It would also be \
possible to pass __getitem__ exactly one other argument, a dict with all the named \
arguments.</div><div><br></div><div>So instead of __getitem__(inds, **kwargs) simply \
__getitem__(inds, kwargs)</div><div><br></div><div>&quot;kwargs&quot; would be the \
same in both cases, a dict with the key/value pairs.   In most cases a dict is what \
people are going to want anyway.   It avoids having to unpack then repack the dict.   \
But it would make it slightly harder for adding parameters to indexing, although I am \
skeptical of that use-case to begin with.   It would also make it feasible to use \
labels that aren&#39;t valid variable names, although it may not be desirable to \
support that.<br></div></div></div>



_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WUS2RRY73GOZVUC4BUP7WF6WAXERDDAS/
 Code of Conduct: http://python.org/psf/codeofconduct/



[prev in list] [next in list] [prev in thread] [next in thread]