[ python-Bugs-1583276 ] Different behavior when stepping through code w/ pdb
Bugs item #1583276, was opened at 2006-10-24 00:54 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior when stepping through code w/ pdb Initial Comment: The attached test case will raise a NameError when executed in pdb by stepping though the code. The issue is the EnumType name, which is both a local variable in the Enum function which is used in the lambda and the name of an attribute on the EnumValue class. Since it is a local variable used in a lambda, it's a freevar. What apparently happens is on line 5 the property() result is stored in frame->f_locals['EnumType'] but it is deleted the next time FastToLocals is invoked prior to calling back into the debugger. This happens when the freevars values are merged into the locals dictionary. The example is a stripped down version of code in turbogears. -- >Comment By: John Ehresman (jpe) Date: 2006-10-30 16:15 Message: Logged In: YES user_id=22785 I'm a bit confused -- http://python.org/sf/1583276 seems to resolve to this bug. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-27 06:23 Message: Logged In: YES user_id=341410 This seems to be a duplicate of http://python.org/sf/1583276 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583276 ] Different behavior when stepping through code w/ pdb
Bugs item #1583276, was opened at 2006-10-23 17:54 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior when stepping through code w/ pdb Initial Comment: The attached test case will raise a NameError when executed in pdb by stepping though the code. The issue is the EnumType name, which is both a local variable in the Enum function which is used in the lambda and the name of an attribute on the EnumValue class. Since it is a local variable used in a lambda, it's a freevar. What apparently happens is on line 5 the property() result is stored in frame->f_locals['EnumType'] but it is deleted the next time FastToLocals is invoked prior to calling back into the debugger. This happens when the freevars values are merged into the locals dictionary. The example is a stripped down version of code in turbogears. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-30 08:41 Message: Logged In: YES user_id=341410 Sorry! What I meant to say is that this seems to be a duplicate of http://python.org/sf/1569356 . -- Comment By: John Ehresman (jpe) Date: 2006-10-30 08:15 Message: Logged In: YES user_id=22785 I'm a bit confused -- http://python.org/sf/1583276 seems to resolve to this bug. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-26 23:23 Message: Logged In: YES user_id=341410 This seems to be a duplicate of http://python.org/sf/1583276 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583276 ] Different behavior when stepping through code w/ pdb
Bugs item #1583276, was opened at 2006-10-24 00:54 Message generated for change (Comment added) made by jpe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&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.5 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Different behavior when stepping through code w/ pdb Initial Comment: The attached test case will raise a NameError when executed in pdb by stepping though the code. The issue is the EnumType name, which is both a local variable in the Enum function which is used in the lambda and the name of an attribute on the EnumValue class. Since it is a local variable used in a lambda, it's a freevar. What apparently happens is on line 5 the property() result is stored in frame->f_locals['EnumType'] but it is deleted the next time FastToLocals is invoked prior to calling back into the debugger. This happens when the freevars values are merged into the locals dictionary. The example is a stripped down version of code in turbogears. -- >Comment By: John Ehresman (jpe) Date: 2006-10-30 16:47 Message: Logged In: YES user_id=22785 It looks like a dup to me. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-30 16:41 Message: Logged In: YES user_id=341410 Sorry! What I meant to say is that this seems to be a duplicate of http://python.org/sf/1569356 . -- Comment By: John Ehresman (jpe) Date: 2006-10-30 16:15 Message: Logged In: YES user_id=22785 I'm a bit confused -- http://python.org/sf/1583276 seems to resolve to this bug. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-27 06:23 Message: Logged In: YES user_id=341410 This seems to be a duplicate of http://python.org/sf/1583276 . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583276&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Comment added) made by jpe
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
Private: No
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: 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.
--
[ python-Bugs-1586414 ] tarfile.extract() may cause file fragmentation on Windows XP
Bugs item #1586414, was opened at 2006-10-28 21:22 Message generated for change (Comment added) made by enochjul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&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 Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.extract() may cause file fragmentation on Windows XP Initial Comment: When I use tarfile.extract() to extract all the files from a large tar archive with lots of files tends to cause file fragmentation in Windows. Apparently NTFS cluster allocation interacts badly with such operations if Windows is not aware of the size of each file. The solution is to use a combination of the Win32 APIs SetFilePointer() and SetEndOfFile() before writing to the target file. This helps Windows choose a contiguous free space for the file. I tried it on the 2.6 trunk by calling file.truncate() (which seems to implement the appropriate calls on Windows) to set the file size before writing to a file. It helps to avoid fragmentation for the extracted files on my Windows XP x64 system. Can this be added to tarfile to improve its performance on Windows? -- >Comment By: Enoch Julias (enochjul) Date: 2006-10-31 05:07 Message: Logged In: YES user_id=6071 I submitted patch #1587674 for this, though I am not sure if it is a good idea to use truncate() for such a purpose. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-29 08:55 Message: Logged In: YES user_id=849994 Can you try to come up with a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1587679 ] scipy gammaincinv gives incorrect answers
Bugs item #1587679, was opened at 2006-10-31 05:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1587679&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 Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David J.C. MacKay (djcmackay) Assigned to: Nobody/Anonymous (nobody) Summary: scipy gammaincinv gives incorrect answers Initial Comment: For extreme values, gamaincinv gives the answer '0.0' when it should not do so. Examples: >>> import scipy.special as S >>> S.gammainc( 50 , 12.00 ) 2.3998794536786009e-16 >>> S.gammaincinv( 50 , 2.39e-16 ) 11.996909478523992 >>> S.gammainc( 50 , 11.00 ) 8.2075477738848345e-18 >>> S.gammaincinv( 50 , 8e-18 ) 0.0 Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 David [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1587679&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
