[issue18623] Factor out the _SuppressCoreFiles context manager

Charles-François Natali added the comment: Could you post your patch without the '--git' option? Apparently it doesn't work well with the code review tool. > It would be nice if there was a more explicit way to test the > creation of core files, however. One possibility

[issue18816] "mmap.flush()" is always synchronous, hurting performance

Charles-François Natali added the comment: > I propose to add an optional keyword parameter with default value "SYNC" > (compatibility) but that can be "ASYNC", "INVALIDATE" (can be > "SYNC|INVALIDATE" and "ASYNC|INVALIDATE" too). AF

[issue18811] add ssl-based generator to random module

Charles-François Natali added the comment: > How about we generalize SystemRandom so users can implement > a custom RNG class wby providing a method rng(amount) -> bytes? The random module already makes it easy: """ Class Random can also be subclassed if you want

[issue18763] subprocess: file descriptors should be closed after preexec_fn is called

Charles-François Natali added the comment: Here's a patch with a more robust test: the previous test worked, but assume that only stdin, stdout and stderr FDs would be open in the child process. This might not hold anymore in a near future (/dev/urandom persistent FD). The new test is

[issue18763] subprocess: file descriptors should be closed after preexec_fn is called

Charles-François Natali added the comment: > I don't understand why os.dup2() is more reliable than os.pipe() for a unit > test? I use dup2() because it allows me to specify a target FD, so the parent can know precisely which FD was opened by the preexec hook, and check it's clo

[issue18763] subprocess: file descriptors should be closed after preexec_fn is called

Charles-François Natali added the comment: > You might also add a check: > > self.assertLessEqual(remaining_fds, {0, 1, 2}) Well no, because the interpreter might have other FDs open than stdin, stdout and stderr. -- ___ Pytho

[issue18763] subprocess: file descriptors should be closed after preexec_fn is called

Charles-François Natali added the comment: > Close_fds is not supposed to close them? Yes, but some new fds might be open in the child process, e.g. for /dev/urandom. That's why it's better to check that this precise FD is closed. Of course, if the /dev/urandom FD gets assigned t

[issue18643] implement socketpair() on Windows

Charles-François Natali added the comment: Here's a patch. Note that I'm still not sure whether it belong to the socket module or test.support. -- keywords: +needs review, patch stage: needs patch -> patch review versions: +Python 3.4 Added file: http://bugs.python.

[issue18643] implement socketpair() on Windows

Charles-François Natali added the comment: > On Linux, many tests of test_socket are failing with the pure Python > implementation. The only failing tests I see are due to the fact that the Python implementation uses AF_INET instead of AF_UNIX, which is normal since Windows doesn't h

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: Alright, I've updated the patch to have a distinct selectors module, and with Guido's comments. Before I post it for final review, I have three more questions: 1) In the documentation, I don't know how to best refer to files object regis

[issue18756] os.urandom() fails under high load

Charles-François Natali added the comment: > New changeset fe949918616c by Antoine Pitrou in branch 'default': > Issue #18756: Improve error reporting in os.urandom() when the failure is due > to something else than /dev/urandom not existing. > http://hg.python.org/cp

[issue18756] os.urandom() fails under high load

Charles-François Natali added the comment: Or more precisely, just run the test in a subprocess. That should fix the OS X failure if we don't restore the RLIMIT_NOFILE limits, and will make the test more robust (but you can't reuse the new test, since it won't work wi

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: > Didn't you forget to upload it? I wanted to have answer to my questions first :-): > Before I post it for final review, I have three more questions: -- ___ Python tracker <http://b

[issue18643] implement socketpair() on Windows

Charles-François Natali added the comment: > self.assertEqual(sock.family, socket.AF_UNIX) > AssertionError: 2 != 1 This is normal. == > FAIL: test_sendall_interrupted (test.test_socket.GeneralMo

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

Charles-François Natali added the comment: The test is failing on Tiger buildbots: """ == FAIL: test_parse_cert_CVE_2013_4238 (test.test_ssl.B

[issue18808] Thread.join returns before PyThreadState is destroyed

Charles-François Natali added the comment: The first patch looks good, as for the second one, it'll take some time :-) -- ___ Python tracker <http://bugs.python.org/is

[issue18643] implement socketpair() on Windows

Charles-François Natali added the comment: Alright, I think I know what's happening. The Python implementation uses a TCP socket, whereas the native implementation uses AF_UNIX socket. The maximum size of data that can be written to a socket without blocking is given by its send/receive bu

[issue18643] implement socketpair() on Windows

Changes by Charles-François Natali : Added file: http://bugs.python.org/file31458/sendall_write.diff ___ Python tracker <http://bugs.python.org/issue18643> ___ ___ Pytho

[issue18763] subprocess: file descriptors should be closed after preexec_fn is called

Changes by Charles-François Natali : -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.or

[issue18623] Factor out the _SuppressCoreFiles context manager

Charles-François Natali added the comment: The test works for me. The only problem is that faulthandler dumps a stack: it might be better to use subprocess with stderr=devnull). As for the status code, it looks like a bash bug: """ $ cat /tmp/test_core.py import os if

[issue18836] Potential race condition in exceptions

Charles-François Natali added the comment: > If it is intended not to be able to catch all exceptions > and prevent a traceback being showed this should be indeed a PEP. You may want to have a look at sys.excepthook. -- nosy: +neologix ___

[issue18571] Implementation of the PEP 446: non-inheritable file descriptors

Charles-François Natali added the comment: 14.1 --- a/Lib/multiprocessing/util.py 14.2 +++ b/Lib/multiprocessing/util.py 14.13 # 14.14 # Return pipe with CLOEXEC set on fds 14.15 # 14.16 +# Deprecated: os.pipe() creates non-inheritable file descriptors 14.17 +# since

[issue18786] test_multiprocessing_spawn crashes under PowerLinux

Charles-François Natali added the comment: > It looks like the main process keeps getting killed by SIGUSR1. > Don't know why. In Lib/test/_test_multiprocessing.py: """ def test_poll_eintr(self): got_signal = [False] def record(*args):

[issue18786] test_multiprocessing_spawn crashes under PowerLinux

Charles-François Natali added the comment: > Thanks! You're welcome :) BTW, I don't know if that would fulfill the goal of your test here, but when I want to check for EINTR handling, I just use alarm (see attached patch). The only downside is that the minimum dela

[issue18869] test suite: faulthandler signal handler is lost

New submission from Charles-François Natali: At the beginning of the test suit execution, faulthandler registers its signal handler for fatal signals, as well as SIGUSR1 and SIGALRM. The problem is that some tests temporary change those handlers, e.g. for EINTR-handling tests. While they do

[issue18851] subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors

Charles-François Natali added the comment: Yes, the problem is that the pipes FDs are closed twice if fork() succeeds, but exec() fails. They're closed in _execute_child(): 1286 if p2cread is not None and p2cwrite is not None: 1287 os.close(p2

[issue18869] test suite: faulthandler signal handler is lost

Charles-François Natali added the comment: > Or perhaps we could enhance the signal module so that getsignal() return > something (i.e. a specific object) which can restore the C signal handler. > That would be better than special-casing faulthandler, IMHO. Yes, I thought about that,

[issue18643] implement socketpair() on Windows

Charles-François Natali added the comment: Victor, did you have a chance to test the patch? -- ___ Python tracker <http://bugs.python.org/issue18643> ___ ___ Pytho

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: Alright, here's the patch, with all the changes discussed (and of cours a separate selectors.py). -- Added file: http://bugs.python.org/file31499/selectors-14.diff ___ Python tracker <http://bugs.py

[issue18869] test suite: faulthandler signal handler is lost

Charles-François Natali added the comment: I'll tackle #13285 instead. -- resolution: -> duplicate stage: -> committed/rejected superseder: -> signal module ignores external signal changes ___ Python tracker <http://bugs.pyth

[issue18643] implement socketpair() on Windows

Charles-François Natali added the comment: Since I'll update socket tests to also use support.PIPE_MAX_SIZE, maybe we should rename this variable while we're at it? Anybody can think of a name that would work both for sockets and pipes? -- nos

[issue18643] implement socketpair() on Windows

Charles-François Natali added the comment: > Why not using a different value (constant) for sockets? We can add a new constant (e.g. SOCK_MAX_SIZE), that would be fine, as long as it aliases to PIPE_MAX_SIZE. There's no need to have two values (the current 4MB value is fine). > By

[issue18869] test suite: faulthandler signal handler is lost

Changes by Charles-François Natali : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue18869> ___ ___ Python-bugs-list mailing list Un

[issue18806] socketmodule: fix/improve setipaddr() numeric addresses handling

Changes by Charles-François Natali : -- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> socket.gethostbyname incorrectly parses ip ___ Python tracker <http://bugs.python

[issue16201] socket.gethostbyname incorrectly parses ip

Charles-François Natali added the comment: Stupid question: why use scanf()/strtol() to parse an IP address, and not simply inet_pton()/inet_aton(), which are made precisely for that purpose? inet_pton() is POSIX (it was introduced at the same time as getaddrinfo(), which is used

[issue16201] socket.gethostbyname incorrectly parses ip

Charles-François Natali added the comment: Note that for IPv6 addresses, we should just extract manually the scope ID ('%' prefix) if present. -- ___ Python tracker <http://bugs.python.o

[issue16201] socket.gethostbyname incorrectly parses ip

Charles-François Natali added the comment: Here's a patch using inet_pton() if available, otherwise inet_aton() if available, otherwise fallback to getaddrinfo(). This should work on every platform, but if a platform has neither inet_pton() nor inet_aton(), calling getaddrinfo() will inc

[issue16201] socket.gethostbyname incorrectly parses ip

Charles-François Natali added the comment: > For Windows >= Vista, inet_pton() is available. > I'm not sure whether XP has one of them: if not, then we might keep > the hand-parsing as a fallback. Apparently, XP doesn't have inet_aton()... So I changed the code to use in

[issue16201] socket.gethostbyname incorrectly parses ip

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file31506/parse_inet.diff ___ Python tracker <http://bugs.python.org/issue16201> ___ ___ Pytho

[issue18851] subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors

Charles-François Natali added the comment: Rietveld's choking on git diffs. -- ___ Python tracker <http://bugs.python.org/issue18851> ___ ___ Python-bugs-l

[issue18643] implement socketpair() on Windows

Charles-François Natali added the comment: Alright, I chose a 16MB size for SOCK_MAX_SIZE because nowadays, one can encounter large buffers for Gigabit/10Gb Ethernet. Regarding the original issue: is it OK to add it as socket.socketpair(), or should it only be added to test.support? Since I

[issue18876] Problems with files opened in append mode with io module

Charles-François Natali added the comment: > On which systems is O_APPEND not supported? It's part of the POSIX standard, > and even Windows seems to have it. That would be surprising. An easy way to find this out would be to remove the ifdef: 352 #ifdef O_APPEND 353 if (append

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

Charles-François Natali added the comment: Just two things: - running under valgrind with the suppression file would help pinpoint this - usually, stack/heap overflows or invalid pointer dereference affect a contiguous chunk of memory: here, there's a *single bit* flipped, not even a byte

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: Hello, > - What about Solaris' /dev/poll? That should be pretty easy to add by someone who has access to a Solaris box: I could use the buildbots, but it'd take a couple iterations to get it right. > - I'm not sure why in case of

[issue18885] handle EINTR in the stdlib

New submission from Charles-François Natali: As discussed in http://mail.python.org/pipermail/python-dev/2013-August/128204.html, I think that we shouldn't let EINTR leak to Python code: it should be handled properly by the C code, so that users (and the Python part of the stdlib) don&#

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

Charles-François Natali added the comment: 2013/8/30 Martin Mokrejs : > Per comment from Charles-François, so you mean that this single-bit change > won't be caught by valgrind, right? Why does not memtest86+ detect that? > Could python when compiled with the --with-pydebug print

[issue18885] handle EINTR in the stdlib

Changes by Charles-François Natali : -- nosy: +haypo, pitrou, sbt ___ Python tracker <http://bugs.python.org/issue18885> ___ ___ Python-bugs-list mailin

[issue18418] Thread.isAlive() sometimes True after fork

Changes by Charles-François Natali : -- nosy: +pitrou stage: patch review -> commit review versions: +Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issu

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

Changes by Charles-François Natali : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

Charles-François Natali added the comment: Oops. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue18709> ___ ___ Python-bugs-list mai

[issue18887] test_multiprocessing.test_connection failure

New submission from Charles-François Natali: http://buildbot.python.org/all/builders/x86%20Windows7%202.7/builds/2211/steps/test/logs/stdio """ test_ignore_listener (test.test_multiprocessing.TestIgnoreEINTR) ... test test_multiprocessing failed -- Traceback (most recent call la

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: 2013/8/31 Guido van Rossum : > But still I agree with Giampaolo that the decorator doesn't feel > right. It's like a try/except around the entire body of your function, > which is usually a code smell (even though I realize the exc

[issue18418] Thread.isAlive() sometimes True after fork

Charles-François Natali added the comment: > The final patch includes tests that are very reliable at > revealing the bug in 2.7 and 3.3. Indeed, I could reproduce it systematically without the patch. > Thanks for accepting this patch! Well, thanks for the patch! -- r

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: Oh, and FWIW, that's also what Java does: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5100121 http://hg.openjdk.java.net/jdk6/jdk6-gate/jdk/file/6daa81bdfd18/src/solaris/native/sun/nio/ch/PollArrayWrapper.c (I know some people don't

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: > I may be missing something here but isn't the whole point of EINTR to > interrupt a potentially long running syscall? No. EINTR is an artifact of the early Unix design, because failing when a signal was delivered was simpler than res

[issue18885] handle EINTR in the stdlib

Charles-François Natali added the comment: Gregory, thanks, that's what I was planning to do. But since the recent discussions (mainly on selectors), there are points I obviously don't - and won't - agree with (such as select() returning EINTR or returning early, same for sl

[issue18885] handle EINTR in the stdlib

Changes by Charles-François Natali : -- nosy: -neologix ___ Python tracker <http://bugs.python.org/issue18885> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: Here's a patch returning [] on EINTR. I've tested it on Linux, Windows, FreeBSD, OpenSolaris and OS-X. -- Added file: http://bugs.python.org/file31536/selectors-15.diff ___ Python trac

[issue18835] Add aligned memory variants to the suite of PyMem functions/macros

Charles-François Natali added the comment: > Please don't FUD this one to death. Aligned memory access is > sometimes important and we currently have no straight-forward > way to achieve it. I guess that a simple way to cut the discussion short would be to have a first implement

[issue18907] urllib2.open FTP open times out at 20 secs despite timeout parameter

Charles-François Natali added the comment: Actually, I think urllib (actually ftplib) handles the timeout correctly. Here's the result on my Linux box (replacing the server with localhost, with a firewall rule to drop packets to ftp port): $ ./python ~/edgartimeouttest3.py Open o

[issue16201] socket.gethostbyname incorrectly parses ip

Charles-François Natali added the comment: Here's an updated patch with new tests. It passes the regression test, and yields noticable performance improvements for IPv6: before: $ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); DATA

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: > Is there anything left to do or can we close this issue? I usually wait until the test is run on the buildbots to check I didn't break anything: apparently that's OK, so we can close. > It would be nice to mention the new selecto

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: > Giampaolo Rodola' added the comment: > > I have realized just now that at least epoll() and kqueue() selectors could > take advantage and define their own modify() method (there was even a TODO I > totally missed). As a side

[issue18935] test_regrtest.test_timeout failure

New submission from Charles-François Natali: http://buildbot.python.org/all/builders/AMD64 Fedora without threads 3.x/builds/5074/steps/test/logs/stdio """ == FAIL: test_timeout (test.test_regrtest.Pa

[issue18934] multiprocessing: use selectors module

New submission from Charles-François Natali: Here's a patch. -- components: Library (Lib) files: selectors_multiprocessing.diff keywords: needs review, patch messages: 197012 nosy: neologix, sbt priority: normal severity: normal stage: patch review status: open title: multiproce

[issue16853] add a Selector to the select module

Charles-François Natali added the comment: > Richard Oudkerk added the comment: > > Even with edge-triggered notification, doesn't registering an fd check > the current readiness: Hum... Looks like I forgot to turn my brai

[issue18934] multiprocessing: use selectors module

Charles-François Natali added the comment: The test is failing on some (unstable) buildbots: http://buildbot.python.org/all/builders/AMD64%20Solaris%2011%20%5BSB%5D%203.x/builds/1598/steps/test/logs/stdio """

[issue18934] multiprocessing: use selectors module

Charles-François Natali added the comment: > Richard Oudkerk added the comment: > > I remember wondering at one time why EPOLLNVAL did not exist, and realizing > that closed fds are just silently unregistered by epoll(). Exactly. > I guess the issue is that some of the selec

[issue18934] multiprocessing: use selectors module

Charles-François Natali added the comment: I just realized that using DefaultSelector isn't optimal for Connection: It's fine for forkserver, since it's a long lived process, but for Connection.poll(), this means that it'll use epoll or kqueue: which means allocating a new

[issue18623] Factor out the _SuppressCoreFiles context manager

Charles-François Natali added the comment: >> Is there anything else that this patch should address? > > I hoped Charles-François would answer this one, but no, I don't think there's > anything left :) Sorry, I had completely forgotten this issue. The only comme

[issue18963] test_selectors test_above_fd_setsize cases fail on OS X due to infinite hard limit

Charles-François Natali added the comment: > R. David Murray added the comment: > > See also issue issue 17409. > > The code isn't setting it to RLIM_INFINITY explicitly, though, so this must > mean that OSX is reporting an infinite hard limit when the hard limit is

[issue18969] test suite: enable faulthandler timeout in assert_python

New submission from Charles-François Natali: Currently, the test suite, as well as processes spawned by the script_helper.assert_python family, are run with faulthandler enabled. That's great to debug crashes, but it would be even better if those processes were started with faulthand

[issue18935] test_regrtest.test_timeout failure

Charles-François Natali added the comment: Anyone? (The patch is trivial, but I'm not familiar with regrtest). -- ___ Python tracker <http://bugs.python.org/is

[issue18963] test_selectors test_above_fd_setsize cases fail on OS X due to infinite hard limit

Charles-François Natali added the comment: I knew this wouldn't be so easy with OS X... http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/6916/steps/test/logs/stdio == ERROR: test_above_fd_se

[issue18935] test_regrtest.test_timeout failure

Charles-François Natali added the comment: Committed. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue18963] test_selectors test_above_fd_setsize cases fail on OS X due to infinite hard limit

Charles-François Natali added the comment: Alright, it should be fixed now, thanks for the report. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: -> behavior ___ Python tracker <http://

[issue18934] multiprocessing: use selectors module

Changes by Charles-François Natali : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue14532] multiprocessing module performs a time-dependent hmac comparison

Charles-François Natali added the comment: > v3 patch, based on feedback from the review here: > http://bugs.python.org/review/14532/show Looks good to me. One last thing (sorry for not bringing this up earlier): I don't like bikeshedding, but at least to me, `time_independent_e

[issue14308] '_DummyThread' object has no attribute '_Thread__block'

Charles-François Natali added the comment: > Here is a complete patch + tests for 2.7. I like the test. However there's something I find strange with the patch: """ diff --git a/Lib/threading.py b/Lib/threading.py --- a/Lib/threading.py +++ b/Lib/threading.py

[issue14308] '_DummyThread' object has no attribute '_Thread__block'

Charles-François Natali added the comment: > New patch with the hasattr() approach. LGTM. -- ___ Python tracker <http://bugs.python.org/issue14308> ___ ___ Py

[issue14635] telnetlib uses select instead of poll - limited to FD_SETSIZE fds

Charles-François Natali added the comment: See also issue #10527, dealing with multiprocessing. Note that this probably affects other modules besides telnetlib, so it might be interesting to find a way to factorize code (i.e. use poll() if available or fallback to select()). -- nosy

[issue14606] Memory leak subprocess on Windows

Changes by Charles-François Natali : -- resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue14632] Race condition in WatchedFileHandler leads to unhandled exception

Charles-François Natali added the comment: Thanks for the report and patch. I'm making Vinay nosy, as he's the logging expert. A couple remarks: - it would be nice to add your testcase to the logging tests (Lib/test/test_logging.py) - I think you could probably save the whole fsta

[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu

Charles-François Natali added the comment: Could you please run: $ sh -x ./configure to see what's going on. It might also be interesting to have the output of $ strace -f ./configure Thanks. -- nosy: +neologix ___ Python tracker

[issue14532] multiprocessing module performs a time-dependent hmac comparison

Charles-François Natali added the comment: > I have used the name "secure_compare" in the past for such a function. That > said, I don't have strong feelings either way about the naming, so I'll > yield to the others. I prefer this name too. Wait one day or two (t

[issue14632] Race condition in WatchedFileHandler leads to unhandled exception

Charles-François Natali added the comment: > There's certainly a problem to be addressed here, but integrating the test > into the regular test suite represents a problem in that the test takes > around 10 minutes to run, and sometimes completes successfully. I'm not

[issue14632] Race condition in WatchedFileHandler leads to unhandled exception

Charles-François Natali added the comment: > Charles-François: Certainly I can reduce the iterations to make the test > faster. As it is, I did reproduce the failure on my dev system, but only > once, after running John's test script about a dozen times: every other > t

[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu

Charles-François Natali added the comment: Your strace output looks strange :-) Unless it's truncated, we see that the wait4() doesn't return when the test pthread executable exits... Could you try building this code : """ #include void* routine(void* p

[issue14632] Race condition in WatchedFileHandler leads to unhandled exception

Charles-François Natali added the comment: > I can't see why this always works, while John's script sometimes fails. It does fail consistently on my machine. I'm attaching the diff just in case. -- Added file: http://bugs.python.org/file25345/test

[issue1522400] irda socket support

Charles-François Natali added the comment: Here's a cleanup up patch against default. However, I don't have any IrDA capable device neither, so I won't be able to help much. I'll ask on python-dev if someone can help. As for the manual decoding, AFAICT you'll hav

[issue14059] Implement multiprocessing.Barrier

Charles-François Natali added the comment: The patch looks good. However, I've had two failures while testing it: - a BrokenBarrierError on test_default_timeout: I see you've already increased the timeout from the original threading code, but you can probably double it (we have

[issue1522400] irda socket support

Charles-François Natali added the comment: Actually I think it suffers from the same problem as AF_UNIX: sockaddr_irda->sir_name, like sockaddr_un->sun_path, don't have to be NUL-terminated, and the kernel can return non NUL-terminated strings. Which means tha

[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu

Charles-François Natali added the comment: > Yes, this code is hanging in my system. I'm posting the strace output. > > If there's any other information that may be helpful I'll happily provide it. Well, in that case it's a bug in your pthread implementatio

[issue14428] Implementation of the PEP 418

Charles-François Natali added the comment: test_process_time_threads is failing on one of the buildbots: """ == FAIL: test_process_time_threads (test.test_ti

[issue14690] Use monotonic time for sched, trace and subprocess modules

Charles-François Natali added the comment: LGTM. Juste one nitpick: why do you sometimes import the clock source as get_time() and others _time()? _time() looks fine to me. -- ___ Python tracker <http://bugs.python.org/issue14

[issue14610] configure script hangs on pthread verification and PTHREAD_SCOPE_SYSTEM verification on Ubuntu

Charles-François Natali added the comment: I'm closing as invalid. If you decide to fill a bug report to your distribution (or directly to the libc in this case), it'd be interesting to post a link to the bug report here. Thanks. -- resolution: -> invalid stage:

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Charles-François Natali added the comment: > Anybody working on this one? I’d give it a shot otherwise. Go ahead. You could - should? - probably use the new os.fwalk() to walk directories in a safe maner. -- ___ Python tracker &l

[issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count

Charles-François Natali added the comment: Well, it always boils down to the same problem: should we offer thin wrappers around underlying syscalls or offer higher-level functions? I personally think that offering mere wrappers around syscalls doesn't make much sense: Python is a very

[issue14433] Python 3 interpreter crash on windows when stdin closed in Python shell

Charles-François Natali added the comment: Martin, is there any reason not to commit your patch? -- ___ Python tracker <http://bugs.python.org/issue14

[issue14428] Implementation of the PEP 418

Charles-François Natali added the comment: > Hum, the problem is maybe that the thread is preempted, but the first > problem is that the test considers that time.process_time() uses seconds. Hum, what? You mean that process_time() doesn't ret

<    5   6   7   8   9   10   11   12   13   14   >