svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r78875 | victor.stinner | 2010-03-12 18:00:41 +0100 (ven., 12 mars 2010) | 5 lines
Issue #6697: use %U format instead of _PyUnicode_AsString(), because
_PyUnicode_AsString() was not checked for error (NULL).
The unicode string is no more truncated to 200 or 400 *bytes*.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r79205 | benjamin.peterson | 2010-03-21 12:34:54 -0500 (Sun, 21 Mar 2010) | 1 line
rewrite a bit
........
r79219 | benjamin.peterson | 2010-03-21 14:24:08 -0500 (Sun, 21 Mar 2010) | 1 line
flatten condition
........
r79228 | benjamin.peterson | 2010-03-21 14:35:39 -0500 (Sun, 21 Mar 2010) | 1 line
remove pointless condition
........
r79230 | benjamin.peterson | 2010-03-21 14:39:52 -0500 (Sun, 21 Mar 2010) | 1 line
co_varnames is certainly a tuple, so let's not waste time finding out
........
r79232 | benjamin.peterson | 2010-03-21 14:54:56 -0500 (Sun, 21 Mar 2010) | 1 line
fix import
........
r79233 | benjamin.peterson | 2010-03-21 14:56:37 -0500 (Sun, 21 Mar 2010) | 1 line
don't write duplicate tests
........
r79235 | benjamin.peterson | 2010-03-21 15:21:00 -0500 (Sun, 21 Mar 2010) | 4 lines
improve error message from passing inadequate number of keyword arguments #6474
Note this removes the "non-keyword" or "keyword" phrases from these messages.
........
r79237 | benjamin.peterson | 2010-03-21 15:30:30 -0500 (Sun, 21 Mar 2010) | 1 line
take into account keyword arguments when passing too many args
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78746 | benjamin.peterson | 2010-03-06 18:00:37 -0600 (Sat, 06 Mar 2010) | 1 line
more specific exception for wrong kind of raise #8082
........
In Python 2.x, exceptions in finally blocks are not normalized. Since with
statements are implemented using finally blocks, ceval.c had to be tweaked to
distinguish between with finally blocks and normal ones.
A test for the finalization of generators containing with statements was also
added.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76629 | mark.dickinson | 2009-12-02 17:33:41 +0000 (Wed, 02 Dec 2009) | 3 lines
Issue #7406: Fix some occurrences of potential signed overflow in int
arithmetic.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r75984 | mark.dickinson | 2009-10-31 10:18:44 +0000 (Sat, 31 Oct 2009) | 12 lines
Merged revisions 75982 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r75982 | mark.dickinson | 2009-10-31 10:11:28 +0000 (Sat, 31 Oct 2009) | 5 lines
Issue #6603: Fix --with-tsc build failures on x86-64 that resulted
from a gcc inline assembler peculiarity. (gcc's "A" constraint
apparently means 'rax or rdx' in 64-bit mode, not edx:eax
or rdx:rax as one might expect.)
........
................
svn+ssh://pythondev@svn.python.org/python/trunk
........
r75982 | mark.dickinson | 2009-10-31 10:11:28 +0000 (Sat, 31 Oct 2009) | 5 lines
Issue #6603: Fix --with-tsc build failures on x86-64 that resulted
from a gcc inline assembler peculiarity. (gcc's "A" constraint
apparently means 'rax or rdx' in 64-bit mode, not edx:eax
or rdx:rax as one might expect.)
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r75982 | mark.dickinson | 2009-10-31 10:11:28 +0000 (Sat, 31 Oct 2009) | 5 lines
Issue #6603: Fix --with-tsc build failures on x86-64 that resulted
from a gcc inline assembler peculiarity. (gcc's "A" constraint
apparently means 'rax or rdx' in 64-bit mode, not edx:eax
or rdx:rax as one might expect.)
........
from a gcc inline assembler peculiarity. (gcc's "A" constraint
apparently means 'rax or rdx' in 64-bit mode, not edx:eax
or rdx:rax as one might expect.)
svn+ssh://pythondev@svn.python.org/python/trunk
........
r73750 | benjamin.peterson | 2009-07-01 19:45:19 -0400 (Wed, 01 Jul 2009) | 1 line
small optimization: avoid popping the current block until we have to
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72487 | jeffrey.yasskin | 2009-05-08 17:51:06 -0400 (Fri, 08 May 2009) | 7 lines
PyCode_NewEmpty:
Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New
are trying to build an empty code object, usually to put it in a dummy frame
object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify
just the filename, function name, and first line number, instead of also
requiring lots of code internals.
........
r72488 | jeffrey.yasskin | 2009-05-08 18:23:21 -0400 (Fri, 08 May 2009) | 13 lines
Issue 5954, PyFrame_GetLineNumber:
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.
........
r72879 | jeffrey.yasskin | 2009-05-23 19:23:01 -0400 (Sat, 23 May 2009) | 14 lines
Issue #6042:
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r73614 | benjamin.peterson | 2009-06-28 11:08:02 -0500 (Sun, 28 Jun 2009) | 1 line
add two generic macros for peeking and setting in the stack
........
r73615 | benjamin.peterson | 2009-06-28 11:14:07 -0500 (Sun, 28 Jun 2009) | 1 line
use stack macros
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72912 | benjamin.peterson | 2009-05-25 08:13:44 -0500 (Mon, 25 May 2009) | 5 lines
add a SETUP_WITH opcode
It speeds up the with statement and correctly looks up the special
methods involved.
........
r72920 | benjamin.peterson | 2009-05-25 15:12:57 -0500 (Mon, 25 May 2009) | 1 line
take into account the fact that SETUP_WITH pushes a finally block
........
r72940 | benjamin.peterson | 2009-05-26 07:49:59 -0500 (Tue, 26 May 2009) | 1 line
teach the peepholer about SETUP_WITH
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r73064 | antoine.pitrou | 2009-05-30 23:27:00 +0200 (sam., 30 mai 2009) | 4 lines
Issue #5330: C functions called with keyword arguments were not reported by
the various profiling modules (profile, cProfile). Patch by Hagen Fürstenau.
........
r73065 | antoine.pitrou | 2009-05-30 23:39:25 +0200 (sam., 30 mai 2009) | 3 lines
The test for #5330 wasn't correct.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r73064 | antoine.pitrou | 2009-05-30 23:27:00 +0200 (sam., 30 mai 2009) | 4 lines
Issue #5330: C functions called with keyword arguments were not reported by
the various profiling modules (profile, cProfile). Patch by Hagen Fürstenau.
........
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
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.
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.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r69811 | collin.winter | 2009-02-20 13:30:41 -0600 (Fri, 20 Feb 2009) | 2 lines
Issue 5176: special-case string formatting in BINARY_MODULO implementation. This shows a modest (1-3%) speed-up in templating systems, for example.
........
r69947 | jeffrey.yasskin | 2009-02-24 16:48:34 -0600 (Tue, 24 Feb 2009) | 3 lines
Tools/scripts/analyze_dxp.py, a module with some helper functions to
analyze the output of sys.getdxp().
........
Antoine Pitrou
Benjamin Peterson
Victor Stinner
Alexandre Vassalotti
Mark Dickinson
Ezio Melotti
Jeffrey Yasskin