
December 28th, 2006, 02:15 PM
| | | __getattr__ possible loop
I have tried this, with Psyco it segfaults, and with Python 2.5 (on
Win) hangs the interpreter, is it possible to improve the situation?
class T(object):
def __getattr__(self, x): dir(self)
#import psyco
#psyco.full()
T().method()
(Probably dir calls __getattr__).
Bye,
bearophile | 
December 28th, 2006, 03:35 PM
| | | Re: __getattr__ possible loop bearophileHUGS@lycos.com wrote: Quote:
I have tried this, with Psyco it segfaults, and with Python 2.5 (on
Win) hangs the interpreter, is it possible to improve the situation?
>
class T(object):
def __getattr__(self, x): dir(self)
#import psyco
#psyco.full()
T().method()
>
(Probably dir calls __getattr__).
>
Bye,
bearophile
>
| how to improve the situation depends on what do you expect to get by calling "T().method()"
dir calls __getattr__ with the value '__members__', for example you can write:
def __getattr__(self, x):
if x == '__members__':
return ('method1', 'field1', )
--
Maksim Kasimov | 
December 28th, 2006, 03:55 PM
| | | Re: __getattr__ possible loop
Maksim Kasimov: Quote: |
how to improve the situation depends on what do you expect to get by calling "T().method()"
| You are right, sorry for being cryptic. I think that's a kind of bug of
Python (produced maybe by an infinite loop), so an improvement can be a
traceback or some automatic breaking of that loop. Note that my problem
comes from using Psyco that segfaults in that situation (if you have
Psyco installed you can decomment two lines to see that). I think that
using normal code Python+Psyco don't have to segfault, but I know this
is tricky situation, so if no simple "solutions" can be found, then
it's not a important thing and it can be ignored.
Bye,
bearophile | 
December 28th, 2006, 04:35 PM
| | | Re: __getattr__ possible loop
On 28 Dec 2006 07:45:05 -0800, bearophileHUGS@lycos.com
<bearophileHUGS@lycos.comwrote: Quote:
Maksim Kasimov: Quote: |
how to improve the situation depends on what do you expect to get by calling "T().method()"
| >
You are right, sorry for being cryptic. I think that's a kind of bug of
Python (produced maybe by an infinite loop), so an improvement can be a
traceback or some automatic breaking of that loop. Note that my problem
comes from using Psyco that segfaults in that situation (if you have
Psyco installed you can decomment two lines to see that). I think that
using normal code Python+Psyco don't have to segfault, but I know this
is tricky situation, so if no simple "solutions" can be found, then
it's not a important thing and it can be ignored.
>
| What I find most interesting is that you don't crash out because of
hitting the recursion limit. My brief testing shows something odd
going on - when the stack depth gets to almost 1000 (the recursion
limit on my system) it knocks some stuff off the stack and the stack
limit never gets to the limit. Some sort of built in tail recursion? | 
December 28th, 2006, 04:45 PM
| | | Re: __getattr__ possible loop
On 12/28/06, Chris Mellon <arkanes@gmail.comwrote: Quote:
On 28 Dec 2006 07:45:05 -0800, bearophileHUGS@lycos.com
<bearophileHUGS@lycos.comwrote: Quote:
Maksim Kasimov: Quote: |
how to improve the situation depends on what do you expect to get by calling "T().method()"
| You are right, sorry for being cryptic. I think that's a kind of bug of
Python (produced maybe by an infinite loop), so an improvement can be a
traceback or some automatic breaking of that loop. Note that my problem
comes from using Psyco that segfaults in that situation (if you have
Psyco installed you can decomment two lines to see that). I think that
using normal code Python+Psyco don't have to segfault, but I know this
is tricky situation, so if no simple "solutions" can be found, then
it's not a important thing and it can be ignored.
| >
What I find most interesting is that you don't crash out because of
hitting the recursion limit. My brief testing shows something odd
going on - when the stack depth gets to almost 1000 (the recursion
limit on my system) it knocks some stuff off the stack and the stack
limit never gets to the limit. Some sort of built in tail recursion?
>
| Nothing so clever. dir() eats and ignores all exceptions, so when you
hit the recursion limit it eats the RecursionLimitExceeded exception
and continues merrily along the way. This is probably not good
behavior...
class Foo:
def __getattr__(self, attr):
raise SystemExit, "Don't call me, again, ever"
f = Foo()
f.method() #dies correctly
dir(f) #continues happily | 
December 28th, 2006, 04:55 PM
| | | Re: __getattr__ possible loop bearophileHUGS@lycos.com wrote: Quote:
Maksim Kasimov: Quote: |
>how to improve the situation depends on what do you expect to get by calling "T().method()"
| >
You are right, sorry for being cryptic. I think that's a kind of bug of
Python (produced maybe by an infinite loop), so an improvement can be a
traceback or some automatic breaking of that loop. Note that my problem
comes from using Psyco that segfaults in that situation (if you have
Psyco installed you can decomment two lines to see that). I think that
using normal code Python+Psyco don't have to segfault, but I know this
is tricky situation, so if no simple "solutions" can be found, then
it's not a important thing and it can be ignored.
>
Bye,
bearophile
>
| it is neither a bug of python neither it comes from using Psyco,
the problem is here:
def __getattr__(self, x): dir(self)
the "__getattr__" method calls "dir",
but then "dir" calls "__getattr__" method of the object (self) - it makes endless loop
(see the code in my previous message)
--
Maksim Kasimov | 
December 28th, 2006, 05:05 PM
| | | Re: __getattr__ possible loop
Chris Mellon wrote: Quote:
>
Nothing so clever. dir() eats and ignores all exceptions, so when you
hit the recursion limit it eats the RecursionLimitExceeded exception
and continues merrily along the way. This is probably not good
behavior...
>
class Foo:
def __getattr__(self, attr):
raise SystemExit, "Don't call me, again, ever"
>
f = Foo()
f.method() #dies correctly
dir(f) #continues happily
| can't understand - what kind of problem you tried to fix in that way?
if __getattr__ just raise some exception, it needless to define it at all.
--
Maksim Kasimov | 
December 29th, 2006, 12:25 AM
| | | Re: __getattr__ possible loop
At Thursday 28/12/2006 14:01, Maksim Kasimov wrote: Quote: Quote:
Nothing so clever. dir() eats and ignores all exceptions, so when you
hit the recursion limit it eats the RecursionLimitExceeded exception
and continues merrily along the way. This is probably not good
behavior...
class Foo:
def __getattr__(self, attr):
raise SystemExit, "Don't call me, again, ever"
f = Foo()
f.method() #dies correctly
dir(f) #continues happily
| >
>can't understand - what kind of problem you tried to fix in that way?
>if __getattr__ just raise some exception, it needless to define it at all.
| The problem is, dir() blindly eats *all* exceptions, including the
RecursionLimitExceeded on the original post, this SystemExit,
KeyboardInterrupt, etc. It shouldn't.
Perhaps this example (esencially the same thing) is a bit more clear:
import sys
class Foo:
def __getattr__(self, attr):
print "About to exit program"
sys.exit(1)
f = Foo()
dir(f)
print "You should not see this line"
--
Gabriel Genellina
Softlab SRL
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya! http://www.yahoo.com.ar/respuestas |
Posting Rules
| You may not post new threads You may not post replies You may not post attachments You may not edit your posts HTML code is Off | | | | | | What is Bytes?
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over network members.
|