_Py_char2wchar() callers usually need the result size in characters. Since it's
trivial to compute it in _Py_char2wchar() (O(1) whereas wcslen() is O(n)), add
an option to get it.
* PyUnicode_EncodeFSDefault(), PyUnicode_DecodeFSDefaultAndSize() and
PyUnicode_DecodeFSDefault() use the locale encoding instead of UTF-8 if
Py_FileSystemDefaultEncoding is NULL
* redecode_filenames() functions and _Py_code_object_list (issue #9630)
are no more needed: remove them
* Don't define _Py_wstat() on Windows, Windows has its own _wstat() function
with a different API (the stat buffer has another type)
* Include windows.h
* _Py_fopen() and _Py_stat() come from Python/import.c
* (_Py)_wrealpath() comes from Python/sysmodule.c
* _Py_char2wchar(), _Py_wchar2char() and _Py_wfopen() come from Modules/main.c
* (_Py)_wstat(), (_Py)_wgetcwd(), _Py_wreadlink() come from Modules/getpath.c
Redecode the filenames of:
- all modules: __file__ and __path__ attributes
- all code objects: co_filename attribute
- sys.path
- sys.meta_path
- sys.executable
- sys.path_importer_cache (keys)
Keep weak references to all code objects until initfsencoding() is called, to
be able to redecode co_filename attribute of all code objects.
retry the select() loop instead of bailing out. This is because select()
can incorrectly report a socket as ready for reading (for example, if it
received some data with an invalid checksum).
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84810 | daniel.stutzbach | 2010-09-14 11:02:01 -0500 (Tue, 14 Sep 2010) | 1 line
Remove pointers to a FAQ entry that no longer exists. Incorporate some text from the old FAQ into the docs
........
environment variable to set the filesystem encoding at Python startup.
sys.setfilesystemencoding() creates inconsistencies because it is unable to
reencode all filenames in all objects.
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.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r84347 | antoine.pitrou | 2010-08-28 22:42:55 +0200 (sam., 28 août 2010) | 5 lines
Issue #4835: make PyLong_FromSocket_t() and PyLong_AsSocket_t() private
to the socket module, and fix the width of socket descriptors to be
correctly detected under 64-bit Windows.
........
Database (Py_UNICODE_TOLOWER, Py_UNICODE_ISDECIMAL, and others) now accept
and return characters from the full Unicode range (Py_UCS4).
The differences from Python code are few:
- unicodedata.numeric(), unicodedata.decimal() and unicodedata.digit()
now return the correct value for large code points
- repr() may consider more characters as printable.
... to get the filename as a unicode object, instead of a byte string. Function
needed to support unencodable filenames. Deprecate PyModule_GetFilename() in
favor on the new function.
Call _wfopen() on Windows, or fopen() otherwise. Return the new file object on
success, or NULL if the file cannot be open or (if PyErr_Occurred()) on unicode
error.
It's a ParseTuple converter: decode bytes objects to unicode using
PyUnicode_DecodeFSDefaultAndSize(); str objects are output as-is.
* Don't specify surrogateescape error handler in the comments nor the
documentation, but PyUnicode_DecodeFSDefaultAndSize() and
PyUnicode_EncodeFSDefault() because these functions use strict error handler
for the mbcs encoding (on Windows).
* Remove PyUnicode_FSConverter() comment in unicodeobject.c to avoid
inconsistency with unicodeobject.h.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r82966 | stefan.krah | 2010-07-19 14:36:57 +0200 (Mon, 19 Jul 2010) | 13 lines
Issue #9036: Throughout the code base, Py_CHARMASK is used on 8-bit wide
signed/unsigned chars or on integers directly derived from those. In all
cases, it could be replaced by a simple cast to (unsigned char). Reasons
for the change:
a) Make the comment more explicit.
b) If char is unsigned, the cast is optimized away.
c) If char is unsigned, gcc emits spurious "array subscript
has type 'char'" warnings.
........
signed/unsigned chars or on integers directly derived from those. In all
cases, it could be replaced by a simple cast to (unsigned char). Reasons
for the change:
a) Make the comment more explicit.
b) If char is unsigned, the cast is optimized away.
c) If char is unsigned, gcc emits spurious "array subscript
has type 'char'" warnings.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r82059 | victor.stinner | 2010-06-18 01:08:50 +0200 (ven., 18 juin 2010) | 5 lines
Issue #6543: Write the traceback in the terminal encoding instead of utf-8.
Fix the encoding of the modules filename.
Reindent also traceback.h, just because I hate tabs :-)
........
r82061 | victor.stinner | 2010-06-18 01:17:37 +0200 (ven., 18 juin 2010) | 2 lines
Issue #6543: Mention the author of the patch, Amaury Forgeot d'Arc
........
(instances of int, float, complex, decimal.Decimal and
fractions.Fraction) that makes it easy to maintain the invariant that
hash(x) == hash(y) whenever x and y have equal value.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r81400 | antoine.pitrou | 2010-05-21 19:25:34 +0200 (ven., 21 mai 2010) | 12 lines
Merged revisions 81398 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81398 | antoine.pitrou | 2010-05-21 19:12:38 +0200 (ven., 21 mai 2010) | 6 lines
Issue #5753: A new C API function, :cfunc:`PySys_SetArgvEx`, allows
embedders of the interpreter to set sys.argv without also modifying
sys.path. This helps fix `CVE-2008-5983
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5983>`_.
........
................
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81398 | antoine.pitrou | 2010-05-21 19:12:38 +0200 (ven., 21 mai 2010) | 6 lines
Issue #5753: A new C API function, :cfunc:`PySys_SetArgvEx`, allows
embedders of the interpreter to set sys.argv without also modifying
sys.path. This helps fix `CVE-2008-5983
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5983>`_.
........
object to Py_FileSystemDefaultEncoding with the "surrogateescape" error
handler, return a bytes object. If Py_FileSystemDefaultEncoding is not set,
fall back to UTF-8.
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r81168 | victor.stinner | 2010-05-14 17:58:55 +0200 (ven., 14 mai 2010) | 10 lines
Issue #8711: Document PyUnicode_DecodeFSDefault*() functions
* 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
........
* 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/branches/py3k
................
r76713 | ronald.oussoren | 2009-12-08 17:35:28 +0100 (Tue, 08 Dec 2009) | 11 lines
Merged revisions 76712 via svnmerge from
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
........
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/branches/py3k
................
r75246 | benjamin.peterson | 2009-10-04 15:32:25 -0500 (Sun, 04 Oct 2009) | 29 lines
Merged revisions 74841 via svnmerge from
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
........
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.
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r73782 | benjamin.peterson | 2009-07-02 16:44:01 -0500 (Thu, 02 Jul 2009) | 1 line
the old CO_FUTURE flags can't be commented out
................
r73783 | benjamin.peterson | 2009-07-02 16:54:36 -0500 (Thu, 02 Jul 2009) | 1 line
a little more fiddling to make flags like 2.x
................
r73784 | benjamin.peterson | 2009-07-02 16:55:39 -0500 (Thu, 02 Jul 2009) | 9 lines
Merged revisions 73781 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r73781 | benjamin.peterson | 2009-07-02 16:38:36 -0500 (Thu, 02 Jul 2009) | 1 line
test that compile() accepts the future flag
........
................