<div dir="ltr"><font face="arial, helvetica, sans-serif">I don't understand the rationale behind PEP 463's rejection. Guido says, "</font><span style="color:rgb(68,68,68);background-color:rgb(249,249,249)"><font face="arial, helvetica, sans-serif" style="">I disagree with the position that EAFP is better than LBYL, or "generally recommended" by Python. (Where do you get that?..."; but it's been <a href="https://docs.python.org/3/glossary.html" style="">in the official Python.org docs</a> for a while and even provides a pretty good justification for why EAFP is preferable to LBYL (aside from the language calling EAFP "common", "clean", and "fast" that's notably absent from LBYL's description):<br></font><br><font face="arial, helvetica, sans-serif">"</font></span><font face="arial, helvetica, sans-serif"><span style="text-align:justify">In a multi-threaded environment, the LBYL approach can risk introducing a race condition between “the looking” and “the leaping”. For example, the code, </span><code class="gmail-docutils gmail-literal gmail-notranslate" style="background-color:rgb(236,240,243);padding:0px 1px;border-radius:3px;text-align:justify"><span class="gmail-pre" style="hyphens: none;">if</span> <span class="gmail-pre" style="hyphens: none;">key</span> <span class="gmail-pre" style="hyphens: none;">in</span> <span class="gmail-pre" style="hyphens: none;">mapping:</span> <span class="gmail-pre" style="hyphens: none;">return</span><span class="gmail-pre" style="hyphens: none;">mapping[key]</span></code><span style="text-align:justify"> can fail if another thread removes </span><em style="text-align:justify">key</em><span style="text-align:justify"> from </span><em style="text-align:justify">mapping</em></font><span style="text-align:justify"><font face="arial, helvetica, sans-serif" style=""> after the test, but before the lookup. This issue can be solved with locks or by using the EAFP approach."<br></font><br>Which brings me to the question: What happens when a PEP gets rejected? Is it final? Is there a process for reviving a PEP?<br><br>I personally would love to have <b>both</b> more consistent methods on built-in classes AND exception handling expressions. I think the colon (and maybe 'except' keyword) could be replaced with an exclamation point:<br><br> </span><span style="background-color:rgb(249,249,249);color:rgb(68,68,68);font-family:Consolas,"Lucida Console","Liberation Mono","DejaVu Sans Mono","Bitstream Vera Sans Mono","Courier New",monospace,sans-serif;font-size:15px;white-space:pre-wrap">value = lst[2] except IndexError! "No value"</span><span style="text-align:justify"><br></span><br>or just:<br><br><pre class="gmail-literal-block" style="box-sizing:border-box;margin-top:0px;margin-bottom:1.3125em;padding:0.5em;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;font-size:15px;line-height:1.875;font-family:Consolas,"Lucida Console","Liberation Mono","DejaVu Sans Mono","Bitstream Vera Sans Mono","Courier New",monospace,sans-serif;vertical-align:baseline;white-space:pre-wrap;background-image:inherit;background-position:inherit;background-size:inherit;background-repeat:inherit;background-origin:inherit;background-clip:inherit;background-color:rgb(249,249,249);color:rgb(68,68,68)"> value = lst[2] IndexError! "No value"
</pre>if that appeases the people who dislike the over-use of colons.<br><br>A full exception list would have to be in parentheses which get's ugly, but would also be (I would wager) a less common form:<br><span style="background-color:rgb(249,249,249);color:rgb(68,68,68);font-family:Consolas,"Lucida Console","Liberation Mono","DejaVu Sans Mono","Bitstream Vera Sans Mono","Courier New",monospace,sans-serif;font-size:15px;white-space:pre-wrap"><br></span><div><span style="background-color:rgb(249,249,249);color:rgb(68,68,68);font-family:Consolas,"Lucida Console","Liberation Mono","DejaVu Sans Mono","Bitstream Vera Sans Mono","Courier New",monospace,sans-serif;font-size:15px;white-space:pre-wrap"> dirlist.append(os.getcwd() (AttributeError, OSError as e)! os.curdir)</span><br><br>That might need some work. I don't know if it's compatible w/ the compiler. It may have to start with "try" or something, but it seems pretty close to a workable solution.<br><br class="gmail-Apple-interchange-newline"><span style="text-align:justify"><br><br></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 4:42 AM Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Oct 31, 2018 at 8:24 PM Nicolas Rolin <<a href="mailto:nicolas.rolin@tiime.fr" target="_blank">nicolas.rolin@tiime.fr</a>> wrote:<br>
><br>
><br>
> As a user I always found a bit disurbing that dict pop method have a default while list and set doesn't.<br>
> While it is way more computationally easy to check wether a list or a set is empty that to check if a key is in a dict, it still create a signature difference for no real reason (having a default to a built-in in python is pretty standard).<br>
> It would be nice if every built-in/method of built-in type that returns a value and raise in some case have access to a default instead of raise, and not having to check the doc to see if it supports a default.<br>
><br>
<br>
<a href="https://www.python.org/dev/peps/pep-0463/" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0463/</a> wants to say hi.<br>
<br>
ChrisA<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>