STINNER Victor added the comment:
Oh, the file contains also a reference to a missing file:
#ifdef PLAN9_THREADS
#include "thread_plan9.h"
#endif
But I don't see where PLAN9_THREADS is defined.
--
___
Python tracker
<http
STINNER Victor added the comment:
The problem is that I don't know how to check in test_threadsignals which
thread implementation is used in Python. It would be nice to have some
functions providing such information in the sys or sysconfig module, maybe
something like sys.float_info.
STINNER Victor added the comment:
@sdaoden: This issue has a lot of patches, can you remove old patches?
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
threading_info.patch:
- Add thread._info() function -> dict with 'name' and 'use_semaphores'
(pthread only) keys
- Skip test_lock_acquire_interruption() and test_rlock_acquire_interruption()
if Python uses pthread without semaphores
STINNER Victor added the comment:
11277.3.diff: this patch looks correct (I'm unable to test it), but can you add
a sentence in mmap doc to explain that mmap.mmap() does flush the file on Mac
OS X and VMS?
--
___
Python tracker
Changes by STINNER Victor :
--
title: test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD) ->
Crash with mmap and sparse files on Mac OS X
___
Python tracker
<http://bugs.python.org/issu
STINNER Victor added the comment:
Oh, fcntl has already a F_FULLFSYNC constant, so we can use like
fcntl.fcntl(fd, fcntl.F_FULLFSYNC) in Python.
> can you add a sentence in mmap doc to explain that mmap.mmap()
> does flush the file on Mac OS X and VMS?
Hum, it does flush the file
STINNER Victor added the comment:
Oh, and can you add a comment explaining why F_FULLFSYNC is needed on Mac OS X
in your patch? (If I understood correctly, it is needed to avoid crash with
sparse files).
--
___
Python tracker
<h
STINNER Victor added the comment:
> (My last reply-mail changed the title. Fixing.)
Yeah, it's a common problem if you use the email interface :-/
--
___
Python tracker
<http://bugs.python.org
STINNER Victor added the comment:
Oh, this is a duplicate of #11863.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
Issue #11876 has been marked as a duplicate of this issue.
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
Patch removing cpthread, pth, lwp and solaris thread implementations. The patch
on configure.in, around the following diff, is invalid:
AC_DEFINE(_REENTRANT)
-AC_CHECK_HEADER(cthreads.h, [AC_DEFINE(WITH_THREAD)
-AC_DEFINE(C_THREADS
STINNER Victor added the comment:
FYI Hurd only supports cthread, without cthread support, Python will not
support threads on Hurd anymore.
There are two Hurd issues to move from cthread to pthread
http://savannah.gnu.org/task/?5487 (opened 5 years ago)
http://savannah.gnu.org/task/?7895
STINNER Victor added the comment:
Oh, it remembers a long story around ext3/ext4 and write barrier, with a
specific problem in Firefox with SQLite.
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/fsync.2.html
" For applications that require ti
STINNER Victor added the comment:
> Most of these names will be removed in 3.3:
> http://bugs.python.org/issue11863
Yeah, I know. My patch should be updated if #11863 is fixed before this issue.
Updated patch:
- add 'pthread_version' key to threading._info()
- test_os uses
STINNER Victor added the comment:
Example on my Debian Sid:
>>> threading._info()
{'pthread_version': 'NPTL 2.11.2', 'use_semaphores': True, 'name': 'pthread'}
--
___
STINNER Victor added the comment:
Python/thread.c contains a reference to a missing file:
#ifdef PLAN9_THREADS
#include "thread_plan9.h"
#endif
But I don't see where PLAN9_THREADS is defined.
remove_threads.patch removes these 3 lines.
--
There is also an unused file: Python
STINNER Victor added the comment:
> The path which sets "pthread_version" should be inside "#ifdef
> _POSIX_THREADS".
> Also, some comments about the doc:
> - you need a "versionadded" tag
Right, fixed.
> - "use_semaphores" should expla
STINNER Victor added the comment:
Let's wait 6 hours for "x86 FreeBSD 6.4 3.x":
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x
The first build including my fix (383a7301616b) should be:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206
STINNER Victor added the comment:
signal_pthread_sigmask.patch:
- add signal.pthread_sigmask() function with doc and tests
- add SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK constants
- fix #11859: fix tests of test_io using threads and an alarm: use
pthread_sigmask() to ensure that only the main
Changes by STINNER Victor :
--
dependencies: +expose signalfd(2) and sigprocmask(2) in the signal module
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
Oh, I forget to read again http://codereview.appspot.com/1132041.
Here is an updated patch reusing some tests and with a better documentation.
--
Added file: http://bugs.python.org/file21736/signal_pthread_sigmask-2.patch
STINNER Victor added the comment:
> c) parse_source_module()
> => covered by the issue #10785.
Issue #10785 didn't change parse_source_module(): it does still encode the
filename.
We need Unicode version of PyParser_ASTFromFile() and PyAST_Compile(): a new
version of t
STINNER Victor added the comment:
"Builder x86 FreeBSD 6.4 3.x Build #1394. Results: Build successful"
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1394
Great! It should be the first success on this buildbot since... 4 months
(r87292, issue #884
Changes by STINNER Victor :
--
title: test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x" buildbot ->
test_mmap.test_large_offset() timeout (1 hour) on "AMD64 Snow Leopard 3.x"
buildbot
___
Python tracker
<http://
STINNER Victor added the comment:
> I think that the last test_threadsignals failures on PPC Tiger
> were related to the new regrtest timeout, and it is now fixed.
Wrong, it was a deadlock. It is a duplicate of #11768 and it is now
STINNER Victor added the comment:
This issue is not fixed: the test does still fail... sometimes. Recent example
(AMD64 FreeBSD 8.2 3.x buildbot):
--
(...)
[283/354] test_logging
Warning -- logging._handlerList was modified by
Changes by STINNER Victor :
--
title: interruption of locks by signals not guaranteed when the semaphore
implementation is not used -> interruption of locks by signals not guaranteed
when locks are implemented using POSIX condition variab
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11864>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
A different approach for this issue is to document fcntl.fcntl(fd,
fcntl.F_FULLFSYNC) in fsync() documentation.
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
> > This issue is not fixed: the test does still fail... sometimes. Recent
> > example
> >(AMD64 FreeBSD 8.2 3.x buildbot):
>
> Yes, I know it's not fixed yet - I'm still working on it. (...)
I realized just after writin
STINNER Victor added the comment:
It failed also on "AMD64 FreeBSD 8.2 3.x" buildbot:
-
test test_compileall failed -- Traceback (most recent call last):
File
"/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_compileall.py",
line
New submission from STINNER Victor :
test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x":
'AEST-10AEDT-11,M10.5.0,M3.5.0' timezone becomes 'EST'.
==
FAIL: test_tzse
New submission from STINNER Victor :
assertEqual(), assertListEqual(), assertSequenceEqual() emits a BytesWarning
warning or raise a BytesWarning exception if python has -b or -bb option.
Attached patch adds tests to demonstrate this issue.
--
components: Library (Lib), Tests, Unicode
Changes by STINNER Victor :
--
keywords: +patch
Added file: http://bugs.python.org/file21740/unittest_str_bytes.patch
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
compile_filename.patch:
- Add PyErr_ProgramTextObject() and PyErr_WarnExplicitObject() functions
- Store the filename as Unicode in compile.c
- Remove the filename from get_ref_type() fatal error (I never see such fatal
error, and I hope that it does never
New submission from STINNER Victor :
[129/354] test_multiprocessing
Process Process-72:
Traceback (most recent call last):
File
"/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/multiprocessing/process.py",
line 263, in _bootstrap
self.run()
File
"/expor
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21735/signal_pthread_sigmask.patch
___
Python tracker
<http://bugs.python.org/issue8407>
___
___
Pytho
STINNER Victor added the comment:
sys_thread_info.patch:
- Replace threading._info() by sys.thread_info: it now always have 3 values,
but all values are optional (can be None). sys.thread_info.name is None if
Python is compiled without threads.
- Reorder sys internal doc (Static objects
STINNER Victor added the comment:
> The main issue is that we'd have to provide (and maintain) our own
> implementation of log2 for Windows (and other OSs that don't have all
> the C99 support. Solaris?)
No, we don't have to. Python has already a lot of optional fun
STINNER Victor added the comment:
11877.2.diff: On Mac OS X, fsync(fd, full_sync=True); fsync(fd) do a full sync
twice. You should restore the old file flags at fsync() exit. Or this
surprising behaviour should be documented.
--
___
Python tracker
Changes by STINNER Victor :
--
title: expose signalfd(2) and sigprocmask(2) in the signal module -> expose
signalfd(2) and pthread_sigmask in the signal module
___
Python tracker
<http://bugs.python.org/iss
STINNER Victor added the comment:
Fixed in 3.2 (fa5e348889c2) and 3.3 (7b8d625eb6e4). The bug is a regression
introduced in Python 3.2, so Python 3.1 doesn't need to be fixed.
--
status: open -> closed
___
Python tracker
<http://bugs
STINNER Victor added the comment:
Another huge patch to support Unicode filenames: parser_unicode.patch
Doc/c-api/exceptions.rst | 26 +++---
Include/ast.h|5 ++
Include/compile.h| 15 +++-
Include/parsetok.h | 42
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21743/compile_filename.patch
___
Python tracker
<http://bugs.python.org/issue11619>
___
___
Python-bug
STINNER Victor added the comment:
> http://gentoo.osuosl.org/distfiles/sandbox-2.5.tar.xz
What is this file? Where does it come from?
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issu
STINNER Victor added the comment:
> Is the assert still needed?
The assertion is in RLock()._acquire_restore(), not in RLock._release_save(). I
prefer to keep it, it doesn't hurt.
close this issue because I commited my fix.
--
resolution: -> fixed
status: ope
STINNER Victor added the comment:
The commit:
New changeset 2c0da1c4f063 by Victor Stinner in branch 'default':
Issue #11915: threading.RLock()._release_save() raises a RuntimeError if the
http://hg.python.org/cpython/rev/2c0da1c4f063
--
STINNER Victor added the comment:
This issue comes from sandbox, not from ctypes.
Using sandbox, execv() C function doesn't close files with FD_CLOEXEC flag if
the child program is a static program.
test_ctypes hangs on find_library() in subprocess.Popen._execute_child():
- create a
STINNER Victor added the comment:
If you would like to reproduce sandbox bug:
gcc sandbox_exec_bug.c -o sandbox_exec_bug
gcc -static static.c -o static
sandbox ./sandbox_exec_bug
The bug doesn't occur if static.c is not compiled with -static.
Note: I don't know if "sandbox ./s
STINNER Victor added the comment:
I close this issue because it is not a Python. I will try to open an issue in
Gentoo bugtracker, but now I am too tired to do that :-)
--
resolution: -> invalid
status: open -> closed
___
Python tracker
STINNER Victor added the comment:
If the child program is static, sandbox protects it using a tracing mechanism
(based on ptrace with PTRACE_SYSCALL). Output is debug mode:
trace_main tracing: ./static
TRACE (pid=10377):trace_main: parent waiting for child (pid=10378) to signal
TRACE (pid
STINNER Victor added the comment:
> Correctly merging #9319 into 3.3?
No, this issue was fixed differently in Python 3.3. I see that you reverted
(bb62908896fe) this merge (except the test, which is a good idea).
--
___
Python tracker
&l
New submission from STINNER Victor :
Because we don't have any OS/2 and VMS maintainer for Python 3, I propose to
drop OS/2 and VMS support in Python 3.3: OSes unsupported in 3.3, code removed
in 3.4 (see the PEP 11 for the process).
--
components: Interpreter Core
messages: 1
Changes by STINNER Victor :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11918>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
Modules/_testembed fails with ISO-8859-15 locale encoding because of a
bootstrap issue. The problem is that the filesystem encoding codec is
implemented in Python: Python requires the codec to loads modules, but it has
to load a module to load the codec. I
STINNER Victor added the comment:
> I think that Python used interp->codecs_initialized flag
Yes in PyUnicode_AsEncodedString(), in Python 3.0 and 3.1. Python 3.2 has also
the test, but PyUnicode_AsEncodedString() is no more used to encode filenames.
I removed the test in Pyth
STINNER Victor added the comment:
> The problem is the test on the "python initialization":
> PyUnicode_EncodeFSDefault / PyUnicode_DecodeFSDefaultAndSize
> check the global Py_FileSystemDefaultEncoding variable (use
> C functions if it is NULL).
The problem is a l
STINNER Victor added the comment:
> The main issue is that we'd have to provide (and maintain) our own
> implementation of log2 for Windows (and other OSs that don't have all
> the C99 support. Solaris?)
Can't we simply use (approximation to 1/log(2)) *
STINNER Victor added the comment:
> Can't we simply use (approximation to 1/log(2)) * log(x)?
> Is it worse than reimplementing it using log(x)/log(2) in Python?
Hum. With a x86 and the right compiler optimization level, log(x)/log(2) in C
can be more accurate than log(x)/log(2
STINNER Victor added the comment:
I reported the bug on Gentoo bug tracker:
http://bugs.gentoo.org/show_bug.cgi?id=364877
--
___
Python tracker
<http://bugs.python.org/issue11
New submission from STINNER Victor :
test_ttk_guionly.test_traversal() failed on "x86 Windows7 3.x":
---
[120/354] test_ttk_guionly
test test_ttk_guionly failed -- Traceback (most recent call last):
File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\l
STINNER Victor added the comment:
Code of the test:
-
class NotebookTest(unittest.TestCase):
def setUp(self):
support.root_deiconify()
self.nb = ttk.Notebook(padding=0)
self.child1 = ttk.Label()
self.child2 = ttk.Label
STINNER Victor added the comment:
@loewis: Would you like to review the patch?
You wrote on python-dev:
"For OS/2, I propose to syntactically break the makefile"
and
"For VMS, I *think* the build process is configure-based (but I may
misremember); if so, adding an exit into con
STINNER Victor added the comment:
Oh, I just realized that the PEP 11 doesn't ask to mention unsupported OSes in
the What's new document. New patch to mention that OS/2 and VMS are no more
supported.
--
Added file: http://bugs.python.org/file21780/unsupport_os2_v
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21779/unsupport_os2_vms.patch
___
Python tracker
<http://bugs.python.org/issue11918>
___
___
Pytho
STINNER Victor added the comment:
> > - Rename _PyThread_Info() to PyThread_GetInfo() (consistent name with
> > PyFloat_GetInfo() and PyLong_GetInfo())
>
> I don't think we want that API to be public, so it should be
> _PyThread_GetInfo().
Why should it be priva
STINNER Victor added the comment:
> The patch looks fine; please add a reference to PEP 11
> into the error messages
Ok, done.
> "Our plan are to port, this year 2.7, then 3.x."
VMS is unsupported in 3.3 and the code will be removed in 3.4. If anyone comes
with patche
STINNER Victor added the comment:
> Well, if it's called _info() in Python, it's private too!
My patch replaces thread._info() by sys.thread_info: it becomes public.
> What I mean is that the "#ifdef WITH_THREAD" could be done in
> sysmodule.c rather than
STINNER Victor added the comment:
time.rst:
* **Year 2000 (Y2K) issues**: Python depends on the platform's C library, which
generally doesn't have year 2000 issues, since all dates and times are
represented internally as seconds since the epoch. Function :func:`strptime`
c
STINNER Victor added the comment:
"What makes you say so?
1970"
Don't write ">>> " using the email interface :-)
--
>>> t
time.struct_time(tm_year=70, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0,
tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
>>&
STINNER Victor added the comment:
test_capi pass on x86 debian parallel 3.x: I close this issue again :-)
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
STINNER Victor added the comment:
The next step is to update the datetime module: something like the attached
patch (datetime_y2k.patch).
--
Added file: http://bugs.python.org/file21788/datetime_y2k.patch
___
Python tracker
<http://bugs.python.
Changes by STINNER Victor :
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11918>
___
___
Pyth
STINNER Victor added the comment:
PEP 398 -- Python 3.3 Release Schedule
http://www.python.org/dev/peps/pep-0398/
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
> Victor, the fix needs to go into 3.2 as well.
Oh, I thought that Modules/_testembed.c was only in 3.3. Anyway, it is a real
bug in 3.2, and it is now fixed (I backported the 2 fixes in 3.2).
--
status: open ->
Changes by STINNER Victor :
--
title: interruption of locks by signals not guaranteed when locks are
implemented using POSIX condition variables -> interruption of locks by signals
not guaranteed when locks are implemented using POSIX condition variables; add
sys.thread_i
STINNER Victor added the comment:
New changeset 28b9702a83d1 by Victor Stinner in branch 'default':
Issue #8407, issue #11859: Add signal.pthread_sigmask() function to fetch
http://hg.python.org/cpython/rev/28b9702a83d1
--
___
Python trac
STINNER Victor added the comment:
signalfd.patch: Add signal.signalfd(), signal.SFD_CLOEXEC and
signal.SFD_NONLOCK.
The patch is based on http://codereview.appspot.com/1132041 and the last
version (bzr) of python-signalfd.
The patch uses also PyModule_AddIntMacro() for the 3 constants added
STINNER Victor added the comment:
> The FreeBSD-AMD64 bot exhibits sporadic hanging in unspecific places.
You can try a shorter regrtest timeout, edit Lib/test/regrtest.py near:
if hasattr(faulthandler, 'dump_tracebacks_later'):
timeout = 60*60
(or use --timeout
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11361>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
We may have a support.HOST_IPV6 constant, but I would imply to modify many
tests to use it. I prefer to apply your simple patch, thanks!
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
unittest_str_bytes-2.patch:
- add new tests to reproduce the bug
- fix the bug: ignore temporary BytesWarning warnings while comparing objects
and sequences
--
Added file: http://bugs.python.org/file21844/unittest_str_bytes-2.patch
STINNER Victor added the comment:
The test suite crashs randomly with issue9756.patch on my Ubuntu 11.04 (AMD64
with 4 cores, 4 GB of memory, Linux 2.6.38). I use "./python -bb
Lib/test/regrtest.py -r" to reproduce the crash.
... I tried without the patch, and test_descr does cra
STINNER Victor added the comment:
Oh, the Ubuntu host has a temperature issue and hardware errors... Example of
mcelog output:
MCE 0
CPU 0 THERMAL EVENT TSC 198d1eb8325
TIME 1304222195 Sun May 1 05:56:35 2011
Processor 0 heated above trip temperature
STINNER Victor added the comment:
Le dimanche 01 mai 2011 à 03:19 +, STINNER Victor a écrit :
> The test suite crashs randomly with issue9756.patch on my Ubuntu 11.04
> (AMD64 with 4 cores, 4 GB of memory, Linux 2.6.38). I use "./python
> -bb Lib/test/regrtest.py -r" to
STINNER Victor added the comment:
> Ok, I'm sure that I have hardware issues, but I am also sure that the
> patch introduces random crashes, especially in
> test_descr.test_wrapper_segfault().
Forget my last messages: my Ubuntu box has serious memory issues. memtest86+
found 41
STINNER Victor added the comment:
Le mardi 26 avril 2011 à 22:20 +, Alexander Belopolsky a écrit :
> Alexander Belopolsky added the comment:
>
> On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor
> wrote:
> ..
> >
> > timemodule.c:
> >
> > PyDoc_ST
STINNER Victor added the comment:
Hey, I had already this bug and I also wrote a patch: copy_script-2.patch
attached to #6011. It is very similar to build_scripts-binary_mode.patch (read
the file in binary mode to avoid the encode/decode dance). But it checks also
that the path to Python
STINNER Victor added the comment:
Oh, if the process is able to handle CTRL+c on Windows, it means that
faulthandler.register() could be used on Windows. While developing the
faulthandler module, I tried all signals but I was only able to handle SIGSEGV,
SIGABRT, SIGBUS and SIGILL on Windows
STINNER Victor added the comment:
The issue is race condition and was rare (I only saw it once on FreeBSD 7.2 3.x
buildbot). I suppose that it is fixed, I'm unable to check (I am unable to
reproduce the bug in my FreeBSD 8 VM). Reopen the issue if it is not fixed yet.
--
depende
STINNER Victor added the comment:
> I think this is a duplicate of issue #9756
Yes it is and the issue is now fixed. The example now fails with the correct
exception:
Traceback (most recent call last):
File " x.py", line 12, in
p.__class__.__call__(p)
TypeError: descrip
STINNER Victor added the comment:
I am not able to check the fix, but the buildbots are :-)
What should be done for Python 2.7? In Python 2.7, zlib.crc32() stores the
buffer length into an int (so the maximum length is INT_MAX), and so test_zlib
doesn't test a (sparse) file of
STINNER Victor added the comment:
Oh... math.log() has an optional second argument: base. math.log(x, 2). But it
is equivalent as math.log(x) / math.log(2) in Python. math.log(x, 2) is
implemented as:
num=math.log(x)
den=math.log(2)
return num / den
where num and den are Python floats
STINNER Victor added the comment:
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> LookupError: unknown encoding: cp0
That's a bug in os.device_encoding(): os.device_encoding(sys.stdout.fileno())
should return None if the application has no consol
STINNER Victor added the comment:
> On a Western Windows, I suggest
>PYTHONIOENCODING=cp1252:backslashreplace
Why using this very small charset whereas a web server can use UTF-8?
I don't think that using backslashreplace on stdout is a good idea.
> But
>PYTHONIOE
STINNER Victor added the comment:
Le lundi 02 mai 2011 07:05:28, vous avez écrit :
> * the patch introduces code/complexity in _baseAssertEqual and other
> places, using catch_warnings to change and restore the warning filters at
> every call;
Yes, and what is the problem? I think t
STINNER Victor added the comment:
> Rather than fiddling with the warnings filters, wouldn't it be easier
> to just catch BytesWarning and return False in that case?
It's another possible solution, but it would display a warning
STINNER Victor added the comment:
> copy_script-2.patch uses os.fsencode(), which doesn't exist in Python 3.1.
Correct, with Python 3.1, you can use
filename.encode(sys.getfilesystemencoding(), 'surrogateescape'). But you must
use os.fsencode() with Python >= 3.2 be
STINNER Victor added the comment:
test_signal.PthreadSigmaskTests fails on Mac OS X.
http://www.python.org/dev/buildbot/all/builders/PPC Leopard
3.x/builds/1785/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/PPC Tiger
3.x/builds/1748/steps/test/logs/stdio
---
[186/354
2901 - 3000 of 35284 matches
Mail list logo
