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?!" 

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.

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?

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.

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).

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.

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...

Code coverage tools run afoul

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.

Fixed in rev. 53954.  Not sure if this should be backported.

It would be great if this could be backported.

Assigning to the 2.4/2.5 RM.

Because of the incompatibility in locals(), this patch cannot be backported.