[Python-ideas] raising an exception type doesn't instantiate it until it gets caught

[Michael Foord]

On 7 November 2011 23:05, Michael Foord <fuzzyman at gmail.com> wrote:

>
>
> On 7 November 2011 21:43, Gregory P. Smith <greg at krypto.org> wrote:
>
>>
>>
>> On Mon, Nov 7, 2011 at 12:05 PM, Cameron Simpson <cs at zip.com.au> wrote:
>>
>>> I wrote, naively:
>>> | > I presume StopIteration would get instantiated to a singleton, like
>>> | > NoneType to None? Just asking.
>>>
>>> On 07Nov2011 22:01, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> | Even without the traceback issue Antoine mentioned, it's already the
>>> | case that StopIteration isn't a singleton in 2.x. Various pieces of
>>> | code (e.g. contextlib.contextmanager) rely on being able to tell
>>> | whether they're getting a specific StopIteration instance back or a
>>> | new one.
>>>
>>> Interesting.
>>>
>>> Off topic digression:
>>>
>>> I've been slightly uncomfortable about exceptions as control flow for a
>>> while, basicly when writing code like this:
>>>
>>>  try:
>>>    x = G.next()
>>>  except StopIteration:
>>>    # G is empty!
>>>
>>> in that I don't entirely know that the StopIteration came from G of from
>>> some buggy code deeper inside G that let a StopIteration out, eg by
>>> mangling a try/except like the above. In most circumstances with other
>>> exceptions, while you might _expect_ the exception to come from the
>>> source you expect you don't care so much because it will indicate
>>> failure of the operation anyway. Report or die, you don't proceed as if
>>> the op was good. But with StopIteration one is reading "G is empty"
>>> directly into the situation and acting as though it is normal (exit the
>>> event loop or whatever it may imply).
>>>
>>
>> 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 *exceptional*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.
>>
>> 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?
>>
>> 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.
>>
>> 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. (*)
>>
>> -gps
>>
>> (*) 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.
>>
>
>
> Having the interpreter instantiate the exception for you allows you to do
> wonderful things like this:
>
> >>> class Foo(Exception):
> ...  def __new__(cls, *args):
> ...   return object()
> ...
> >>> try:
> ...  raise Foo
> ... except Exception as e:
> ...  print (e)
> ...
> <object object at 0x100634280>
>
> (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...)
>


Ooh... this one segfaults Python 3.2 - I wonder if that's been fixed yet.

>>> class Foo(Exception):
...  def __new__(cls, *args):
...   return 'string exception'
...
>>> try:
...  raise Foo
... except Exception as e:
...  print (e)
...
Segmentation fault: 11

All the best,

Michael Foord


>
> All the best,
>
>
> Michael
>
>
>
>>
>>
>>
>>> On 07Nov2011 11:35, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> | It is impossible to use singletons for exception instances now that the
>>> | traceback is stored on them.
>>>
>>> Ah. I had somehow thought the exception itself and the traceback were
>>> distinct items, presented in a tuple.
>>>
>>> On 07Nov2011 21:15, Steven D'Aprano <steve at pearwood.info> wrote:
>>> | Are you asking about what it should be, or what it is?
>>>
>>> The former.
>>>
>>> | Either way:
>>> | >>> a = StopIteration('spam')
>>> | >>> b = StopIteration('ham')
>>> | >>> a is b
>>> | False
>>>
>>> Since my question was about the proposed new behaviour when just a type
>>> was raised, the above test wouldn't educate me. Though it does address
>>> the
>>> behaviour of the type instantation in general.
>>>
>>> Cheers,
>>> --
>>> Cameron Simpson <cs at zip.com.au> DoD#743
>>> http://www.cskk.ezoshosting.com/cs/
>>>
>>> Carpe Datum     - John Sloan <jsloan at ncar.ucar.edu>
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at python.org
>>> http://mail.python.org/mailman/listinfo/python-ideas
>>>
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
>>
>
>
> --
>
> http://www.voidspace.org.uk/
>
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
>
> May you share freely, never taking more than you give.
> -- the sqlite blessing http://www.sqlite.org/different.html
>
>
>


-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111107/ac0e12d7/attachment.html>