<br><br><div class="gmail_quote">On 7 November 2011 23:06, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@gmail.com">fuzzyman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On 7 November 2011 23:05, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@gmail.com" target="_blank">fuzzyman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On 7 November 2011 21:43, Gregory P. Smith <span dir="ltr"><<a href="mailto:greg@krypto.org" target="_blank">greg@krypto.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On Mon, Nov 7, 2011 at 12:05 PM, Cameron Simpson <span dir="ltr"><<a href="mailto:cs@zip.com.au" target="_blank">cs@zip.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I wrote, naively:<br>
<div>| > I presume StopIteration would get instantiated to a singleton, like<br>
| > NoneType to None? Just asking.<br>
<br>
</div><div>On 07Nov2011 22:01, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
| Even without the traceback issue Antoine mentioned, it's already the<br>
| case that StopIteration isn't a singleton in 2.x. Various pieces of<br>
| code (e.g. contextlib.contextmanager) rely on being able to tell<br>
| whether they're getting a specific StopIteration instance back or a<br>
| new one.<br>
<br>
</div>Interesting.<br>
<br>
Off topic digression:<br>
<br>
I've been slightly uncomfortable about exceptions as control flow for a<br>
while, basicly when writing code like this:<br>
<br>
try:<br>
x = G.next()<br>
except StopIteration:<br>
# G is empty!<br>
<br>
in that I don't entirely know that the StopIteration came from G of from<br>
some buggy code deeper inside G that let a StopIteration out, eg by<br>
mangling a try/except like the above. In most circumstances with other<br>
exceptions, while you might _expect_ the exception to come from the<br>
source you expect you don't care so much because it will indicate<br>
failure of the operation anyway. Report or die, you don't proceed as if<br>
the op was good. But with StopIteration one is reading "G is empty"<br>
directly into the situation and acting as though it is normal (exit the<br>
event loop or whatever it may imply).<br></blockquote></div></div><div><br>Agreed. Use of exceptions for this in the language feels like it was a convenient way to do it but as the conditions aren't really <i>exceptional</i> at all it'd be nice if there were a lighter weight mechanism that could skip the unneeded parts of the exception raising and handling mechanism for the implementation. We don't need the traceback to be stored in these situations.<br>
<br>This existing logic to instantiate and associate the traceback with it only if caught is one way to implement doing exactly that. Any other ideas?<br><br>Hackish things like a class attribute on classes being raised as an exception, or a LightweightException class being part of its class heirarchy used to signify if that exception should take the full path or the fast path come to mind but could be considered equally surprising.<br>
<br>I'm not sure any of this is worth it but it would simplify the eval loop. We're speaking implementation details of CPython here, not an actual change to the language itself. (*)<br><br>-gps<br><br>(*) Please beat anybody who writes code that depends on this somewhat odd exception instantiation timing behavior side effect over the head with a frozen herring.<br>
</div></div></blockquote><div><br></div><div><br></div></div></div><div>Having the interpreter instantiate the exception for you allows you to do wonderful things like this:</div><div><br></div><div><div>>>> class Foo(Exception):</div>
<div>... def __new__(cls, *args):</div><div>... return object()</div><div>... </div><div>>>> try:</div><div>... raise Foo</div><div>... except Exception as e:</div><div>... print (e)</div><div>... </div><div>
<object object at 0x100634280></div></div><div><br></div><div>(I know this has nothing to do with the topic being debated but for some reason this code tickles me. Plus it used to segfault Python 3...)</div></div></blockquote>
<div><br></div><div><br></div></div></div><div>Ooh... this one segfaults Python 3.2 - I wonder if that's been fixed yet.</div><div><br></div><div><div class="im"><div>>>> class Foo(Exception):</div><div>... def __new__(cls, *args):</div>
</div><div>... return 'string exception'</div><div class="im"><div>... </div><div>>>> try:</div><div>... raise Foo</div><div>... except Exception as e:</div><div>... print (e)</div><div>... </div></div>
<div>Segmentation fault: 11</div></div></div></blockquote><div><br></div><div><br></div><div>Yeah, fixed on 3.2 branch and trunk. Sorry for all the noise. I finally managed to get Python head to compile on OS X Lion, yay!</div>
<div><br></div><div>Michael</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>
</div><div><br></div><div>All the best,</div><div><br></div><font color="#888888"><div>Michael Foord</div></font><div><div></div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div><br>
</div><div>All the best,</div><div><br></div><div><br></div><div>Michael</div><div><div></div><div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>
<br><br></div><div><div></div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><br>
On 07Nov2011 11:35, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>> wrote:<br>
| It is impossible to use singletons for exception instances now that the<br>
| traceback is stored on them.<br>
<br>
</div>Ah. I had somehow thought the exception itself and the traceback were<br>
distinct items, presented in a tuple.<br>
<div><br>
On 07Nov2011 21:15, Steven D'Aprano <<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>> wrote:<br>
| Are you asking about what it should be, or what it is?<br>
<br>
</div>The former.<br>
<div><br>
| Either way:<br>
| >>> a = StopIteration('spam')<br>
| >>> b = StopIteration('ham')<br>
| >>> a is b<br>
| False<br>
<br>
</div>Since my question was about the proposed new behaviour when just a type<br>
was raised, the above test wouldn't educate me. Though it does address the<br>
behaviour of the type instantation in general.<br>
<br>
Cheers,<br>
<div>--<br>
Cameron Simpson <<a href="mailto:cs@zip.com.au" target="_blank">cs@zip.com.au</a>> DoD#743<br>
<a href="http://www.cskk.ezoshosting.com/cs/" target="_blank">http://www.cskk.ezoshosting.com/cs/</a><br>
<br>
</div>Carpe Datum - John Sloan <<a href="mailto:jsloan@ncar.ucar.edu" target="_blank">jsloan@ncar.ucar.edu</a>><br>
<div><div></div><div>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div></div></div><br>
<br>_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
<br></blockquote></div></div></div><font color="#888888"><br><br clear="all"><div><br></div>-- <br><pre cols="72"><a href="http://www.voidspace.org.uk/" target="_blank">http://www.voidspace.org.uk/</a><br><br>May you do good and not evil<br>
May you find forgiveness for yourself and forgive others<br>
May you share freely, never taking more than you give.<br>-- the sqlite blessing <a href="http://www.sqlite.org/different.html" target="_blank">http://www.sqlite.org/different.html</a></pre>
<br>
</font></blockquote></div></div></div><div><div></div><div class="h5"><br><br clear="all"><div><br></div>-- <br><pre cols="72"><a href="http://www.voidspace.org.uk/" target="_blank">http://www.voidspace.org.uk/</a><br><br>
May you do good and not evil<br>May you find forgiveness for yourself and forgive others<br>
May you share freely, never taking more than you give.<br>-- the sqlite blessing <a href="http://www.sqlite.org/different.html" target="_blank">http://www.sqlite.org/different.html</a></pre>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><pre cols="72"><a href="http://www.voidspace.org.uk/" target="_blank">http://www.voidspace.org.uk/</a><br><br>May you do good and not evil<br>May you find forgiveness for yourself and forgive others<br>
May you share freely, never taking more than you give.<br>-- the sqlite blessing <a href="http://www.sqlite.org/different.html" target="_blank">http://www.sqlite.org/different.html</a></pre>
<br>