object to Py_FileSystemDefaultEncoding with the "surrogateescape" error
handler, return a bytes object. If Py_FileSystemDefaultEncoding is not set,
fall back to UTF-8.
* Add paragraph titles to c-api/unicode.rst.
* Fix PyUnicode_DecodeFSDefault*() comment: it now uses the "surrogateescape"
error handler (and not "replace")
* Remove "The function is intended to be used for paths and file names only
during bootstrapping process where the codecs are not set up." from
PyUnicode_FSConverter() comment: it is used after the bootstrapping and for
other purposes than file names
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.
This fixes issue #8441: python.c is not included
in the framework while main.c is and without this
patch you get a link error when building
Python.framework on OSX.
module now takes an optional timeout argument in seconds. Timeout support
relies on the system threading library, so as to avoid a semi-busy wait
loop.
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
........
r79060 | collin.winter | 2010-03-18 14:54:01 -0700 (Thu, 18 Mar 2010) | 4 lines
Add support for weak references to code objects. This will be used by an optimization in the incoming Python 3 JIT.
Patch by Reid Kleckner!
........
POSIX systems with a C extension module. This is required in order for
the subprocess module to be made thread safe.
The pure python implementation is retained so that it can continue to be
used if for some reason the _posixsubprocess extension module is not
available.
The unittest executes tests on both code paths to guarantee compatibility.
* Moves PyLong_FromPid and PyLong_AsPid from posixmodule.c into longobject.h.
Code reviewed by jeffrey.yasskin at http://codereview.appspot.com/223077/show
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78393 | amaury.forgeotdarc | 2010-02-24 00:19:39 +0100 (mer., 24 févr. 2010) | 2 lines
#4852: Remove dead code in every thread implementation, unused for many years.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78189 | mark.dickinson | 2010-02-14 13:40:30 +0000 (Sun, 14 Feb 2010) | 1 line
Silence more 'comparison between signed and unsigned' warnings.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77842 | mark.dickinson | 2010-01-30 10:08:33 +0000 (Sat, 30 Jan 2010) | 4 lines
Issue #7767: Add new C-API function PyLong_AsLongLongAndOverflow, a
long long variant of PyLong_AsLongAndOverflow. Patch by Case Van
Horsen.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77573 | antoine.pitrou | 2010-01-17 13:26:20 +0100 (dim., 17 janv. 2010) | 6 lines
Issue #7561: Operations on empty bytearrays (such as `int(bytearray())`)
could crash in many places because of the PyByteArray_AS_STRING() macro
returning NULL. The macro now returns a statically allocated empty
string instead.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77234 | mark.dickinson | 2010-01-02 14:45:40 +0000 (Sat, 02 Jan 2010) | 7 lines
Refactor some longobject internals: PyLong_AsDouble and _PyLong_AsScaledDouble
(the latter renamed to _PyLong_Frexp) now use the same core code. The
exponent produced by _PyLong_Frexp now has type Py_ssize_t instead of the
previously used int, and no longer needs scaling by PyLong_SHIFT. This
frees the math module from having to know anything about the PyLong
implementation. This closes issue #5576.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77088 | georg.brandl | 2009-12-28 09:34:58 +0100 (Mo, 28 Dez 2009) | 1 line
#7033: add new API function PyErr_NewExceptionWithDoc, for easily giving new exceptions a docstring.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76822 | benjamin.peterson | 2009-12-13 15:21:43 -0600 (Sun, 13 Dec 2009) | 1 line
initialize to NULL
........
r76824 | benjamin.peterson | 2009-12-13 15:27:53 -0600 (Sun, 13 Dec 2009) | 1 line
add a test of loading the datetime capi
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76740 | mark.dickinson | 2009-12-10 10:36:32 +0000 (Thu, 10 Dec 2009) | 8 lines
Replace the size check for PyMem_MALLOC and PyMem_REALLOC with an almost
equivalent[*] check that doesn't produce compiler warnings about a 'x < 0'
check on an unsigned type.
[*] it's equivalent for inputs of type size_t or Py_ssize_t, or any smaller
unsigned or signed integer type.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76712 | ronald.oussoren | 2009-12-08 17:32:52 +0100 (Tue, 08 Dec 2009) | 4 lines
Fix for issue 7452: HAVE_GCC_ASM_FOR_X87 gets set when doing a universal build on
an i386 based machine, but should only be active when compiling the x86 part of
the universal binary.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76623 | ronald.oussoren | 2009-12-01 16:54:01 +0100 (Tue, 01 Dec 2009) | 9 lines
Fix for issue #7416: SIZEOF_UINTPTR_T can be invalid when configuring a
multi-architecture build (in particular when the architectures don't share
a common pointer size).
Fixed the same issue for SIZEOF_PTHREAD_T.
(No update to the NEWS file because this is a bugfix for an as yet unreleased
feature)
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r76561 | mark.dickinson | 2009-11-28 12:30:36 +0000 (Sat, 28 Nov 2009) | 5 lines
Include ieeefp.h (when available) in pyport.h instead of individually in
Objects/floatobject.c and Objects/complexobject.c. This should silence
compiler warnings about implicit declaration of the 'finite' function
on Solaris.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74841 | thomas.wouters | 2009-09-16 14:55:54 -0500 (Wed, 16 Sep 2009) | 23 lines
Fix issue #1590864, multiple threads and fork() can cause deadlocks, by
acquiring the import lock around fork() calls. This prevents other threads
from having that lock while the fork happens, and is the recommended way of
dealing with such issues. There are two other locks we care about, the GIL
and the Thread Local Storage lock. The GIL is obviously held when calling
Python functions like os.fork(), and the TLS lock is explicitly reallocated
instead, while also deleting now-orphaned TLS data.
This only fixes calls to os.fork(), not extension modules or embedding
programs calling C's fork() directly. Solving that requires a new set of API
functions, and possibly a rewrite of the Python/thread_*.c mess. Add a
warning explaining the problem to the documentation in the mean time.
This also changes behaviour a little on AIX. Before, AIX (but only AIX) was
getting the import lock reallocated, seemingly to avoid this very same
problem. This is not the right approach, because the import lock is a
re-entrant one, and reallocating would do the wrong thing when forking while
holding the import lock.
Will backport to 2.6, minus the tiny AIX behaviour change.
........
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.
........