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

List:       python-ideas
Subject:    [Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thre
From:       Todd <toddrjen () gmail ! com>
Date:       2020-08-27 5:01:21
Message-ID: CAFpSVp+QmJkUfnevPpJnSBFqN9Ej4GhhYRHmLXVEpXaSna9z-g () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Thu, Aug 27, 2020, 00:56 Bruce Leban <bruce@leban.us> wrote:

> A bunch of the conversation here is how to handle both positional and
> keyword arguments with a single signature. Let me suggest an alternative.
> At compile time, we know if the call is made with keyword arguments or not.
>
> a[1]         positional only
> a[b=1]       keyword only
> a[1, b=1]    both
> a[**kwargs]  keyword only
>
> I suggest that in the first case it calls
>         __getitem__(self, args)
> as it does now and in the other cases it calls
>         __getitemx__(self, args, **kwargs)
> instead (the signature is what matters here, don't bikeshed the name).
> Some people have proposed arbitrary signatures for __getitemx__ but I
> think that's an unnecessary degree of complexity for little benefit.
> Personally, I'm not even sure I'd ever want to mix args and kwargs but
> including that in the signature preserves that possibility for others that
> find it useful.
>
> To explain further: when I use [...] without positional arguments the
> code works exactly as it does today with all args in a tuple. Therefore,
> for consistency when I add a keyword argument that should not change the
> args value which is why both signatures include a single args parameter.
>
> If you write a form that uses a keyword argument, and __getitemx__ does
> not exist then it would raise an error other than KeyError (either
> TypeError or AttributeError, with the latter requiring no special handling).
>
> --- Bruce
>
 What is the advantage of this over adding keyword arguments to the
existing find dunders?

[Attachment #5 (text/html)]

<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Aug 27, 2020, 00:56 Bruce Leban &lt;<a \
href="mailto:bruce@leban.us">bruce@leban.us</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">A bunch of the conversation here is how to \
handle both positional and keyword arguments with a single signature. Let me suggest \
an alternative. At compile time, we know if the call is made with keyword arguments \
or not.<div><br></div><div><font face="monospace">a[1]              positional \
only</font></div><div><font face="monospace">a[b=1]           keyword \
only</font></div><div><font face="monospace">a[1, b=1]      \
both</font></div><div><font face="monospace">a[**kwargs]   keyword \
only</font></div><div><br></div><div>I suggest that in the first case it \
calls</div><div><font face="monospace">            __getitem__(self, \
args)</font></div><div>as it does now and in the other cases it calls</div><div><font \
face="monospace">            __getitemx__(self, args, \
**kwargs)</font></div><div>instead (the signature is what matters here, don&#39;t \
bikeshed the name). Some people have proposed arbitrary signatures for <font \
face="monospace">__getitemx__</font> but I think that&#39;s an unnecessary degree of \
complexity for little benefit. Personally, I&#39;m not even sure I&#39;d ever want to \
mix args and kwargs but including that in the signature preserves that possibility \
for others that find it useful.</div><div><br></div><div>To explain further: when I \
use <font face="monospace">[...]</font> without positional arguments the code works \
exactly as it does today with all args in a tuple. Therefore, for consistency when I \
add a keyword argument that should not change the args value which is why both \
signatures include  a single args parameter.</div><div><br></div><div>If you write a \
form that uses a keyword argument, and <font face="monospace">__getitemx__</font> \
does not exist then it would raise an error other than KeyError (either TypeError or \
AttributeError, with the latter  requiring no special \
handling).</div><div><br></div><div>--- \
Bruce</div></div></blockquote></div></div><div dir="auto">  What is the advantage of \
this over adding keyword arguments to the existing find dunders?</div><div \
dir="auto"></div><div dir="auto"><br></div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></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/7EVIBDML643EGMPM4OJXGMNMHPJ6RQSE/
 Code of Conduct: http://python.org/psf/codeofconduct/



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