By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,907 Members | 1,832 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,907 IT Pros & Developers. It's quick & easy.

__getattr__ possible loop

P: n/a
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

Dec 28 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
be************@lycos.com wrote:
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
Dec 28 '06 #2

P: n/a
Maksim Kasimov:
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

Dec 28 '06 #3

P: n/a
On 28 Dec 2006 07:45:05 -0800, be************@lycos.com
<be************@lycos.comwrote:
Maksim Kasimov:
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?
Dec 28 '06 #4

P: n/a
On 12/28/06, Chris Mellon <ar*****@gmail.comwrote:
On 28 Dec 2006 07:45:05 -0800, be************@lycos.com
<be************@lycos.comwrote:
Maksim Kasimov:
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
Dec 28 '06 #5

P: n/a
be************@lycos.com wrote:
Maksim Kasimov:
>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
Dec 28 '06 #6

P: n/a
Chris Mellon wrote:
>
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
Dec 28 '06 #7

P: n/a
At Thursday 28/12/2006 14:01, Maksim Kasimov wrote:
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

Dec 29 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.