<p dir="ltr"><br>
On 12 Apr 2014 20:54, "Chris Angelico" <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br>
><br>
> On Sun, Apr 13, 2014 at 5:28 AM, Joseph Martinot-Lagarde<br>
> <<a href="mailto:joseph.martinot-lagarde@m4x.org">joseph.martinot-lagarde@m4x.org</a>> wrote:<br>
> > The main use case is to be able to set a default value for indexing. I<br>
> > though about it after reading PEP 463 (Exception-catching expressions), this<br>
> > would be an alternative for one of the problem this PEP is trying to solve.<br>
> > Compare these solutions:<br>
> >>>> lst = [1, 2, 3]<br>
> >>>> value = lst[3]<br>
> > Traceback (most recent call last):<br>
> >   File "<stdin>", line 1, in <module><br>
> > IndexError: list index out of range<br>
> >>>> try:  # Python<br>
> > ....     value = lst[3]<br>
> > .... except IndexError:<br>
> > ....     value = 0<br>
> >>>> value = lst[3] except IndexError: 0  # PEP 463<br>
> >>>> value = lst[3, default=0]  # My proposal<br>
><br>
> An interesting idea, but that looks far too much like a function call.<br>
> Square brackets and then more and more a function call inside... may<br>
> fail the grit test.<br>
><br>
> Part of the point of except expressions was that the implementation of<br>
> __getitem__ wouldn't need to have two branches in it. Currently, you<br>
> need to write __getitem__ (which raises an exception on finding a<br>
> problem) plus something else, eg get(), which returns a default<br>
> instead. By your proposal, both branches would go inside __getitem__,<br>
> which means they could share code; but there still need to be two<br>
> branches. That's two branches that need to be written, tested, etc,<br>
> and if the author hasn't thought to handle default=, there's no way to<br>
> get that functionality, same as if there's no get() method. And just<br>
> as with the get method, there'll be an ad-hoc and fairly arbitrary<br>
> puddle of names (some will go "default=", others will say that's way<br>
> too long and go "def=", except that that's a keyword so they'll use<br>
> "dflt=" or something...), unless there's a strong force pushing people<br>
> to one consistent name. Terry's suggestion solves that part of it, but<br>
> also restricts the feature to just default values; with a more general<br>
> keyword argument system, it would make sense to also use this with<br>
> __setitem__ and __delitem__, and I'm not sure how "default value"<br>
> should be interpreted there. Which is better is, of course, a matter<br>
> of opinion! :)</p>
<p dir="ltr">A getitem() builtin seems like a more obvious parallel with getattr(), and pairs up nicely with operator.itemgetter.</p>
<p dir="ltr">Proposals of additional special cases like this is a reasonable outcome of the rejection of the except expressions PEP.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> ChrisA<br>
> _______________________________________________<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">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
> Code of Conduct: <a href="http://python.org/psf/codeofconduct/">http://python.org/psf/codeofconduct/</a><br>
</p>