Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder1.xlned.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'subject:error': 0.03; 'interpreter': 0.05; 'subject:Python': 0.06; 'element': 0.07; 'level,': 0.07; 'pypy': 0.07; 'responding': 0.07; 'except:': 0.09; 'extracted': 0.09; 'logic': 0.09; 'overflow': 0.09; 'received:209.85.219': 0.09; 'try:': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; 'def': 0.12; 'creates': 0.14; 'posted': 0.15; 'bug,': 0.16; 'crashed': 0.16; 'justified': 0.16; 'occurs.': 0.16; 'then?': 0.16; 'valueerror,': 0.16; 'why,': 0.16; 'exception': 0.16; 'weird': 0.16; 'wrote:': 0.18; 'code.': 0.18; 'trying': 0.19; 'stack': 0.19; 'seems': 0.21; 'code,': 0.22; 'memory': 0.22; 'email addr:gmail.com>': 0.22; 'cc:addr:python.org': 0.22; 'error': 0.23; 'cc:2**0': 0.24; "i've": 0.25; '>': 0.26; 'handling': 0.26; 'pass': 0.26; 'code:': 0.26; 'defined': 0.27; 'header:In-Reply-To:1': 0.27; 'tried': 0.27; 'function': 0.29; 'see,': 0.30; 'message- id:@mail.gmail.com': 0.30; "i'm": 0.30; 'code': 0.31; 'catching': 0.31; 'exceptions': 0.31; 'informative': 0.31; 'file': 0.32; 'up.': 0.33; 'core': 0.34; "i'd": 0.34; 'received:209.85': 0.35; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'similar': 0.36; 'should': 0.36; 'error.': 0.37; 'example,': 0.37; 'level': 0.37; 'received:209': 0.37; 'expected': 0.38; 'skip:& 10': 0.38; 'manager': 0.38; 'handle': 0.38; 'issue': 0.38; 'little': 0.38; 'expect': 0.39; 'does': 0.39; 'itself': 0.39; 'though,': 0.39; 'enough': 0.39; 'even': 0.60; 'skip:u 10': 0.60; 'removing': 0.60; 'lower': 0.61; 'new': 0.61; 'simply': 0.61; 'more': 0.64; 'to:addr:gmail.com': 0.65; 'here': 0.66; 'design.': 0.68; 'statement,': 0.68; 'caused': 0.69; 'behavior': 0.77; '3.3.1': 0.84; 'oscar': 0.84; 'disturb': 0.91; 'not:': 0.91; 'recover': 0.91; 'imagine': 0.93; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qUJCCCMTfyI+N+X1AaEEX/RBGsPWsDOF7r6Kb6+Bupg=; b=BQCEpGAoh8y7hzanfJTNiwPaFlDKiDTQGqeh3JXHDTDqSvUiKfodDsJTxVUQM/HPRb fa+Hp9RcKEHsqFGwki4NUKncs8V7jAcosRM4Z+UWbB02rm3fpgTsKDkWbqV/60+VL2Op 3Hgobz5toKytr9ew54f1auWYbhJC2Oa8Iq/+dQrq2H4IL10DdTjsJsU5VHoRqEuRKHq2 iH2SNp9f3p1QKB5xcBLgv3yDu8GXTUAYOYyRo43uHsNYW1XHiuf8PsiDJ2+SMoDyRb/z Z8smejuOFUWMxh04TW18ez4g45Q5J/IBOVYe+tOfg6gk4F/Ti5ATNoAAaL8uGyYuEnow fPoQ== MIME-Version: 1.0 X-Received: by 10.60.33.102 with SMTP id q6mr1574225oei.111.1369833743324; Wed, 29 May 2013 06:22:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 May 2013 10:22:23 -0300 Subject: Re: Fatal Python error From: Marcel Rodrigues To: Joshua Landau Content-Type: multipart/alternative; boundary=089e01182bf6ac1d8304dddb4581 Cc: python-list X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 137 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1369833751 news.xs4all.nl 15876 [2001:888:2000:d::a6]:37102 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:46376 --089e01182bf6ac1d8304dddb4581 Content-Type: text/plain; charset=UTF-8 I think the issue here has little to do with classes/objects/properties. See, for example, the code posted by Oscar Benjamin. What that code is trying to do is similar to responding to an "Out Of Memory" error with something that might require more memory allocation. Even if we consider the Py3 behavior here a bug, that code is unreliable by design. It's an infinite loop at the best. 2013/5/29 Joshua Landau > On 29 May 2013 13:30, Marcel Rodrigues wrote: > > > > I just tried your code with similar results: it does nothing on PyPy > 2.0.0-beta2 and Python 2.7.4. But on Python 3.3.1 it caused core dump. > > It's a little weird but so is the code. You have defined a function that > calls itself unconditionally. This will cause a stack overflow, which is a > RuntimeError. > > > The weirdness of the code is simply as I've taken all the logic and > conditionality away, since it was irrelevant. Why, though, does removing > any one element make it fail properly? That's what's confusing, largely. > > > > > > Since you are handling this very exception with a pass statement, we > would expect that no error occurs. But the fatal error message seems pretty > informative at this point: "Cannot recover from stack overflow.". > > > > One thing to note is that while it's reasonable to handle exceptions > that happens at the level of your Python code, like a ValueError, it's not > so reasonable to try to handle something that may disturb the interpreter > itself in a lower level, like a stack overflow (I think that the stack used > by your code is the same stack used by the interpreter code, but I'm not > sure). > > > What is the expected response here then? Should I ever feel justified in > catching a Stack Overflow error? This code was extracted from a file > manager after much difficulty, but it should have been "caught" by a global > try...except and not crashed the whole program immediately. I'd imagine > that's a good enough reason to bring this up. > > > > Also; > This works for the code: > > def loop(): > thingwithproperty.prop > loop() > > This does not: > > def loop(): > try: > thingwithproperty.prop > except: > pass > loop() > > thingwithproperty.prop NEVER creates an error. > (.prop is the new .property) > --089e01182bf6ac1d8304dddb4581 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the issue here has little to do with cla= sses/objects/properties. See, for example, the code posted by Oscar Benjamin.

What that code is trying to do is similar to= responding to an "Out Of Memory" error with something that might= require more memory allocation.

Even if we c= onsider the Py3 behavior here a bug, that code is unreliable by design. It&= #39;s an infinite loop at the best.


2013/5/29 Jos= hua Landau <joshua.landau.ws@gmail.com>
On 29 May 2013 13:30, Marcel Rodrigues &= lt;marcelgmr@gmail= .com> wrote:
>
> I just tried your code with similar res= ults: it does nothing on PyPy 2.0.0-beta2 and Python 2.7.4. But on Python 3= .3.1 it caused core dump.
> It's a little weird but so is the code. You have defined a functio= n that calls itself unconditionally. This will cause a stack overflow, whic= h is a RuntimeError.


The weirdness of the code is simply a= s I've taken all the logic and conditionality away, since it was irrele= vant. Why, though, does removing any one element make it fail properly? Tha= t's what's confusing, largely.

=C2=A0
>
> =C2=A0Since you are handling this very exception wit= h a pass statement, we would expect that no error occurs. But the fatal err= or message seems pretty informative at this point: "Cannot recover fro= m stack overflow.".
>
> One thing to note is that while it's reasonable to handle = exceptions that happens at the level of your Python code, like a ValueError= , it's not so reasonable to try to handle something that may disturb th= e interpreter itself in a lower level, like a stack overflow (I think that = the stack used by your code is the same stack used by the interpreter code,= but I'm not sure).


What is the expected response here then? Should I ever feel j= ustified in catching a Stack Overflow error? This code was extracted from a= file manager after much difficulty, but it should have been "caught&q= uot; by a global try...except and not crashed the whole program immediately= . I'd imagine that's a good enough reason to bring this up.



Also;
This works for the code:

def loop():
=C2=A0 = =C2=A0 thingwithproperty.prop
=C2=A0 =C2=A0=C2=A0loop()

This does= not:

def loop():
=C2=A0 =C2=A0 try:
=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0thingwithproperty.prop
=C2=A0 =C2=A0=C2=A0except:
=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0pass
loop()

thingwithproperty.prop NEVER creates an error.
(.prop is t= he new .property)

--089e01182bf6ac1d8304dddb4581--