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: Nobody/Anonymous (nobody) 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-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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com