[issue8828] Atomic function to rename a file

Charles-François Natali added the comment: I'd prefer an optional flag to rename() too. I really don't like having different functions that achieve the same thing. It's not obvious to infer from 'replace' its real intent, since it doesn't match any standard syscall

[issue8828] Atomic function to rename a file

Charles-François Natali added the comment: > How about overwrite=[None, True] with None meaning "OS default"? +1. > One of the Python advantages is providing predictable cross-platform > behavior. If we can't introduce nice API without BC break, it is not > a r

[issue8828] Atomic function to rename a file

Charles-François Natali added the comment: > I propose quite the opposite. rename() should not overwrite existing > files by default. 1. That's not what I understood from: > os.rename(overwrite=True) to produce consistent cross-platform > behavior. 2. The above arg

[issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64 Snow Leopard 02 03.x"

Charles-François Natali added the comment: > Yes, I get a ECONNREFUSED. I tested backlog.py on FreeBSD 8.2. Thanks. I bumped the backlog, I hope it will fix this. We can leave this report open for a couple days, to see how the buildbots beh

[issue9260] A finer grained import lock

Charles-François Natali added the comment: IIUC, the deadlock avoidance code just checks that acquiring a per-module lock won't create a cycle. However, I think there's a race, because the cycle detection and the lock acquisition is not atomic. For example, let's say we have a

[issue9260] A finer grained import lock

Charles-François Natali added the comment: > That's true. Do you think temptatively acquiring the lock (without > blocking) would solve the issue? I think it should work. Something along those lines: while True: if lock.acquire(0): lock.tstate = tstate return Tr

[issue11812] transient socket failure to connect to 'localhost'

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

[issue8623] Aliasing warnings in socketmodule.c

Charles-François Natali added the comment: > This change probably should be backported to 3.2 branch. I'm not sure about this, I don't feel comfortable backporting a such path which doesn't solve a "real world problem". -- _

[issue13645] import machinery vulnerable to timestamp collisions

Charles-François Natali added the comment: The patch looks good to me. -- ___ Python tracker <http://bugs.python.org/issue13645> ___ ___ Python-bugs-list mailin

[issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64 Snow Leopard 02 03.x"

Charles-François Natali added the comment: Alright, it seems to be fixed. We can still reopen if this happens again. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: That's because SocketListener uses SO_REUSEADDR. It seems that, with SO_REUSEADDR, Windows allows binding to a port even though there's a socket already bound to the same port in the LISTEN state: this is wrong, the semantics of SO_REU

[issue9975] Incorrect use of flowinfo and scope_id in IPv6 sockaddr tuple

Charles-François Natali added the comment: Should be fixed now. Vilmos, thanks for the patch! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.o

[issue13697] python RLock implementation unsafe with signals

Charles-François Natali added the comment: The core of the problem is that we don't just want those methods to be atomic or thread-safe, but reentrant (or rather async-safe). As such, protecting by a lock isn't enough (and it's not really feasible in Python). Note

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: OK, so just removing SO_REUSEADDR on Windows should do the trick... Seriously, why can't they simply conform to existing standards :-( If someone wants to provide a patch + test, go ahead! -- ___ P

[issue13697] python RLock implementation unsafe with signals

Charles-François Natali added the comment: > That sounds like a good solution in the middle-term. Are there any > drawbacks? (apart from launching a thread) Just to be clear: the approach I was suggesting is to have a resident thread dedicated to signal management, not to spawn a new on

[issue12760] Add create mode to open()

Charles-François Natali added the comment: I've done a small review. -- ___ Python tracker <http://bugs.python.org/issue12760> ___ ___ Python-bugs-list m

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: > If the above gets solved on windows my problem will just go away, thanks Would you like to propose a patch with test? -- ___ Python tracker <http://bugs.python.org/iss

[issue13697] python RLock implementation unsafe with signals

Charles-François Natali added the comment: > Hmm, but that would break single-threaded programs which expect their > select() (or other) to return EINTR when a signal is received (which is > a perfectly valid expectation in that case). Yes, that's why I said "that"s ano

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: > Like I said, I dont know much about named pipes and im not even sure thats > how they are intended to work in this context. IE: if one process is > listening, can another listen on that named pipe as well? Under Unix, you'd get a EAD

[issue13555] cPickle MemoryError when loading large file (while pickle works)

Charles-François Natali added the comment: Antoine, could you test the last version (test_pickle and if possible with the OP testcase)? I can't test it myself (32-bit machine with 1 GB). -- ___ Python tracker <http://bugs.python.org/is

[issue13550] Rewrite logging hack of the threading module

Charles-François Natali added the comment: Alright, Nick agreed on python-dev to remove the logging hack. -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue13

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: I noticed that if bind() fails (in this case with EADDRINUSE), the socket isn't closed (FD leak). Here's a patch. -- keywords: +patch Added file: http://bugs.python.org/file24163/connection_

[issue13502] Documentation for Event.wait return value is either wrong or incomplete

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

[issue13732] test_logging failure on Windows buildbots

New submission from Charles-François Natali : Commit 57295c4d81ac879dd2d804190b38b2e91f934acd broke Windows buildbots: """ == ERROR: test_rotator (test.test_logging.Rotating

[issue12760] Add create mode to open()

Charles-François Natali added the comment: I intend to commit this patch within a couple days (unless anyone objects of course). -- stage: -> patch review ___ Python tracker <http://bugs.python.org/issu

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: Here's a possible walkfd() implementation. Example: """ $ cat /home/cf/testwalkfd.py import os import sys topfd = os.open(sys.argv[1], os.O_RDONLY) for rootfd, dirs, files in os.walkfd(topfd): print(rootfd, dir

[issue13739] os.fdlistdir() is not idempotent

New submission from Charles-François Natali : After a call to fdlistdir(), another call to fdlistdir() on the same file handle (but using a different FD, since the FD passed to fdlistdir() is closed) will return an empty list: """ $ cat ~/test_fdlistdir.py import os import sys

[issue12760] Add create mode to open()

Charles-François Natali added the comment: Here's a new version of the patch that should address all the comments. -- Added file: http://bugs.python.org/file24179/open_create_x-3.patch ___ Python tracker <http://bugs.python.org/is

[issue13739] os.fdlistdir() is not idempotent

Charles-François Natali added the comment: > For some reason, the second changeset broke the OpenIndiana buildbots: > I have absolutely no idea of why this doesn't work. I suspect rewinddir() is a noop on OpenIndiana if readdir() hasn't been called. I'll revert this comm

[issue8184] multiprocessing.managers will not fail if listening ocket already in use

Charles-François Natali added the comment: Here's a patch addressing the multiple bind() problem on Windows. Note that this problem also affects other parts of the stdlib, which use SO_REUSEADDR when available. Also, there's an rather confusing comment in support.find_u

[issue12760] Add create mode to open()

Charles-François Natali added the comment: > Just a small note: FileExistsError is raised, not exactly OSError, > when the file exists. I've updated the doc accordingly. -- stage: patch review -> commit review ___ Python

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: > Hmm, sorry, I must have misremembered. I thought openat didn't follow > symlinks. OK, I was afraid I had missed something. > As for the patch, I think there's a problem with the API Yes, it was really a proof-of-concept, the

[issue13741] *** glibc detected *** python: double free or corruption (!prev): 0x0000000001d53ad0 ***

Charles-François Natali added the comment: /usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0xd6aa)[0x7fbd27c806aa] /usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0xde51)[0x7fbd27c80e51] /usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0x13f9b)[0x7fbd27c86f9b] /usr/lib

[issue13741] *** glibc detected *** python: double free or corruption (!prev): 0x0000000001d53ad0 ***

Charles-François Natali added the comment: > I'll try Python 2.6, but this says 2.7 is supported (OOps, mixed up psyco and psycopg). Anyway, if you look at the backtrace, you'll see it segfaults inside psycopg. You should report this crash to this project. Closing.

[issue13739] os.fdlistdir() is not idempotent

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

[issue13750] queue broken when built without-thread

New submission from Charles-François Natali : Commit 190ad17f5a87481a006434a2a3d3a8e1e954a6db broke the fedora without-threads buildbot: """ ./python ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600 Traceback (most recent call last): File "/home/buildbot/build

[issue12760] Add create mode to open()

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

[issue13757] os.fdlistdir() should not close the file descriptor given in argument

New submission from Charles-François Natali : os.fdlistdir() closes the FD passed as argument. This is annoying, since in 99% of the cases you'd like to keep FD intact, so you end up doing os.fdlistdir(os.dup(fd)). Here's a patch that duplicates the FD in fdlistdir(), so that the o

[issue12760] Add create mode to open()

Charles-François Natali added the comment: Nick suggested to call the new flag "exclusive create" in the doc (and explain in whatsnew that it's based C11 new 'x' flag). Could someone please check the attached patch? My wording sounds really clumsy, so I'd pr

[issue13757] os.fdlistdir() should not close the file descriptor given in argument

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

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: Here's a patch with tests and documentation. I noticed something surprising: walk() with followlinks=False returns links to directories as directories (in dirnames). I find this surprising, since if you don't follow symlinks, those are just

[issue13734] Add a generic directory walker method to avoid symlink attacks

Charles-François Natali added the comment: Here's an updated version. Note that I'm not pushing towards changing the current behavior pertaining to symlinks to directories, because if we change this, this will break code. For example to count the number of lines of all the fil

[issue13703] Hash collision security issue

Charles-François Natali added the comment: I must be missing something, but how is raising an exception when a collision threshold is reached a good thing? Basically, we're just exchanging a DoS for another (just feed the server process with ad-hoc data and he'll commit suicide).

[issue13734] Add a generic directory walker method to avoid symlink attacks

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file24176/walkfd.diff ___ Python tracker <http://bugs.python.org/issue13734> ___ ___ Python-bug

[issue13734] Add a generic directory walker method to avoid symlink attacks

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file24197/fdwalk.diff ___ Python tracker <http://bugs.python.org/issue13734> ___ ___ Python-bug

[issue13734] Add a generic directory walker method to avoid symlink attacks

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file24202/fdwalk-1.diff ___ Python tracker <http://bugs.python.org/issue13734> ___ ___ Python-bug

[issue13734] Add a generic directory walker method to avoid symlink attacks

Changes by Charles-François Natali : Added file: http://bugs.python.org/file24211/fdwalk-2.diff ___ Python tracker <http://bugs.python.org/issue13734> ___ ___ Python-bug

[issue6774] socket.shutdown documentation: on some platforms, closing one half closes the other half

Charles-François Natali added the comment: > I was scared by the note in the documentation and wondered if the > socket Python API was completely incapable of handling half-closed > connections cross platform. [...] > It makes it half-closed as it should Indeed. Calling shut

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: I've committed the patch to 3.3. Since the documentation aspect is traced in Issue #12103, I'm closing this issue. Марк, thanks for reporting this! -- resolution: accepted -> fixed stage: commit review -> committed/rejec

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: > And apparently some buildbot doesn't like it Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-2.0.1 little-endian O_CLOEXEC support was added to Linux 2.6.23: this means that the libc defines it while th

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: The real issue is that the libc defines O_CLOEXEC, but kernels prior to 2.6.23 don't support it: instead of returning EINVAL, the socket syscall silently ignores the flag (don't know why I made the comment about this flag being de

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

Charles-François Natali added the comment: > Oh, Linux 2.6.27+ has a SOCK_CLOEXEC option: It's not exactly the same thing. We want to close the socket right after fork, not wait until exec (in the OP case there was no exec). > Patch looks fine to me. Is it easily testable?

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: > This is a kernel bug, not a bug in the GNU libc (ask Ulrich if you are not > sure ;-)). Kernels prior to 2.6.23 didn't know about the O_CLOEXEC flag: to catch this kind of problem, every syscall would have to check every bit when it

[issue12158] platform: add linux_version()

Charles-François Natali added the comment: Do we really need to expose a such Linux-centric and sparingly used function to the platform module? Since it's needed by several tests, why not add it to Lib/test/support.py? That way, we could also make it return a tuple without breaking any exi

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

Charles-François Natali added the comment: Antoine, do you think we can commit this as-is (i.e. without specific test)? If yes, to what branches (I'm not really sure of what kind of change is allowed for each branch, is there a document somewhere detailing the official p

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: @Victor Since linux_version() won't be added to the platform module, could you add it to test.support so that it can be used in the O_CLOEXEC test? -- ___ Python tracker <http://bugs.python.org/is

[issue12105] open() does not able to set flags, such as O_CLOEXEC

Charles-François Natali added the comment: Checking the kernel version did the trick, the test now run fines on the buildbots. Thanks Victor. Re-closing. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issu

[issue8407] expose signalfd(2) and pthread_sigmask in the signal module

Charles-François Natali added the comment: > New changeset f8c49a930015 by Victor Stinner in branch 'default': > Issue #8407: The signal handler writes the signal number as a single byte > http://hg.python.org/cpython/rev/f8c49a930015 There's a race. If a signal is rece

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

Charles-François Natali added the comment: > You change caused test_socketserver to hang. I attempted a fix, but I'm not > sure if it's completely correct. I'm a morron. I don't know how I could miss this: closing the server socket is perfectly fine in TCP, sinc

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

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

[issue1441530] socket read() can cause MemoryError in Windows

Charles-François Natali added the comment: I've committed the patch to 2.7, and also to default (and only to default since for py3k it's more of an optimization than a bug fix). Closing. -- resolution: -> fixed stage: patch review -> committed/rejected status

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

Charles-François Natali added the comment: So, SOCK_CLOEXEC is available. Note that I don't like the idea of falling back to FD_CLOEXEC since it's not atomic, and some people might rely on this. Can we close this issue? -- ___ Python trac

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

Charles-François Natali added the comment: Since it's a OOM issue, can we close? -- ___ Python tracker <http://bugs.python.org/issue12071> ___ ___ Pytho

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

Charles-François Natali added the comment: > Well, this is apparently a feature request for socketserver.TCPServer. Honestly, I'm not sure what this request is about. The original request seemed to imply this should be made the default. I don't agree, and think this should be

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: It's an unaligned access: addr=0x21007b72c case T_LONGLONG: v = PyLong_FromLongLong(*(PY_LONG_LONG *)addr); sizeof(PY_LONG_LONG) == 8, but addr % 8 = 0x21007b72c % 8 == 4 -- nosy: +charles-francois.n

[issue12181] SIGBUS error on OpenBSD (sparc64)

Changes by Charles-François Natali : -- nosy: +mark.dickinson ___ Python tracker <http://bugs.python.org/issue12181> ___ ___ Python-bugs-list mailing list Unsub

[issue12184] socketserver.ForkingMixin collect_children routine needs to collect only it's children

Charles-François Natali added the comment: In the common case, I don't think that the os.waitpid(0, 0) is the hot spot, but rather this: for child in self.active_children: os.waitpid(child, os.WNOHANG) It's called every time, and it's O(number of active children). os.w

[issue12184] socketserver.ForkingMixin collect_children routine needs to collect only it's children

Charles-François Natali added the comment: Some precisions: 1) Of course, if a handler changes its process group through setsid/setpgrp, it won't be waited on. 2) If a handler running on behalf of a process which is the current process group leader calls setsid, it will get an EPERM err

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: OpenBSD's struct kevent definition looks fishy: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/event.h?rev=1.15;content-type=text%2Fplain struct kevent { u_int ident; /* identifier for this event */

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: > ident and data are not pointers, That's not the point. struct kevent declaration should be the following: struct kevent { uintptr_t ident;/* identifier for this event */ short filter; /* filter f

[issue12191] Shutil - add chown() in order to allow to use user and group name (and not only uid/gid)

Charles-François Natali added the comment: I didn't test, but after skimming through the code I think that if an invalid user name/group name is provided, os.chown is passed None, which will fail with ValueError. It would be better to raise an explicit error like "no such user&q

[issue12190] intern filenames in bytecode

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22136/unnamed ___ Python tracker <http://bugs.python.org/issue12190> ___ ___ Python-bug

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: Hello Nicholas, > kqueue is not standardized. You're probably right, but depending on the version of your manpages, the definition changes: http://www.openbsd.org/cgi-bin/man.cgi?query=kevent&apropos=0&sektion=0&manpath=OpenBSD+

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: Concerning the differences between platforms, as noted, FreeBSD, NetBSD and OS-X are all consistent and I don't think it'll change tomorrow, so for now it's not a problem. Arbitrarily changing such structures definition - event tho

[issue12196] add pipe2() to the os module

New submission from Charles-François Natali : pipe2() makes it possible to create a pipe O_CLOEXEC or O_NONBLOCK atomically, which can be quite useful, especially in multi-threaded code. It would be nice to expose it in the os module. Patch attached. -- components: Library (Lib) files

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: > Do you want to call the function with two arguments or one tuple with 2 > items? You may test both :-) The former. Fixed. > Hum, I'm not sure that it's revelant to test the time I didn't like it either, I just reused wh

[issue12196] add pipe2() to the os module

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

[issue12196] add pipe2() to the os module

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

[issue12196] add pipe2() to the os module

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

[issue12196] add pipe2() to the os module

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

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: > +# A constant likely larger than the underlying OS pipe buffer size. > +# Windows limit seems to be around 512B, and most Unix kernels have a 64K > pipe > +# buffer size: take 1MB to be sure. > +PIPE_MAX_SIZE = 1024 * 1024 > &g

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: > Out of interest, is there any reason that the configure check for pipe2 is a > special case near the bottom of configure.in instead of with all the other > function checks in the AC_CHECK_FUNCS[] section in the middle? No clue. I&#x

[issue12196] add pipe2() to the os module

Changes by Charles-François Natali : -- nosy: +gregory.p.smith ___ Python tracker <http://bugs.python.org/issue12196> ___ ___ Python-bugs-list mailing list Unsub

[issue12196] add pipe2() to the os module

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

[issue12196] add pipe2() to the os module

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22151/support_pipe_max.diff ___ Python tracker <http://bugs.python.org/issue12196> ___ ___

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: > I just nuked the pure Python POSIX subprocess implementation Nice. I've updated both patches to address Victor's comments on test_io and test_subprocess usage of PIPE_MAX_SIZE, and Ross' comment on pipe2's configure tests

[issue12157] join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty

Charles-François Natali added the comment: When map is called, a MapResult object is created, which adds itself to the Pool's result cache. When the pool is shut down, the result handler thread waits until the cache drains (while cache and thread._state != TERMINATE). But since no resu

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: The Gentoo buildbot on which O_CLOEXEC test failed also chokes on test_pipe2: [ 10/355] test_posix test test_posix failed -- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_posix.py&q

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: The test now runs fine on the buildbots, closing. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: > support.linux_version() may be changed for requires_linux_version(2, 6, 27), > > but linux_version() is always used in tests to check the Linux version. > requires_linux_version() would only raise a SkipTest if the OS is Linux and >

[issue12021] mmap.read requires an argument

Charles-François Natali added the comment: The patch looks good to me. In your test, you don't explicitely close the mmap object: it's not a problem with CPython since it will get unmmapped, and the file descriptor - if it's a file-backed mapping - will get closed, as soon as

[issue12021] mmap.read requires an argument

Charles-François Natali added the comment: > I noticed that RawIOBase.read, TextIOBase.read, etc also accept None as the > argument, treating it as -1. Should this be implemented, too? > That's because of the _PyIO_ConvertSsize_t converter, which silently converts None to -1. Th

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: > I like your patch, it removes many duplicate code :-) > > Some comments: Patch attached. > Doc/whatsnew/3.3.rst Patch attached. -- Added file: http://bugs.python.org/file22209/pipe2_whatsnew.diff Added file: http://bug

[issue6560] socket sendmsg(), recvmsg() methods

Charles-François Natali added the comment: > What needs to happen to get recvmsg() supported in Python? Well, I guess that the only reason is that no committer is motivated enough to bring this into Python: it's a rather large patch, and honestly, I'm not sure that many people are

[issue8407] expose signalfd(2) and pthread_sigmask in the signal module

Charles-François Natali added the comment: > The wakeup fd now contains the number of each signal, and so the behaviour has > to change. I applied your patch and I added a test. Interesting. I suspected this would have an impact on the test_signal failure on the FreeBSD 6.4 b

[issue12235] subprocess.check_output throws wrong exception if non executable

Charles-François Natali added the comment: Python is not raising this error, your OS is. It doesn't find the interpreter, and if you look carefully, it's clear why: bash: ***/src/webapp/tools/grab.sh: /bin/sh^M: bad interpreter: No such file or directory See the ^M after /bin/sh?

[issue12235] subprocess loses stderr information when _execute_child fails

Charles-François Natali added the comment: > I think it should at least include "bad interpreter", otherwise it is a tad > misleading. It just forwards the error raised by the exec system call: $ cat foo.sh #! /bin/foo $ strace ./foo.sh execve("./foo.sh",

[issue12196] add pipe2() to the os module

Charles-François Natali added the comment: > requires_linux_version() should also be a decorator. Patch attached. -- Added file: http://bugs.python.org/file22219/support_linux_version.diff ___ Python tracker <http://bugs.python.org/issu

[issue1495802] cygwin: popen3 lock up

Charles-François Natali added the comment: It's not a bug. so.readlines reads the subprocess' stdout until EOF is encountered, but in the meantime, if it writes a lot to stderr, the corresponding pipe fills up, and the subprocess blocks on the write. You should use Popen's com

[issue5384] mmap and exception type

Charles-François Natali added the comment: Here's a patch. -- keywords: +needs review, patch nosy: +charles-francois.natali, haypo stage: -> patch review versions: +Python 3.3 -Python 2.7, Python 3.1 Added file: http://bugs.python.org/file0/mmap_excepti

<    1   2   3   4   5   6   7   8   9   10   >