<div dir="ltr"><div><div><div><div><div><div>Something probably not directly related, but since we started to talk about syntactic changes...<br></div>I think what would be great to eventually have is some form of pattern matching.<br></div><div></div>Essentially pattern matching  could be just a "tagged" unpacking protocol.<br></div>For example, something like this will simplify a common pattern<br>with a sequence of if isinstance() branches:<br><br></div>class Single(NamedTuple):<br></div>    x: int<br><br></div>class Pair(NamedTuple):<br><div><div><div><div>    x: int<br></div><div>    y: int<br><br></div><div>def func(arg: Union[Single, Pair]) -> int:<br></div><div>    whether arg:<br>        Single as a:<br></div><div>            return a + 2<br></div><div>        Pair as a, b:<br></div><div>            return a * b<br></div><div>        else:<br></div><div>            return 0<br></div><div><br></div><div>The idea is that the expression before ``as`` is evaluated, then if ``arg`` is an instance of the result,<br>then ``__unpack__`` is called on it. Then the resulting tuple is unpacked into the names a, b, etc.<br><br></div><div>I think named tuples could provide the __unpack__, and especially it would be great for dataclasses<br></div><div>to provide the __unpack__ method. (Maybe we can then call it __data__?)<br></div><div><br>--<br></div><div>Ivan<br><br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 July 2017 at 11:39, Clément Pit-Claudel <span dir="ltr"><<a href="mailto:cpitclaudel@gmail.com" target="_blank">cpitclaudel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017-07-20 11:30, Paul Moore wrote:<br>
> On 20 July 2017 at 10:15, Clément Pit-Claudel <<a href="mailto:cpitclaudel@gmail.com">cpitclaudel@gmail.com</a>> wrote:<br>
>> On 2017-07-20 11:02, Paul Moore wrote:<br>
>>>> Also, what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)? I.e.,<br>
>>>> why does this need to be syntax instead of a library?<br>
>>><br>
>>> Agreed. Now that keyword argument dictionaries retain their order,<br>
>>> there's no need for new syntax here. In fact, that's one of the key<br>
>>> motivating reasons for the feature.<br>
>><br>
>> Isn't there a speed aspect?  That is, doesn't the library approach require creating (and likely discarding) a dictionary every time a new ntuple is created?  The syntax approach wouldn't need to do that.<br>
><br>
> I don't think anyone has suggested that the instance creation time<br>
> penalty for namedtuple is the issue (it's the initial creation of the<br>
> class that affects interpreter startup time), so it's not clear that<br>
> we need to optimise that (at this stage)<br>
<br>
</span>Indeed, it's not clear we do.  I was just offering a response to the original question, "what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)?".<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br></div>