GitLab

namespace if it occurs as a free variable in a nested block.  This limitation
of the compiler has been lifted, and a new opcode introduced (DELETE_DEREF).

This sample was valid in 2.6, but fails to compile in 3.x without this change::

   >>> def f():
   ...     def print_error():
   ...        print(e)
   ...     try:
   ...        something
   ...     except Exception as e:
   ...        print_error()
   ...        # implicit "del e" here


This sample has always been invalid in Python, and now works::

   >>> def outer(x):
   ...     def inner():
   ...        return x
   ...     inner()
   ...     del x

There is no need to bump the PYC magic number: the new opcode is used
for code that did not compile before.

by the new (and simpler) DUP_TOP_TWO.  Performance isn't changed, but
our bytecode is a bit simplified.  Patch by Demur Rumed.

_PyUnicode_AsString() raises an exception on unencodable filename.

compilers (which are detected by the configure script).  They can still
be disable selectively by specifying --without-computed-gotos.

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r81029 | antoine.pitrou | 2010-05-09 16:46:46 +0200 (dim., 09 mai 2010) | 3 lines

  Untabify C files. Will watch buildbots.
........

http://code.google.com/p/data-race-test/wiki/ThreadSanitizer is a dynamic data
race detector that runs on top of valgrind. With this patch, the binaries at
http://code.google.com/p/data-race-test/wiki/ThreadSanitizer#Binaries pass many
but not all of the Python tests. All of regrtest still passes outside of tsan.

I've implemented part of the C1x atomic types so that we can explicitly mark
variables that are used across threads, and get defined behavior as compilers
advance.

I've added tsan's client header and implementation to the codebase in
dynamic_annotations.{h,c} (docs at
http://code.google.com/p/data-race-test/wiki/DynamicAnnotations).
Unfortunately, I haven't been able to get helgrind and drd to give sensible
error messages, even when I use their client annotations, so I'm not supporting
them.

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r79555 | antoine.pitrou | 2010-04-01 18:42:11 +0200 (jeu., 01 avril 2010) | 5 lines

  Issue #8276: PyEval_CallObject() is now only available in macro form.  The
  function declaration, which was kept for backwards compatibility reasons,
  is now removed (the macro was introduced in 1997!).
........

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r78028 | benjamin.peterson | 2010-02-06 13:40:18 -0600 (Sat, 06 Feb 2010) | 1 line

  remove pointless error checking
........

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
........

_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

........
  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

........
  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.
........

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().
........

This patch by Antoine Pitrou optimizes the bytecode for conditional branches by
merging the following "POP_TOP" instruction into the conditional jump.  For
example, the list comprehension "[x for x in l if not x]" produced the
following bytecode:

  1           0 BUILD_LIST               0
              3 LOAD_FAST                0 (.0)
        >>    6 FOR_ITER                23 (to 32)
              9 STORE_FAST               1 (x)
             12 LOAD_FAST                1 (x)
             15 JUMP_IF_TRUE            10 (to 28)
             18 POP_TOP
             19 LOAD_FAST                1 (x)
             22 LIST_APPEND              2
             25 JUMP_ABSOLUTE            6
        >>   28 POP_TOP
             29 JUMP_ABSOLUTE            6
        >>   32 RETURN_VALUE

but after the patch it produces the following bytecode:

  1           0 BUILD_LIST               0
              3 LOAD_FAST                0 (.0)
        >>    6 FOR_ITER                18 (to 27)
              9 STORE_FAST               1 (x)
             12 LOAD_FAST                1 (x)
             15 POP_JUMP_IF_TRUE         6
             18 LOAD_FAST                1 (x)
             21 LIST_APPEND              2
             24 JUMP_ABSOLUTE            6
        >>   27 RETURN_VALUE

Notice that not only the code is shorter, but the conditional jump
(POP_JUMP_IF_TRUE) jumps right to the start of the loop instead of going through
the JUMP_ABSOLUTE at the end. "continue" statements are helped
similarly.

Furthermore, the old jump opcodes (JUMP_IF_FALSE, JUMP_IF_TRUE) have been
replaced by two new opcodes:
- JUMP_IF_TRUE_OR_POP, which jumps if true and pops otherwise
- JUMP_IF_FALSE_OR_POP, which jumps if false and pops otherwise

on compilers that support it (notably: gcc, SunPro, icc), the bytecode
evaluation loop is compiled with a new dispatch mechanism which gives
speedups of up to 20%, depending on the system, on various benchmarks.