Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
If anyone wants to clean up the documentation, feel free. It's my first documentation foray, and it's not that great.
Will port to py3k with a different strategy.
- simplify parsing and printing of complex numbers
- make complex(repr(z)) round-tripping work for complex
numbers involving nans, infs, or negative zeros
- don't accept some of the stranger complex strings
that were previously allowed---e.g., complex('1..1j')
int, long, and float __format__(), and it keeps their implementation
in sync with py3k.
Also added PyOS_double_to_string. This is the "fallback" version
that's also available in trunk, and should be kept in sync with that
code. I'll add an issue to document PyOS_double_to_string in the C
API.
There are many internal cleanups. Externally visible changes include:
- Implement PEP 378, Format Specifier for Thousands Separator, for
floats, ints, and longs.
- Issue #5515: 'n' formatting for ints, longs, and floats handles
leading zero formatting poorly.
- Issue #5772: For float.__format__, don't add a trailing ".0" if
we're using no type code and we have an exponent.
Re http://bugs.python.org/issue4315
The symbol table used the same name dictionaries to recursively
analyze each of its child blocks, even though the dictionaries are
modified during analysis. The fix is to create new temporary
dictionaries via the analyze_child_block(). The only information that
needs to propagate back up is the names of the free variables.
Add more comments and break out a helper function. This code doesn't
get any easier to understand when you only look at it once a year.
POP_JUMP_IF_{TRUE,FALSE} and JUMP_IF_{TRUE,FALSE}_OR_POP. This avoids executing
a POP_TOP on each conditional and sometimes allows the peephole optimizer to
skip a JUMP_ABSOLUTE entirely. It speeds up list comprehensions significantly.
an existing .py counterpart, override the co_filename attributes of all
code objects if the original filename is obsolete (which can happen if the
file has been renamed, moved, or if it is accessed through different paths).
Patch by Ziga Seilnacht and Jean-Paul Calderone.
PyString_FromFormat which has an independent implementation, and uses "%zd".
This makes a difference on win64, where printf needs "%Id" to display
64bit values. For example, queue.__repr__ was incorrect.
Reviewed by Martin von Loewis.
catch_warnings(), and clean up the API.
While expanding the test suite, a bug was found where a warning about the
'line' argument to showwarning() was not letting functions with '*args' go
without a warning.
Closes issue 3602.
Code review by Benjamin Peterson.
exception afterwards (for a subsequent parameter), the user code will
not call PyBuffer_Release() and memory will leak.
Reviewed by Amaury Forgeot d'Arc.
match Python 2.5 speed despite the __instancecheck__ / __subclasscheck__
mechanism. In the process, fix a bug where isinstance() and issubclass(),
when given a tuple of classes as second argument, were looking up
__instancecheck__ / __subclasscheck__ on the tuple rather than on each
type object.
Reviewed by Benjamin Peterson and Raymond Hettinger.
* crashes on memory allocation failure found with failmalloc
* memory leaks found with valgrind
* compiler warnings in opt mode which would lead to invalid memory reads
* problem using wrong name in decimal module reported by pychecker
Update the valgrind suppressions file with new leaks that are small/one-time
leaks we don't care about (ie, they are too hard to fix).
TBR=barry
TESTED=./python -E -tt ./Lib/test/regrtest.py -uall (both debug and opt modes)
in opt mode:
valgrind -q --leak-check=yes --suppressions=Misc/valgrind-python.supp \
./python -E -tt ./Lib/test/regrtest.py -uall,-bsddb,-compiler \
-x test_logging test_ssl test_multiprocessing
valgrind -q --leak-check=yes --suppressions=Misc/valgrind-python.supp \
./python -E -tt ./Lib/test/regrtest.py test_multiprocessing
for i in `seq 1 4000` ; do
LD_PRELOAD=~/local/lib/libfailmalloc.so FAILMALLOC_INTERVAL=$i \
./python -c pass
done
At least some of these fixes should probably be backported to 2.5.
key list data structure in the thread startup path.
This change is a companion to r60148 which already successfully dealt with a
similar issue on thread shutdown.
In particular this loop has been observed happening from this call path:
#0 in find_key ()
#1 in PyThread_set_key_value ()
#2 in _PyGILState_NoteThreadState ()
#3 in PyThreadState_New ()
#4 in t_bootstrap ()
#5 in pthread_start_thread ()
I don't know how this happens but it does, *very* rarely. On more than
one hardware platform. I have not been able to reproduce it manually.
(A flaky mutex implementation on the system in question is one hypothesis).
As with r60148, the spinning we managed to observe in the wild was due to a
single list element pointing back upon itself.
Benjamin Peterson
Hirokazu Yamamoto
R. David Murray
Jeffrey Yasskin
Eric Smith
Mark Dickinson
Georg Brandl
Matthias Klose
Antoine Pitrou
Brett Cannon
Jesse Noller
Jeremy Hylton
Nick Coghlan
Collin Winter
Raymond Hettinger
Mark Hammond
Amaury Forgeot d'Arc
Martin v. Löwis
Kristján Valur Jónsson
Armin Ronacher
Christian Heimes
Andrew MacIntyre
Neal Norwitz
Gregory P. Smith