[ python-Bugs-1764286 ] inspect.getsource does not work with decorated functions
Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-SourceForge-Tracker-unixname: python X-SourceForge-Tracker-trackerid: 105470 X-SourceForge-Tracker-itemid: 1764286 X-SourceForge-Tracker-itemstatus: Open X-SourceForge-Tracker-itemassignee: nobody X-SourceForge-Tracker-itemupdate-reason: Tracker Item Submitted X-SourceForge-Tracker-itemupdate-username: Item Submitter Bugs item #1764286, was opened at 2007-07-31 06:16 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=1764286&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michele Simionato (michele_s) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource does not work with decorated functions Initial Comment: Here is the issue: $ cat example.py import functools # I am using Python 2.5 def identity_dec(func): def wrapper(*args, **kw): return func(*args, **kw) return functools.update_wrapper(wrapper, func) @identity_dec def example(): pass >>> import inspect >>> from example import example >>> print inspect.getsource(example) def wrapper(*args, **kw): return func(*args, **kw) You get the source code of the closure and not what would be more meaningful, i.e. the string """ @identity_dec def example(): pass """ Of course one could argue that this is not a bug (in a sense the inspect module is doing the right thing) but still it is giving information which is not very useful. Looking at the guts of inspect.getsource, one discovers the origin of the problem: inspect.findsource is looking at the attribute .co_firstlineno of the decorated function code object. Unfortunately .co_firstlineno is a read-only attribute, otherwise it would be possibile to change functools.update_wrapper to set it to the correct line number (i.e. the line where the undecorated function is defined, -1). So I don't think you can fix this in current Python, but it is something to keep in mind for Python 2.6 and 3.0. It should also manage classmethods/ staticmethods and other decorators not implemented as closures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764286&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1764407 ] The -m switch does not use the builtin __main__ module
Bugs item #1764407, was opened at 2007-07-31 22:43 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=1764407&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nick Coghlan (ncoghlan) Summary: The -m switch does not use the builtin __main__ module Initial Comment: The -m switch creates a new module object to execute the requested module, and then throws it away before returning control to the interpreter core. This is incompatible with the -i command line switch (and its environment variable equivalent), and would also cause problems if any code executed while looking for the module to be executed (e.g. sitecustomize.py or package __init__ modules) grabbed a reference to the original __main__ module. (Creating bug report because I don't think the quick fix I checked in to SVN is adequate, and it's taking me longer than I planned to roll the quick fix back and fix the problem properly) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764407&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1746071 ] class mutex doesn't do anything atomically
Bugs item #1746071, was opened at 2007-07-02 00:49 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1746071&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Benbennick (dbenbenn) Assigned to: Nobody/Anonymous (nobody) Summary: class mutex doesn't do anything atomically Initial Comment: >>> import mutex >>> print mutex.mutex.testandset.__doc__ Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded. The above docstring is wrong: the method is not atomic. This is easy to see by inspecting the method's code: def testandset(self): """Atomic test-and-set -- grab the lock if it is not set, return True if it succeeded.""" if not self.locked: self.locked = 1 return True else: return False Therefore, it is possible for two threads to lock the same mutex simultaneously. So the mutex module cannot be used for mutual exclusion. The documentation for mutex says "The mutex module defines a class that allows mutual-exclusion via acquiring and releasing locks." [http://docs.python.org/lib/module-mutex.html]. Perhaps it would be a good idea to make the module actually do what the documentation says. -- >Comment By: Nick Coghlan (ncoghlan) Date: 2007-07-31 23:18 Message: Logged In: YES user_id=1038590 Originator: NO The docs may be misleading - they're missing a key comment from the source code that suggests that this particular mutex is specifically for use with the single threaded event scheduler in the sched module. On the other hand, the module predates the thread module by more than a year, and the threading module by about 7 years, so it may simply have failed to keep up with the times. The module as written definitely isn't thread-safe though (I suspect the question of whether or not it should be hasn't really come up before, as most new code just uses threading.Lock or threading.RLock for all its mutex needs). Either the code needs to change or the docs - this question would probably be best asked on python-dev (referencing this bug report). -- Comment By: David Benbennick (dbenbenn) Date: 2007-07-04 07:26 Message: Logged In: YES user_id=95581 Originator: YES I've attached a patch to mutex.py that fixes the bug by acquiring a lock in testandset() and unlock(). After you apply the patch, the previous attachment will run forever. File Added: patch.txt -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-04 05:36 Message: Logged In: YES user_id=942711 Originator: NO Thanks David, there is something 'interesting' being observed here. At a point: Calling testandset in thread 1, m.locked is False Calling testandset in thread 0, m.locked is False Thread 0 locked Resetting, trying again Another place: Calling testandset in thread 1, m.locked is False Calling testandset in thread 0, m.locked is False Thread 0 locked Thread 1 locked Hah, all these threads locked at the same time: [0, 1] My doubts are still with threading, but am unable to derive anything. Should someone more experienced look into? Or mind taking this for suggestions to c.l.p? -- Comment By: David Benbennick (dbenbenn) Date: 2007-07-02 19:23 Message: Logged In: YES user_id=95581 Originator: YES > How are you using mutex with threads, can you please provide some information. I'm attaching an example program that demonstrates two threads both locking the same mutex at the same time. > If muobj is an instance of mutex class. > muobj.testandset() for process-a will set the lock. > muobj.testandset() for process-b will be dealt with self.lock = True and > wont be able to set. That isn't correct. It is possible for testandset to return True in both thread-a and thread-b. What can happen is the following: 1) Thread a calls testandset(). It executes the line "if not self.locked", and finds the result to be True. 2) The OS switches threads. 3) Thread b calls testandset(). It executes the line "if not self.locked", and finds the result to be True. 4) Thread b sets "self.locked = 1" and returns True 5) Thread a sets "self.locked = 1" and returns True File Added: ex.py -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-07-02 13:10 Message: Logged In: YES user_id=942711 Originator: NO Hi David, I just fired
[ python-Bugs-1764059 ] _RLock.__repr__ throws exception
Bugs item #1764059, was opened at 2007-07-31 08:06
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764059&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: Threads
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: _RLock.__repr__ throws exception
Initial Comment:
I rewrote the test code in threading.py
to exercise it a bit more completely,
and found the following exception.
I think it arises because of a race
condition. Ownership probably changes
in the interval between the two
parts of the "and" on line 90.
Exception in thread gtp0:
Traceback (most recent call last):
File "/tmp/threading.py", line 460, in __bootstrap
self.run()
File "/tmp/threading.py", line 440, in run
self.__target(*self.__args, **self.__kwargs)
File "g_threading.py", line 107, in __a_thread
self.sclock.wait()
File "/tmp/threading.py", line 216, in wait
self._note("%s.wait(): got it", self)
File "/tmp/threading.py", line 46, in _note
format = format % args
File "/tmp/threading.py", line 189, in __repr__
return "" % (self.__lock, len(self.__waiters))
File "/tmp/threading.py", line 90, in __repr__
self.__owner and self.__owner.getName(),
AttributeError: 'NoneType' object has no attribute 'getName'
This was python 2.5.1, running on this:
$ uname -a
Linux chives 2.6.11.4-21.15-smp #1 SMP Tue Nov 28 13:39:58 UTC 2006 x86_64
x86_64 x86_64 GNU/Linux
$
I attach a patch to threading.py that exhibits
the bug (i.e. better testing code).
--
>Comment By: Nick Coghlan (ncoghlan)
Date: 2007-07-31 23:46
Message:
Logged In: YES
user_id=1038590
Originator: NO
The race condition should be fixed in rev 56633 in Subversion. I didn't
check in the test code changes, because they don't appear to actually
exercise the affected code path (there is no code to call repr() on the
RLock).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764059&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1764059 ] _RLock.__repr__ throws exception
Bugs item #1764059, was opened at 2007-07-30 22:06
Message generated for change (Comment added) made by gpk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764059&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: Threads
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: _RLock.__repr__ throws exception
Initial Comment:
I rewrote the test code in threading.py
to exercise it a bit more completely,
and found the following exception.
I think it arises because of a race
condition. Ownership probably changes
in the interval between the two
parts of the "and" on line 90.
Exception in thread gtp0:
Traceback (most recent call last):
File "/tmp/threading.py", line 460, in __bootstrap
self.run()
File "/tmp/threading.py", line 440, in run
self.__target(*self.__args, **self.__kwargs)
File "g_threading.py", line 107, in __a_thread
self.sclock.wait()
File "/tmp/threading.py", line 216, in wait
self._note("%s.wait(): got it", self)
File "/tmp/threading.py", line 46, in _note
format = format % args
File "/tmp/threading.py", line 189, in __repr__
return "" % (self.__lock, len(self.__waiters))
File "/tmp/threading.py", line 90, in __repr__
self.__owner and self.__owner.getName(),
AttributeError: 'NoneType' object has no attribute 'getName'
This was python 2.5.1, running on this:
$ uname -a
Linux chives 2.6.11.4-21.15-smp #1 SMP Tue Nov 28 13:39:58 UTC 2006 x86_64
x86_64 x86_64 GNU/Linux
$
I attach a patch to threading.py that exhibits
the bug (i.e. better testing code).
--
>Comment By: Greg Kochanski (gpk)
Date: 2007-07-31 13:53
Message:
Logged In: YES
user_id=6290
Originator: YES
__repr__ gets called in obscure and complicated ways
when _VERBOSE gets set. This happens when you run
threading.py as a script, rather than loading it as a
module. Trust me: __repr__ got called.
I can tell because the exception says so.
The important feature of the test code is that it
calls sys.setcheckinterval() with various arguments.
All good threading tests should do so: it allows
the test to explore many more potential race conditions.
Python, by default, checks for a thread switch every 10 or
100 instructions. Consequently, it could go entirely through
a critical section between thread switches.Instead,
if you call sys.setcheckinterval() with various arguments
like 1, 2, 3, 5, ... 100, ... you arrange for the thread
switches to happen in all different places. This will reveal
many more bugs, if you have them.
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2007-07-31 13:46
Message:
Logged In: YES
user_id=1038590
Originator: NO
The race condition should be fixed in rev 56633 in Subversion. I didn't
check in the test code changes, because they don't appear to actually
exercise the affected code path (there is no code to call repr() on the
RLock).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764059&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1764638 ] add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP
Feature Requests item #1764638, was opened at 2007-07-31 17:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&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: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Pogonyshev (doublep)
Assigned to: Nobody/Anonymous (nobody)
Summary: add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP
Initial Comment:
In disassembled code of Python functions I often see stuff like this:
421 JUMP_IF_FALSE 14 (to 438)
424 POP_TOP
1178...
435 JUMP_FORWARD 1 (to 439)
>> 438 POP_TOP
>> 439 END_FINALLY
Note how both branches of execution after JUMP_IF_FALSE do POP_TOP. This
causes the true-branch add JUMP_FORWARD, the only purpose of which is to bypass
the POP_TOP command.
I propose adding two new bytecodes, JUMP_IF_FALSE_AND_POP and
JUMP_IF_TRUE_AND_POP. Their semantics would be the same as that of existing
JUMP_IF_FALSE/JUMP_IF_TRUE except the commands would also pop the stack once,
after checking whether to jump. This would simplify the above code to just
421 JUMP_IF_FALSE_AND_POP 14 (to 438)
1178...
>> 438 END_FINALLY
This shortens bytecode by 5 bytes and both execution branches, by 1 and 2
commands correspondingly.
I'm willing to create a patch, if this sounds like a worthwile improvement.
Maybe it is better to skip 2.6 and target it for 3000 instead.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers
Bugs item #1750076, was opened at 2007-07-09 09:24 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&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: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Lasher (gotgenes) >Assigned to: Neal Norwitz (nnorwitz) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. -- >Comment By: Nick Coghlan (ncoghlan) Date: 2007-08-01 00:48 Message: Logged In: YES user_id=1038590 Originator: NO It's a genuine bug in the AST compiler - there are some workarounds in compile.c to make sure a for loop gets visited properly in the debugger, but there is no equivalent for while loops at this stage. I've had a quick look, but wasn't able to apply the same trick to while loops - hopefully Neal will have some insight into the matter. -- Comment By: Nir (nir1408) Date: 2007-07-24 22:01 Message: Logged In: YES user_id=933518 Originator: NO Hi Chris, I have done some digging and it seems the problem is rooted in the way co_lnotab is constructed for code objects (http://docs.python.org/ref/types.html#l2h-139). Consider for example the following code: > line 0: def loop(): > line 1:while True: > line 2:pass Both Python 2.4 and Python 2.5 emit the same disassembly for that code (using dis.dis()) : > 10 SETUP_LOOP 12 (to 15) > >>3 LOAD_GLOBAL 0 (True) > 6 JUMP_IF_FALSE4 (to 13) > 9 POP_TOP > > 2 10 JUMP_ABSOLUTE3 > >> 13 POP_TOP > 14 POP_BLOCK > >> 15 LOAD_CONST 0 (None) > 18 RETURN_VALUE However there is a difference with the co_lnotab structure between the versions. Python 2.4 emits the following offsets: > byte code offsets: [0, 3, 7] > source code offsets: [1, 0, 1] Python 2.5 emits the following offsets for the same code: > byte code offsets: [0, 10] > source code offsets: [1, 1] Note: The above output was generated with the following code: > print 'byte code offsets: ', [ord(x) for x in > loop.func_code.co_lnotab[::2]] > print 'source code offsets:', [ord(x) for x in > loop.func_code.co_lnotab[1::2]] So, what happens is that in offset 10, the while loop jumps back with JUMP_ABSOLUTE 3, but in Python 2.5 that offset is missing from the byte code offsets in co_lnotab. Python considers only offsets that appear in that structure for the purpose of tracing, and therefore that line (source line number 1) is skipped when jumped back to in Python 2.5 co_lnotab is constructed in compile.c but since that file was changed considerably between Python 2.4 and Python 2.5 I did not try to pinpoint the source of difference. In addition I do not know the motivation of this difference. It could be a mere bug, but it can also be by design, meaning that simply reverting the co_lnotab construction behavior back might break Python 2.5 elsewhere. Cheers, Nir -- Comment By: Chris Lasher (gotgenes) Date: 2007-07-09 09:37 Message: Logged In: YES user_id=1180453 Originator: YES Notice how in Python 2.4, the breakpoint is honored through each iteration through the while loop. -- [EMAIL PROTECTED]:~/development/playground$ python2.4 -m pdb simple.py > /home/chris/development/playground/simple.py(3)?() -> a = 10 (Pdb) b 5 Breakpoint 1 at /home/chris/development/playground/simple.py:5 (Pdb) l 1 #!/usr/bin/env python 2 3 -> a = 10 4 5 B while a > 0: 6 a -= 1 # how do I check the value of a at end of last iter.? 7 8 print "Fin!" [EOF] (Pdb) r > /home/chris/development/playground/simple.py(5)?() -> while a > 0: (Pdb) p a 10 (Pdb) r > /home/chris/development/playground/simple.py(5)?() -> while a > 0: (Pdb) p a 9 (Pdb) r > /home/chris/development/playground/simple.py(5)?() -
[ python-Bugs-1764761 ] Decimal comparison with None fails in Windows
Bugs item #1764761, was opened at 2007-07-31 13:34
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=1764761&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: pablohoffman.com (pablohoffman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Decimal comparison with None fails in Windows
Initial Comment:
The version used to test this was:
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
In Linux:
>>> from decimal import Decimal
>>> Decimal('1') < None
False
>>>
In Windows:
>>> from decimal import Decimal
>>> Decimal('1') < None
True
>>>
This is probably a Windows bug since both platforms do:
>>> 1 < None
False
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1764761&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
