[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes

[SourceForge.net]

Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by scott_marks
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: Open
Resolution: None
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Martin v. Löwis (loewis)
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: applebucks (scott_marks)
Date: 2006-10-03 22: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 02: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 12: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