Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Comment added) made by jhylton
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: applebucks (scott_marks)
Assigned to: Jeremy Hylton (jhylton)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
----------------------------------------------------------------------
>Comment By: Jeremy Hylton (jhylton)
Date: 2007-02-26 18:41
Message:
Logged In: YES
user_id=31392
Originator: NO
Fixed in rev. 53954. Not sure if this should be backported.
----------------------------------------------------------------------
Comment By: Jp Calderone (kuran)
Date: 2007-02-25 18:23
Message:
Logged In: YES
user_id=366566
Originator: NO
Ahem.
Code coverage tools run afoul of this bug as well. A common case is to
run coverage tools using a test suite. If this bug is triggered, then the
resulting coverage data isn't valid.
----------------------------------------------------------------------
Comment By: Jp Calderone (kuran)
Date: 2007-02-25 18:21
Message:
Logged In: YES
user_id=366566
Originator: NO
Code coverage tools run afoul
----------------------------------------------------------------------
Comment By: John Ehresman (jpe)
Date: 2006-10-30 16:53
Message:
Logged In: YES
user_id=22785
This could & probably should be fixed, at the cost of making
the core debugger support more complicated. The current
version of TurboGears has code that triggers the same bug.
That said, I don't have a patch to fix the core...
----------------------------------------------------------------------
Comment By: applebucks (scott_marks)
Date: 2006-10-08 23:54
Message:
Logged In: YES
user_id=120857
I didn't say Python is lame. I use Python heavily,
apparently an uncommonly large subset of Python
functionality at that, and largely love it. That's why the
failure of semantic transparency caused by something
apparently irrelevant (tracing, as opposed to some kind of
deliberate stack frame munging) is disturbing.
Not to mention it makes my debugging tough. :)
More seriously, one of the users of the subsystem in which
this bug shows us just (on Friday) lost a few hours chasing
a real bug that should have been obvious but which was
masked by this error as manifest by a bdb-based debugger.
----------------------------------------------------------------------
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-07 16:54
Message:
Logged In: YES
user_id=341410
I'm not going to comment on the internals, because I don't
know enough about them to make a positive comment, but it
seems to me that your statement of:
..."just makes Python seem ... lame."
is insulting to those who have helped to develop Python over
the years. In my experience attempting to help, the surest
way of not getting what you want is to insult those who have
developed Python (nevermind that according to the lack of
bugs on the topic, very few people want/need the
functionality you expect).
----------------------------------------------------------------------
Comment By: applebucks (scott_marks)
Date: 2006-10-04 02:32
Message:
Logged In: YES
user_id=120857
"Cannot be fixed" sounds pretty final, and also a little
pessimistic. From your description, it seems that the
correct functionality could be maintained at the cost of
retention of the keys in "normal locals" and dissection back
into "fast locals" and "normal locals" after the trace
function does ... whatever it does. In particular, it seems
unacceptable that the invariants of the semantics of class
creation (on which introspection and other important
functionality depends) is borked by debugging in such a way
as to render quite misleading the process of debugging code
that depends on those invariants.
Not to mention that the workaround ("be sure to rename your
class factory function parameters so that they don't collide
with intended attributes of the created class") just makes
Python seem ... lame.
I hope for a more optimistic reply.
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 06:49
Message:
Logged In: YES
user_id=849994
I'm afraid that this cannot be fixed.
In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.
If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.
Martin, do you you have an additional opinion?
----------------------------------------------------------------------
Comment By: applebucks (scott_marks)
Date: 2006-10-02 16:02
Message:
Logged In: YES
user_id=120857
This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation. The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
