[issue28663] Higher virtual memory usage on recent Linux versions

[ProgVal]

ProgVal added the comment:

first command:
(0, 0)
0.14user 0.01system 0:00.94elapsed 16%CPU (0avgtext+0avgdata 18484maxresident)k
560inputs+0outputs (0major+2702minor)pagefaults 0swaps

second command:
(6663744, 6732519)
0.18user 0.01system 0:00.96elapsed 20%CPU (0avgtext+0avgdata 22572maxresident)k
480inputs+0outputs (2major+4081minor)pagefaults 0swaps

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex

[Mark Dickinson]

Mark Dickinson added the comment:

Thanks, Tom. Re-opening.

--
resolution: postponed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28663] Higher virtual memory usage on recent Linux versions

[INADA Naoki]

INADA Naoki added the comment:

On Linux 3.16? 4.7?  What is difference between 3.16 and 4.7?

Again, I doubt Python's memory consumption increased by Linux version.
Isn't rlimit more strict for now?

Even if memory usage is really grow, I don't think it's a Python's issue.
Maybe, environment issue or kernel issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28663] Higher virtual memory usage on recent Linux versions

[ProgVal]

ProgVal added the comment:

> On Linux 3.16? 4.7?  What is difference between 3.16 and 4.7?

On 4.8 (which has the same issue as 4.7).
The difference is that on 4.7, the rlimit has to be set incredibly high for the 
child process not to hit the limit.

> Again, I doubt Python's memory consumption increased by Linux version.
> Isn't rlimit more strict for now?

That's what I think too, because I would have noticed if the interpreter 
actually started using 20MB for such a simple operation.

> Even if memory usage is really grow, I don't think it's a Python's issue.
> Maybe, environment issue or kernel issue.

I agree. But I don't know how to reproduce this issue without 
multiprocessing.Queue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28180] sys.getfilesystemencoding() should default to utf-8

[Xavier de Gaye]

Xavier de Gaye added the comment:

> On Android, setlocale(CATEGORY, "") does not look for the locale environment 
> variables (LANG, ...) but sets the 'C' locale instead

FWIW the source code of setlocale() on bionic (Android libc) is at 
https://android.googlesource.com/platform/bionic/+/master/libc/bionic/locale.cpp#144

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29342] os.posix_fadvise misreports errors

[Marian Beermann]

New submission from Marian Beermann:

It has been observed that posix_fadvise will not report the original error if 
the syscall fails. Eg. https://bugs.alpinelinux.org/issues/6592

>>> os.posix_fadvise(-1, 0, 0, os.POSIX_FADV_DONTNEED)
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 0] Error

Should report EBADF

>>> os.posix_fadvise(16, 0, 0, os.POSIX_FADV_DONTNEED)
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 0] Error

Ditto

>>> os.posix_fadvise(0, 0, 0, 12345)
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 0] Error

Should be EINVAL

...

This might be because unlike most syscall wrappers posix_fadvise does not set 
errno but only returns it.

--
components: IO, Library (Lib)
messages: 286002
nosy: enkore
priority: normal
severity: normal
status: open
title: os.posix_fadvise misreports errors
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29342] os.posix_fadvise misreports errors

[Marian Beermann]

Marian Beermann added the comment:

Indeed, os.posix_fadvise tries to fetch the error from errno, via posix_error()

static PyObject *
os_posix_fadvise_impl(PyObject *module, int fd, Py_off_t offset,
  Py_off_t length, int advice)
/*[clinic end generated code: output=412ef4aa70c98642 input=0fbe554edc2f04b5]*/
{
int result;
int async_err = 0;

do {
Py_BEGIN_ALLOW_THREADS
result = posix_fadvise(fd, offset, length, advice);
Py_END_ALLOW_THREADS
} while (result != 0 && errno == EINTR &&
 !(async_err = PyErr_CheckSignals()));
if (result != 0)
return (!async_err) ? posix_error() : NULL;
Py_RETURN_NONE;
}

--^ posix_error() using errno not result

posix_fallocate has the same caveat and mishandles errors as well:

static PyObject *
os_posix_fallocate_impl(PyObject *module, int fd, Py_off_t offset,
Py_off_t length)
/*[clinic end generated code: output=73f107139564aa9d input=d7a2ef0ab2ca52fb]*/
{
int result;
int async_err = 0;

do {
Py_BEGIN_ALLOW_THREADS
result = posix_fallocate(fd, offset, length);
Py_END_ALLOW_THREADS
} while (result != 0 && errno == EINTR &&
 !(async_err = PyErr_CheckSignals()));
if (result != 0)
return (!async_err) ? posix_error() : NULL;
Py_RETURN_NONE;
}

--^ posix_error() using errno not result

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29343] sock.close() raises OSError EBADF when socket's fd is closed

[Christian Heimes]

New submission from Christian Heimes:

In Python 3.6 the behavior of socket's close method has changed. In Python 2.7, 
3.5 and earlier, socket.close() ignored EBADF. Starting with Python 3.6 
socket.close() raises an OSError exception when its internal fd has been closed.

Python 2.7.12 (default, Sep 29 2016, 12:52:02) 
[GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, socket
>>> sock = socket.socket()
>>> os.close(sock.fileno())
>>> sock.close()

Python 3.5.2 (default, Sep 14 2016, 11:28:32) 
[GCC 6.2.1 20160901 (Red Hat 6.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket()
>>> import os, socket
>>> os.close(sock.fileno())
>>> sock.close()

Python 3.6.0+ (3.6:ea0c488b9bac, Jan 14 2017, 14:08:17) 
[GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, socket
>>> sock = socket.socket()
>>> os.close(sock.fileno())
>>> sock.close()
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/heimes/dev/python/python36/lib/python3.6/socket.py", line 417, in 
close
self._real_close()
  File "/home/heimes/dev/python/python36/lib/python3.6/socket.py", line 411, in 
_real_close
_ss.close(self)
OSError: [Errno 9] Bad file descriptor


Abstraction layers such as the socket class should ignore EBADF in close(). A 
debug message or a warning is ok, but an exception is wrong. Even the man page 
for close discourages it, http://man7.org/linux/man-pages/man2/close.2.html

   Note, however, that a failure return should be used only for
   diagnostic purposes (i.e., a warning to the application that there
   may still be I/O pending or there may have been failed I/O) or
   remedial purposes (e.g., writing the file once more or creating a
   backup).

--
components: Library (Lib)
keywords: 3.6regression
messages: 286004
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: sock.close() raises OSError EBADF when socket's fd is closed
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28999] Use Py_RETURN_NONE and like

[INADA Naoki]

INADA Naoki added the comment:

While patch looks safe, some developer may dislike such a large patch
without fixing real issue.

Anyway, Coccinelle seems very interesting tool for refactoring.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29284] Include thread_name_prefix in the concurrent.futures.ThreadPoolExecutor example 17.4.2.1

[John Taylor]

John Taylor added the comment:

I have updated the Python 3.6 example for 17.4.2.1. ThreadPoolExecutor Example. 
 Please see the attachment.  On my system this is the output:

thread name: loader_0
thread name: loader_1
thread name: loader_2
thread name: loader_3
thread name: loader_4
'http://example.com/' page is 1270 bytes
'http://www.foxnews.com/' page is 67351 bytes
'http://www.cnn.com/' page is 137164 bytes
'http://europe.wsj.com/' page is 914169 bytes
'http://www.bbc.co.uk/' page is 229503 bytes

Could you please consider adding this to the official documentation?

--
Added file: http://bugs.python.org/file46377/ThreadPoolExec_Example.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28999] Use Py_RETURN_NONE and like

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

That is why I haven't pushed the patch. Thanks you for your LGTMs Victor and 
Inada, but this is not enough.

In general I think that it is better to use Py_RETURN_NONE than 
"Py_INCREF(Py_None); return Py_None;". Some replacements already was done in 
the past, and some currently reviewed patches include also such changes. This 
can distract attention from the main purpose of patches. I think that pushing 
all changes in one big commit will make less harm than add small changes in 
other patches here and there. Concinelle proved his reliability and it is easy 
to check these changes.

I'll push this patch if Raymond or other more conservative core developers 
accept it (or selected parts of it).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28876] bool of large range raises OverflowError

[Akira Li]

Akira Li added the comment:

Following the python-dev discussion [1] I've added a variant of the patch that 
uses c99 designated initializers [2]

[1] https://mail.python.org/pipermail/python-dev/2017-January/147175.html
[2] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

--
Added file: 
http://bugs.python.org/file46378/range_bool-c99-designated-initializers.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29343] sock.close() raises OSError EBADF when socket's fd is closed

[Antoine Pitrou]

Antoine Pitrou added the comment:

Closing a socket whose fd has already been closed before is a bug waiting to 
happen.  Indeed it feels harmless if you just get a EBADF, but if the given fd 
gets reused in the meantime for another file or socket, your close() method is 
going to close a resource which doesn't belong to the socket (and then the fd 
can be reused for yet another resource without its owner knowing, and 
confusion/hilarity ensues).

--
nosy: +neologix, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29343] sock.close() raises OSError EBADF when socket's fd is closed

[Martin Panter]

Martin Panter added the comment:

I added this behaviour in 3.6 on purpose via Issue 26685.

The change also impacted Yury (see the original bug thread), but if I 
understood correctly, he eventually decided that it highlighted a problem in 
asyncio or his code (though the resulting asyncio pull request seems to have 
stalled). Before he came to that decision, I did suggest temporarily using 
DeprecationWarning instead of an exception: 
.

IMO passing a freed file descriptor to close() is asking for trouble. The 
descriptor could be recycled, by another thread, or even internally by a 
function call in the same thread. Another problem is if you don’t end up 
calling socket.close(), the garbage collector may arbitrarily close an FD in 
use in the future.

Your example code was not realistic, but I would say the solution is either 
call socket.detach() rather than socket.fileno(), or don’t call os.close() and 
just call socket.close().

I think that Linux man page is talking more about asynchronous errors from a 
previous write call. Even if we tolerated other errors from close(), I would 
still like to treat EBADF as a real error.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29344] sock_recv not detected a coroutine

[Jeremy Bustamante]

New submission from Jeremy Bustamante:

Documemtation says sock_recv is a coroutine
https://docs.python.org/3.6/library/asyncio-eventloop.html#low-level-socket-operations

But following code says it isnt:

import asyncio
loop = asyncio.get_event_loop()

asyncio.iscoroutinefunction(loop.sock_recv)
False

asyncio.iscoroutine(loop.sock_recv)
False

--
components: asyncio
messages: 286011
nosy: Jeremy Bustamante, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: sock_recv not detected a coroutine
type: behavior
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

Above said, I updated minor changes to the version 2 patch.  Several codes have 
kept the words "thread local" and "TLS" because they have pointed programming 
method or other meanings, not CPython TLS API itself. (e.g. _decimal module)

--
Added file: http://bugs.python.org/file46379/pythread-tss-3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29058] Mark new limited C API

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Do you suggest to emit a warning when the user just defines Py_LIMITED_API 
without specifying concrete version?

#define Py_LIMITED_API

I think this would break too much code. And contradicts to the documentation.

If you mean something different, could you provide a patch?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29084] C API of OrderedDict

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Eric, what are your thoughts?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29345] More lost updates with multiprocessing.Value and .Array

[Just a Person]

New submission from Just a Person:

Lately, I have been having trouble using the multiprocessing library's shared 
memory on Windows. Often, updating the .value property seems to fail for no 
reason. As shown in the attached video, changing ```if __name__ == 
'__main__':``` in the sample code from the documentation to  ```if True:``` 
causes the program to not work.

This issue does not arise under Linux as far as I can tell (testing the same 
code).

Any explanation/fix would be helpful.

--
components: Windows
files: 2017-01-22-1140-25.mp4
messages: 286015
nosy: Just a Person, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: More lost updates with multiprocessing.Value and .Array
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file46380/2017-01-22-1140-25.mp4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27973] urllib.urlretrieve() fails on second ftp transfer

[Senthil Kumaran]

Senthil Kumaran added the comment:

I spent time digging for a proper fix for this issue.

I've come to a conclusion that this commit, 
https://hg.python.org/cpython/rev/44d02a5d59fb (10 May 2016) in 2.7.12, was a 
mistake and needs to be reverted.

The reason this change was made was apparently, it fixed a particular problem 
with retrieving files in 3.x, and the change was backported (issue26960). It 
was reported and fixed in 3.x code line here http://bugs.python.org/issue16270 
(This is an improper change too and it needs to be reverted, we will come to it 
at the end [3].

Why is this a problem?

1. The change made was essentially taking the logic of draining ftp response 
from endtransfer method. Historically, in the module, endtransfer() has been 
used before closing the connection and it is correct to drain response 
(voidresp() method call).

2. If we don't drain responses, we end up with problems like the current 
(issue27973) bug report.

3. The problem with issue16270 was the fail transfer failed only when urllopen 
was used as a context manager (which calls close implicitly on the same host). 
But ftp scenarios were designed for reusing the same host without calling close 
from a long time (3a) and context manager scenario is not applicable to 2.7 
code (3b).

Here are some references on how the module shaped up:
 
3a. https://hg.python.org/cpython/rev/6e0eddfa404a - it talks about repeated 
retriving of the same file from host without closing as a feature.

3b. The urllopen context manager was applicable only in 3.x so the original 
problem of issue16270 was not reproducible in 2.7 and it was improper to 
backport those changes (issue26960). Even issue16270 it is improper to change 
the code in endtransfer, because the problem is specific with context-manager 
usecase of urlopen, regular usage is just fine.

This patch fixes the problem for 2.7. I have included tests in test_urllibnet 
to cover the scenarios that were reported. Please review this.

For 3.x code, I will reopen issue16270, I will port this patch with test cases 
and an additional case for context manager scenario.

--
Added file: http://bugs.python.org/file46381/issue27973.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29336] merge tuples in module

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Removed file: http://bugs.python.org/file46371/merge-constants.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29336] merge tuples in module

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file46382/merge-constants.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29345] More lost updates with multiprocessing.Value and .Array

[Davin Potts]

Davin Potts added the comment:

I'm having difficulty watching your video attachment.  Would it be possible to 
instead describe, preferably with example code that others can similarly try to 
reproduce the behavior, what you're experiencing?

Please keep in mind what the documentation repeatedly advises about the need 
for capturing your process-creating multiprocessing calls inside a "if __name__ 
== '__main__'" clause, especially on Windows platforms.

--
nosy: +davin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29083] Readd PyArg_VaParse to the stable API

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

There are also issues with PyArg_ValidateKeywordArguments(), 
PyArg_UnpackTuple() and Py_BuildValue(). Their declarations are not available 
if define PY_SSIZE_T_CLEAN and Py_LIMITED_API < 3.3. But they were available in 
Python 3.2.

Proposed patch fixes these glitches.

--
assignee:  -> serhiy.storchaka
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file46383/PyArg_VaParse-limited-api.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29345] More lost updates with multiprocessing.Value and .Array

[Eryk Sun]

Eryk Sun added the comment:

Change the last print to test the exit code, as follows:

if p.exitcode != 0:
print('Child failed with exit code:', p.exitcode)
else:
print(num.value)
print(arr[:])

Note that when you fail to limit creating a new process to just the "__main__" 
script, the child process ends up failing. Run it in a command prompt to see 
the following RuntimeError from the child:

RuntimeError:
An attempt has been made to start a new process before the
current process has finished its bootstrapping phase.

This probably means that you are not using fork to start your
child processes and you have forgotten to use the proper idiom
in the main module:

if __name__ == '__main__':
freeze_support()
...

The "freeze_support()" line can be omitted if the program
is not going to be frozen to produce an executable.

Since there's no fork() in the Windows API (the NT kernel actually implements 
forking for other subsystems such as the old POSIX system and the new Linux 
system, but the Windows API wasn't designed for it), multiprocessing has to 
import the main script in a new process, in which case the __name__ is not 
"__main__". But since you're not checking the __name__, it ends up trying to 
start another Process instance. You're lucky that this API has been made smart 
enough to detect this. It used to blow up recursively creating processes.

--
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16270] urllib hangs when closing connection

[Senthil Kumaran]

Senthil Kumaran added the comment:

The original problem here was retrieving files failed (hung) when it was tried 
via context-manager

1. For e.g after "reverting" the changes, if you use the original file without 
the context manager, it will succeed.

fobj = urllib.request.urlopen( url )

That indicates the fix in changing something in endtransfer method was 
improper. I have given more information here: 
http://bugs.python.org/issue27973#msg286016

The proper fix will be revert the endtransfer changes, but fix it in 
contextmanager scenario. Add test cases to cover all these scenarios.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29346] datetime.utcfromtimestamp() returns strange result for very large values

[Eli Collins]

New submission from Eli Collins:

I've found an odd behavior when passing very large values to 
``datetime.datetime.utcfromtimestamp()`` and ``.fromtimestamp()`` under python 
3.6.

Under python 3.5, ``utcfromtimestamp(1<<40)`` would throw a ValueError that the 
year was out of range.  Under python 3.6, this now returns a datetime in year 
36812 (which seems reasonable given the input).  

The unexpected behavior occurs when increasing the bits passed:   
``utcfromtimestamp(1<<41)`` returns a datetime with a *smaller* year (6118).  
This pattern proceeds as the bits are increased, with the years increasing & 
then wrapping around again, up to the point where it exceeds time_t (at that 
point, python 3.6 throws the same OSError as 3.5).

It looks to me like 3.6 dropped a bounds check somewhere, and is now truncating 
high bits off the resulting year?

---

Attached is the "dump_timestamp_output.py" script that I was using to examine 
boundary behavior of utctimestamp() when I found this bug.

System was running Linux Mint 18.1 x86_64, using the python 3.6.0 build from 
https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes (ubuntu's python 3.6.0 
build also shows this behavior).

--
components: Library (Lib)
files: dump_timestamp_output.py
messages: 286021
nosy: Eli Collins
priority: normal
severity: normal
status: open
title: datetime.utcfromtimestamp() returns strange result for very large values
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file46384/dump_timestamp_output.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] Python 2.7 subprocess module does not check WIFSTOPPED on SIGCHLD

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
versions: +Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] Python 2.7 subprocess module does not check WIFSTOPPED on SIGCHLD

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
assignee:  -> gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] subprocess module does not check WIFSTOPPED on SIGCHLD

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
title: Python 2.7 subprocess module does not check WIFSTOPPED on SIGCHLD -> 
subprocess module does not check WIFSTOPPED on SIGCHLD

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29345] More lost updates with multiprocessing.Value and .Array

[Eryk Sun]

Eryk Sun added the comment:

>if p.exitcode != 0:
>print('Child failed with exit code:', p.exitcode)

Interestingly the exit code is always 1 when running under pythonw.exe. I just 
inspected what's going on by setting sys.stderr to a file and discovered the 
following issue:

  File "C:\Program Files\Python35\lib\multiprocessing\process.py", line 
268, in _bootstrap
sys.stdout.flush()
AttributeError: 'NoneType' object has no attribute 'flush'

Calling flush() on stderr and stdout should be gated by a check that they're 
not None and have a flush method. Or simply ignore the AttributeError.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29346] datetime.utcfromtimestamp() returns strange result for very large values

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +belopolsky, lemburg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] subprocess module does not check WIFSTOPPED on SIGCHLD

[Gregory P. Smith]

Gregory P. Smith added the comment:

The attached patch should fix it.

I want to incorporate a bug.py like regression test into test_subprocess.py.

--
keywords: +patch
stage:  -> test needed
Added file: http://bugs.python.org/file46385/issue29335-gps01.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29058] Mark new limited C API

[Steve Dower]

Steve Dower added the comment:

I don't care enough to argue about it with you. Let's just fix the API as soon 
as we can and apologize to people who hit inconsistencies in earlier versions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29346] datetime.utcfromtimestamp() returns strange result for very large values

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

According to the datetime.h file, the valid range for year is 1-, so it's a 
bit surprising that Python 3.6 allows dates outside this range.

Internally, the year is represented using 2 bytes, so you could represent years 
outside the range and up to 65535 as well.

Here's what mxDateTime outputs for the given timestamps:

 >>> from mx.DateTime import *
 >>> DateTimeFromTicks(1<<40)

 >>> DateTimeFromTicks(1<<41)


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29058] Mark new limited C API

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *"

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Stefan, what are your thoughts about this? The patch touches _decimal.c.

--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28749] Fixed the documentation of the mapping codec APIs

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

How can we move this issue forward? Marc-Andre, have I answered to your 
objections?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17720] pickle.py's load_appends should call append() on objects other than lists

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

>From PEP 7:

listitemsOptional, and new in this PEP.
 If this is not None, it should be an iterator (not a
 sequence!) yielding successive list items.  These list
 items will be pickled, and appended to the object using
 either obj.append(item) or obj.extend(list_of_items).
 This is primarily used for list subclasses, but may
 be used by other classes as long as they have append()
 and extend() methods with the appropriate signature.
 (Whether append() or extend() is used depends on which
 pickle protocol version is used as well as the number
 of items to append, so both must be supported.)

Both append() or extend() must be supported, therefore old code was correct. C 
implementation can be optimized by using extend().

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *"

[Stefan Krah]

Stefan Krah added the comment:

For _decimal I'm happy with just the cast from the first patch -- you have a 
one line diff and it's easy to see the focus of the issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *"

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *"

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0d89212941f4 by Serhiy Storchaka in branch 'default':
Issue #28769: The result of PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8()
https://hg.python.org/cpython/rev/0d89212941f4

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *"

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29196] Remove old-deprecated plistlib features

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> ronaldoussoren

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] subprocess module does not check WIFSTOPPED on SIGCHLD

[Gregory P. Smith]

Gregory P. Smith added the comment:

test added.

--
stage: test needed -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file46386/issue29335-gps02.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29284] Include thread_name_prefix in the concurrent.futures.ThreadPoolExecutor example 17.4.2.1

[Davin Potts]

Changes by Davin Potts :


--
nosy: +davin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29136] Add OP_NO_TLSv1_3

[Christian Heimes]

Christian Heimes added the comment:

memo to me: Update the TLS cipher list to include TLS 1.3 ciphers. TLS 1.3 uses 
a disjunct set of cipher suites. No member of the current cipher suite set is 
compatible with TLS 1.3. Handshake with TLS 1.3 enabled servers is going to 
fail.

As of today OpenSSL 1.1.1-dev provides one of five TLS 1.3 ciphers: 
TLS13-AES-128-GCM-SHA256. TLS13-AES-256-GCM-SHA384 and TLS13-CHACHA20-POLY1305 
are not yet implemented as are CCM block mode.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

[desbma]

desbma added the comment:

Ping

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

[Ned Deily]

Changes by Ned Deily :


--
nosy: +bquinlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29346] datetime.utcfromtimestamp() returns strange result for very large values

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

This looks like a duplicate of issue #29100 ("datetime.fromtimestamp() doesn't 
check min/max year anymore: regression of Python 3.6").

--
keywords: +3.6regression
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

[INADA Naoki]

INADA Naoki added the comment:

I don't think this is a regression, bug, bogos naming.

I agree that "_0" is ugly.
But the name describes what is the thread, than "Thread-1".

How about giving default thread_name_prefix less ugly?
e.g. "ThreadPoolExecutor-worker".

--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] subprocess module does not check WIFSTOPPED on SIGCHLD

[Roundup Robot]

Roundup Robot added the comment:

New changeset 269296b2a047 by Gregory P. Smith in branch '3.5':
Issue #29335: Fix subprocess.Popen.wait() when the child process has
https://hg.python.org/cpython/rev/269296b2a047

New changeset ed5255a61648 by Gregory P. Smith in branch '3.6':
Issue #29335: Fix subprocess.Popen.wait() when the child process has
https://hg.python.org/cpython/rev/ed5255a61648

New changeset 4f5e7d018195 by Gregory P. Smith in branch 'default':
Issue #29335: Fix subprocess.Popen.wait() when the child process has
https://hg.python.org/cpython/rev/4f5e7d018195

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

[Eric Lafontaine]

Eric Lafontaine added the comment:

Hi,

I've implemented the heuristic, but it's messy with the issue of this ticket. 

I'm going to do some clean-up and separate the issue from the heuristic and 
post them separated.

Date issue ;
Test Case
Documentation
Implementation

Heuristic of Resent ;
Test Case
Documentation
Implementation


Regards,
Eric Lafontaine

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28556] typing.py upgrades

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7bf6b4fe2c3c by Guido van Rossum in branch '3.5':
Issue #28556: various style fixes for typing.py
https://hg.python.org/cpython/rev/7bf6b4fe2c3c

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28556] typing.py upgrades

[Roundup Robot]

Roundup Robot added the comment:

New changeset f100619e7137 by Guido van Rossum in branch '3.5':
Issue #28556: Allow defining methods in NamedTuple class syntax (#362)
https://hg.python.org/cpython/rev/f100619e7137

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28556] typing.py upgrades

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4121755d by Guido van Rossum in branch '3.6':
Issue #28556: various style fixes for typing.py (3.5->3.6)
https://hg.python.org/cpython/rev/4121755d

New changeset a7e69479ee22 by Guido van Rossum in branch 'default':
Issue #28556: various style fixes for typing.py (3.6->3.7)
https://hg.python.org/cpython/rev/a7e69479ee22

New changeset ba272f947c40 by Guido van Rossum in branch '3.6':
Issue #28556: Allow defining methods in NamedTuple class syntax (#362) 
(3.5->3.6)
https://hg.python.org/cpython/rev/ba272f947c40

New changeset 69c5b800df86 by Guido van Rossum in branch 'default':
Issue #28556: Allow defining methods in NamedTuple class syntax (#362) 
(3.6->3.7)
https://hg.python.org/cpython/rev/69c5b800df86

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28635] Update What's New for 3.6

[Guido van Rossum]

Guido van Rossum added the comment:

Can this be closed (since 3.6 has been released)? Or is there still more you'd 
like to do specifically to complete this issue?

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

[Xiang Zhang]

Changes by Xiang Zhang :


--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28635] Update What's New for 3.6

[Elvis Pranskevichus]

Elvis Pranskevichus added the comment:

I'm pretty sure we're done with What's New for 3.6.0, so, unless it's worth 
keeping this open for any 3.6.x edits, I'm for closing this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29314] asyncio.async deprecation warning is missing stacklevel=2

[INADA Naoki]

INADA Naoki added the comment:

LGTM.

--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29314] asyncio.async deprecation warning is missing stacklevel=2

[INADA Naoki]

Changes by INADA Naoki :


--
stage: needs patch -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29347] Python 2.7.8 is crashing while creating weakref for a given object.

[Saida Dhanavath]

New submission from Saida Dhanavath:

We are using python 2.7.8 on Ubuntu 14.04 to host our services. In one of the 
crashes python interpreter got segmentation fault while initializing weakref 
for a given object. Please find snip of backtraces as given below.

#0  0x7f62aa86951a in clear_weakref (self=0x7f5a1ed17520) at 
Objects/weakrefobject.c:65
#1  proxy_dealloc (self=0x7f5a1ed17520) at Objects/weakrefobject.c:540
#2  0x7f62aa869b8b in PyWeakref_NewProxy (ob=, 
callback=) at Objects/weakrefobject.c:855
#3  0x7f62aa901e56 in weakref_proxy (self=, args=) at ./Modules/_weakref.c:73
#4  0x7f62aa8a929b in call_function (oparg=, 
pp_stack=0x7f5d36661c90) at Python/ceval.c:4033
.
.
.


Have tried to root cause the issue and found that 
PyWeakref_NewProxy@Objects/weakrefobject.c creates new isntance of 
PyWeakReference struct and does not intialize wr_prev and wr_next of new 
isntance. These pointers can have garbage and point to random memory locations. 

As per comment in the code there could be a race while creating new instance 
and some other thread could have created weakref by the time current thread 
returns from new_weakref function. If it finds weakref created, current thread 
destroys instance created by itself and uses the one created by some other 
thread.


Python should not crash while destroying the isntance created in the same 
interpreter function. As per my understanding, both wr_prev and wr_next of 
PyWeakReference instance should be initialized to NULL to avoid segfault.

--
components: Interpreter Core
messages: 286044
nosy: dhanavaths
priority: normal
severity: normal
status: open
title: Python 2.7.8 is crashing while creating weakref for a given object.
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29347] Python 2.7.8 is crashing while creating weakref for a given object.

[Saida Dhanavath]

Changes by Saida Dhanavath :


--
type:  -> crash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28635] Update What's New for 3.6

[Ned Deily]

Ned Deily added the comment:

I don't see any reason to keep this open.  Thanks so much, Elvis and Yury, for 
doing such a great job again!

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] subprocess module does not check WIFSTOPPED on SIGCHLD

[Ned Deily]

Ned Deily added the comment:

Among other buildbot failures:

http://buildbot.python.org/all/builders/x86%20Tiger%203.6/builds/142/steps/test/logs/stdio

==
ERROR: test_child_terminated_in_stopped_state 
(test.test_subprocess.POSIXProcessTestCase)
Test wait() behavior when waitpid returns WIFSTOPPED; issue29335.
--
Traceback (most recent call last):
  File 
"/Users/db3l/buildarea/3.6.bolen-tiger/build/Lib/test/test_subprocess.py", line 
2514, in test_child_terminated_in_stopped_state
libc = ctypes.CDLL(libc_name)
  File "/Users/db3l/buildarea/3.6.bolen-tiger/build/Lib/ctypes/__init__.py", 
line 348, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(libc..dylib, 6): image not found

--
Ran 260 tests in 102.297s


Also, 
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/240/steps/test/logs/stdio

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28999] Use Py_RETURN_NONE and like

[Raymond Hettinger]

Raymond Hettinger added the comment:

I believe this is a safe change.  All of the replaced pairs on consecutive 
lines so there are no intervening operations.

For Modules/xxsubtype.c, I think the code should remain as-is.  It is intended 
to be the simplest possible example of how to make a subtype and its clarity is 
reduced by requiring that someone learn the macro.  That said, it would be 
reasonable to add a comment that this pair could also have been coded as 
Py_RETURN_NONE (i.e. use it as a teachable moment).

--
assignee:  -> serhiy.storchaka
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28876] bool of large range raises OverflowError

[Raymond Hettinger]

Raymond Hettinger added the comment:

This patch looks ready to go.  I'll wait a bit to see it there are any other 
comments.  If not, I'll apply it shortly.

--
assignee:  -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28999] Use Py_RETURN_NONE and like

[INADA Naoki]

INADA Naoki added the comment:

Oh, I feel three LGTMs are positive signal.
As I commented on ML, I think "ask forgiveness than permission" is
realistic approach for patches like this.
But it's up to you.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] subprocess module does not check WIFSTOPPED on SIGCHLD

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8e3d412f8e89 by Gregory P. Smith in branch '2.7':
Issue #29335: Fix subprocess.Popen.wait() when the child process has
https://hg.python.org/cpython/rev/8e3d412f8e89

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29348] this comment 'iff' should be 'if'?

[Tang Weizhi]

New submission from Tang Weizhi:

I think this comment 'if' should be more clearly, or 'iff' is the abbreviation 
of 'if and only if'?

--
assignee: docs@python
components: Documentation
messages: 286051
nosy: Tangwz, docs@python
priority: normal
pull_requests: 20
severity: normal
status: open
title: this comment 'iff' should be 'if'?
type: enhancement
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29348] this comment 'iff' should be 'if'?

[INADA Naoki]

INADA Naoki added the comment:

"iff" is short form of "if and only if".

--
nosy: +inada.naoki
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28876] bool of large range raises OverflowError

[INADA Naoki]

INADA Naoki added the comment:

LGTM, except 2-space indent.

--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28999] Use Py_RETURN_NONE and like

[Roundup Robot]

Roundup Robot added the comment:

New changeset df87db35833e by Serhiy Storchaka in branch 'default':
Issue #28999: Use Py_RETURN_NONE, Py_RETURN_TRUE and Py_RETURN_FALSE wherever
https://hg.python.org/cpython/rev/df87db35833e

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29335] subprocess module does not check WIFSTOPPED on SIGCHLD

[Gregory P. Smith]

Gregory P. Smith added the comment:

thanks Ned, I was awaiting interesting buildbot results. :)

fixed in 2.7 and 3.5 onwards.  thanks for the report Zach.

not closing until I also apply the fix to the subprocess32 backport.

--
resolution:  -> fixed
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com