[Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 10 Aug 2001 10:38:22 -0700
Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: inspect.stack() refcount problem
Initial Comment:
The attached code exhibits the problem: Calling a
function that assigns the results of inspect.stack()
to a local variable causes an extra ref to objects in
the caller's space. Not doing the assignment does not
cause the problem.
Appears that the stack frame is disrupting the
reference counting in some way.
Tested with Python 2.1 and 2.1.1
----------------------------------------------------------------------
>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 10:38
Message:
Logged In: YES
user_id=3066
Added warning in the inspect documentation as
Doc/lib/libinspect.tex revision 1.4.
----------------------------------------------------------------------
Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 15:21
Message:
Logged In: YES
user_id=20438
I understand your point, but I disagree with it wrt GC.
Assuming I am willing to take on the cost/risk of using
sys._getframe() I should be able to find documentation
that describes at least minimally the risks related to GC,
threads, and recursion. This is because I don't want to
become a Python master, just use the language well to make
my job easier.
For example, I am making use of sys._getframe() to make
coding an Interceptor pattern less mind numbing. I
recognize that I need to be careful - and previously have
even gone so far into the code as to provide a Python
patch to implement sys._getframes().
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-08 14:06
Message:
Logged In: YES
user_id=31435
Yes and no. There are about 100 internal types implemented
in C, and you've probably never even heard of most of them
(heck, I bet even Guido wouldn't recognize the names of
dozens of them). So if we give you a giant list of which
do and don't participate in gc, what good would it do you?
sys._getframe() starts with an underscore to scare you
away: it's an internal function that only experts should
even think about using.
You're using inspect.stack(), and that's where the problem
is: if we expose a "high level" interface that isn't meant
for experts only, then *that's* where cautions about cycles
should appear, in its docs. You need to know that
inspect.stack can get you in trouble, but going on about
internal implementation details isn't going to help -- the
latter is at the wrong level for inspect.stack()'s users.
----------------------------------------------------------------------
Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:26
Message:
Logged In: YES
user_id=20438
tim_one, are you saying that the objects that do/don't
participate in gc shouldn't be documented?!?
I'm certainly no expert in Python internals but I
understand enough to know what that distinction means and
would like to see the list documented for each release.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-08-08 13:16
Message:
Logged In: YES
user_id=31435
__del__ only applies to objects coded *in* Python. frame
objects are coded in C, and __del__ isn't relevant to those.
Not all objects are tracked by gc, and the set of objects
which are changes from release to release (it grows); even
if that were documented, you'd never be able to keep it
straight unless you were an expert too in how Python is
implemented, and in all the implementation variations
across releases.
Tracking an object type in gc has both memory and speed
costs, so the pressure has been to do it only for object
types highly likely to be involved in cycles. Since you
really can't get a cycle involving frame objects unless
you're doing disgusting tricks <wink>, frame objects were
left out of this subsystem.
In 2.2 that changes, though, because the addition of
generators and iterators makes it more likely that a frame
object can end up in a cycle even when you're not playing
games with _getframe(). That is, frame objects in cycles
will be collected by magic in 2.2 (they already are in the
current CVS Python).
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 13:10
Message:
Logged In: YES
user_id=6380
In Python 2.1 and 2.1.1, frames are not GC'ed.
In Python 2.2 they will be (they are in CVS but they weren't
in 2.2a1).
I don't understand your question about __del__ methods.
I agree with the documentation question, but don't know
where best to add this. I'll reopen this as a documentation
issue and assign to Fred.
----------------------------------------------------------------------
Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06
Message:
Logged In: YES
user_id=20438
What about GC collection of circular references?
Which object in the cycle (frame or frame locals)
implements a __del__() method?
At the least the documentation should be more clear about
which builtins implement del and therefore are not
collectable.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45
Message:
Logged In: YES
user_id=6380
Your attachment didn't work.
But don't bother. The behavior you describe is not a bug.
It creates a circular reference. If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470