(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.
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.
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)
Objects/floatobject.c and Objects/complexobject.c. This should silence
compiler warnings about implicit declaration of the 'finite' function
on Solaris.
string <-> float conversions; this makes sure that the result of the round
operation is correctly rounded, and hence displays nicely using the new float
repr.
- add double endianness detection to configure script
- add configure-time check to see whether we can use inline
assembly to get and set x87 control word in configure script
- add functions to get and set x87 control word in Python/pymath.c
- add pyport.h logic to determine whether it's safe to use the
short float repr or not
Add the Python/dtoa.c file containing the main algorithms;
add corresponding include file and include in Python.h;
include license information for Python/dtoa.c;
add dtoa.c and dtoa.h to Makefile.
The debug memory api now keeps track of which external API (PyMem_* or PyObject_*) was used to allocate each block and treats any API violation as an error. Added separate _PyMem_DebugMalloc functions for the Py_Mem API instead of having it use the _PyObject_DebugMalloc functions.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r74841 | thomas.wouters | 2009-09-16 12:55:54 -0700 (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.
........
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.
in http://codereview.appspot.com/53094 and accepted by Guido.
The construct is transformed into multiple With AST nodes so that
there should be no problems with the semantics.
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.
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.
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.
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.
untrackable objects are not tracked by the garbage collector. This can
reduce the size of collections and therefore the garbage collection overhead
on long-running programs, depending on their particular use of datatypes.
(trivia: this makes the "binary_trees" benchmark from the Computer Language
Shootout 40% faster)
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.
and cleanups in Objects/longobject.c. The most significant change is that
longs now use less memory: average savings are 2 bytes per long on 32-bit
systems and 6 bytes per long on 64-bit systems. (This memory saving already
exists in py3k.)
svn+ssh://pythondev@svn.python.org/python/trunk
........
r68292 | skip.montanaro | 2009-01-04 11:36:58 +0100 (So, 04 Jan 2009) | 3 lines
If user configures --without-gcc give preference to $CC instead of blindly
assuming the compiler will be "cc".
........
r68344 | marc-andre.lemburg | 2009-01-05 20:43:35 +0100 (Mo, 05 Jan 2009) | 7 lines
Fix#4846 (Py_UNICODE_ISSPACE causes linker error) by moving the declaration
into the extern "C" section.
Add a few more comments and apply some minor edits to make the file contents
fit the original structure again.
........
r68361 | antoine.pitrou | 2009-01-06 19:34:08 +0100 (Di, 06 Jan 2009) | 3 lines
Use shutil.rmtree rather than os.rmdir.
........
r68378 | mark.dickinson | 2009-01-07 18:48:33 +0100 (Mi, 07 Jan 2009) | 2 lines
Issue #4869: clarify documentation for random.expovariate.
........
r68424 | benjamin.peterson | 2009-01-09 03:53:35 +0100 (Fr, 09 Jan 2009) | 1 line
specify what -3 warnings are about
........
r68426 | benjamin.peterson | 2009-01-09 04:03:05 +0100 (Fr, 09 Jan 2009) | 1 line
fix spelling
........
r68429 | benjamin.peterson | 2009-01-09 04:05:14 +0100 (Fr, 09 Jan 2009) | 1 line
add -3 to manpage
........
r68430 | benjamin.peterson | 2009-01-09 04:07:27 +0100 (Fr, 09 Jan 2009) | 1 line
be more specific in -3 option help
........
r68450 | jeffrey.yasskin | 2009-01-09 17:47:07 +0100 (Fr, 09 Jan 2009) | 3 lines
Fix issue 4884, preventing a crash in the socket code when python is compiled
with llvm-gcc and run with a glibc <2.10.
........
r68457 | kristjan.jonsson | 2009-01-09 21:10:59 +0100 (Fr, 09 Jan 2009) | 1 line
Issue 3677: Fix import from UNC paths on Windows.
........
r68480 | vinay.sajip | 2009-01-10 14:38:04 +0100 (Sa, 10 Jan 2009) | 1 line
Minor documentation changes cross-referencing NullHandler to the documentation on configuring logging in a library.
........
r68481 | vinay.sajip | 2009-01-10 14:42:04 +0100 (Sa, 10 Jan 2009) | 1 line
Corrected an incorrect self-reference.
........
r68493 | benjamin.peterson | 2009-01-10 18:18:55 +0100 (Sa, 10 Jan 2009) | 1 line
rewrite verbose conditionals
........
r68495 | benjamin.peterson | 2009-01-10 18:36:44 +0100 (Sa, 10 Jan 2009) | 1 line
tp_iter only exists with Py_TPFLAGS_HAVE_ITER #4901
........
r68499 | mark.dickinson | 2009-01-10 20:14:55 +0100 (Sa, 10 Jan 2009) | 2 lines
Remove an unnecessary check from test_decimal.
........
r68501 | vinay.sajip | 2009-01-10 20:22:57 +0100 (Sa, 10 Jan 2009) | 1 line
Corrected minor typo and added .currentmodule directives to fix missing cross-references.
........
r68512 | benjamin.peterson | 2009-01-10 23:42:10 +0100 (Sa, 10 Jan 2009) | 1 line
make tests fail if they can't be imported
........
r68514 | benjamin.peterson | 2009-01-11 00:41:59 +0100 (So, 11 Jan 2009) | 1 line
move seealso to a more appropiate place
........
r68515 | benjamin.peterson | 2009-01-11 00:49:08 +0100 (So, 11 Jan 2009) | 1 line
macos 9 isn't supported
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r66891 | amaury.forgeotdarc | 2008-10-14 23:47:22 +0200 (mar., 14 oct. 2008) | 5 lines
#4122: On Windows, Py_UNICODE_ISSPACE cannot be used in an extension module:
compilation fails with "undefined reference to _Py_ascii_whitespace"
Will backport to 2.6.
........
Part of source_os2emx.patch in issue 3868:
Include/pystrcmp.h: OS/2 has same C APIs as Windows
Lib/test/test_io.py: OS/2 has same behaviour as Windows for this test
Reviewed by Amaury Forgeot d'Arc
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.
was not always being done properly in some python types and extension
modules. PyMem_MALLOC, PyMem_REALLOC, PyMem_NEW and PyMem_RESIZE have
all been updated to perform better checks and places in the code that
would previously leak memory on the error path when such an allocation
failed have been fixed.
Some functions in the msvcrt module are skipped,
and socket.ioctl is enabled only when using a more recent Platform SDK.
(and yes, there are still companies that use a 10-years old compiler)
Added checks for integer overflows, contributed by Google. Some are
only available if asserts are left in the code, in cases where they
can't be triggered from Python code.
This patch adds a new configure argument on OSX:
--with-universal-archs=[32-bit|64-bit|all]
When used with the --enable-universalsdk option this controls which
CPU architectures are includes in the framework. The default is 32-bit,
meaning i386 and ppc. The most useful alternative is 'all', which includes
all 4 CPU architectures supported by MacOS X (i386, ppc, x86_64 and ppc64).
This includes limited support for the Carbon bindings in 64-bit mode as well,
limited because (a) I haven't done extensive testing and (b) a large portion
of the Carbon API's aren't available in 64-bit mode anyway.
I've also duplicated a feature of Apple's build of python: setting the
environment variable 'ARCHFLAGS' controls the '-arch' flags used for building
extensions using distutils.
renamed Include/bytesobject.h to Include/bytearrayobject.h
renamed Include/stringobject.h to Include/bytesobject.h
added Include/stringobject.h with aliases
Adds 'n' as a format specifier for integers, to mirror the same
specifier which is already available for floats. 'n' is the same as
'd', but inserts the current locale-specific thousands grouping.
I added this as a stringlib function, but it's only used by str type,
not unicode. This is because of an implementation detail in
unicode.format(), which does its own str->unicode conversion. But the
unicode version will be needed in 3.0, and it may be needed by other
code eventually in 2.6 (maybe decimal?), so I left it as a stringlib
implementation. As long as the unicode version isn't instantiated,
there's no overhead for this.