[issue31898] Add `recommended-packages.txt` to `venv` documentation

Nick Coghlan added the comment: https://bugs.python.org/issue31899 is a follow-up issue to discuss whether or not it would make sense to expand these recommendations to cover explicit compatibility testing against these libraries for CPython updates --

[issue31899] Ensure backwards compatibility with recommended packages

New submission from Nick Coghlan : This is a potential follow-up to issue 31898, whereby the recommended packages list could be taken into account as part of CPython's own testing regime. The gist of the idea would be to: 1. Update the recommended-packages list to nominate

[issue31898] Add `recommended-packages.txt` to `venv` documentation

Change by Nick Coghlan : -- stage: -> needs patch type: -> enhancement ___ Python tracker ___

[issue31898] Add `recommended-packages.txt` to `venv` documentation

New submission from Nick Coghlan : As per the python-ideas thread starting at https://mail.python.org/pipermail/python-ideas/2017-October/047508.html, this is proposal to add a `pip -r` compatible `recommended-packages.txt` file to the `venv` documentation that summarises

[issue31897] RecursionError in plistlib.loads

Ned Williamson added the comment: ``` import plistlib dat = b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00AAAnAAA' plistlib.loads(dat, fmt=plistlib.FMT_BINARY) ``` raises ``` Traceback (most recent call last):

[issue31897] RecursionError in plistlib.loads

Ned Williamson added the comment: ``` import plistlib dat = b'AAAwAAA\xc9A\x9cAA\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00A\x04\xb2\xaaAA' plistlib.loads(dat, fmt=plistlib.FMT_BINARY) ``` raises ``` Traceback (most recent call

[issue31897] RecursionError in plistlib.loads

Ned Williamson added the comment: I'm filing related bugs under this same issue. ``` import plistlib dat = b'Q\xe4\xfeAIwAAA\xc9A\xc1AAA\xc1AAA\x9cAAnAAA\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00AA'

[issue31897] RecursionError in plistlib.loads

Ned Williamson added the comment: The crashing version numbers are from testing on the release Python 3.5, but I think we can just fix this in 3.7+. -- ___ Python tracker

[issue31897] RecursionError in plistlib.loads

New submission from Ned Williamson : Hi, The following program crashes for me using the current Python3.7 master: ``` import plistlib plistlib.loads(b'\xdd\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' b'\xda\x0cw\xb7\x00\x00\x00\x00\x00\x00\x00\xc7\x00'

[issue31896] In function define class inherit ctypes.structure, and using ctypes.pointer leak memory

New submission from Yang Big : Here my code: 2 import sys 3 import ctypes 4 5 6 def hi(): 7 class timespec(ctypes.Structure): 8 ┆ """Time specification, as described in clock_gettime(3).""" 9 ┆ _fields_ = (('tv_sec',

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: > The documentation only says “datetime.timestamp” calls “mktime” Indeed. See . This is a documentation bug. Since 3.6 the timestamp does not

[issue31895] Native hijri calendar support

Steven D'Aprano added the comment: Python 2.7 is in feature freeze, so 3.7 is the absolute earliest this could be introduced. Given how close we are to 3.7 feature freeze, 3.8 is more likely. I don't think we would have any objections to supporting hijri calendar,

[issue31894] test_timestamp_naive failed on NetBSD

Martin Panter added the comment: Are you sure it is a “system” bug? As far as I understand, at least Posix does not require support for local time before 1970. See . But why is

[issue31895] Native hijri calendar support

Haneef added the comment: This feature can be added to the (datetime.py)[https://docs.python.org/3/library/datetime.html], Java has done a similar move and it makes the whole process a lot easier. The Hijri calendar is used across the globe by various websites and

[issue31895] Native hijri calendar support

New submission from Haneef : There should be native support for converting between Hijri (Umm al-Qura), Gregorian, Julian and UnixTime calendars. Many big players have included native support for Hijri calendar in their SDKs and software. Below are some: (Java Hijri

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: I am not sure. This is a system bug and we often provide work-arounds or even reimplementations of buggy time functions in the time and datetime modules. Whether or not this is something that is worth fixing is a question

[issue31894] test_timestamp_naive failed on NetBSD

Serhiy Storchaka added the comment: I'm not a datetime expert. What is the better way to skip the test? Is it worth to change the date to say (1970, 3, 9) for which the correct result is obtained on this system? -- ___

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: I posted a wrong command, but fortunately I am in New York, so it did not matter $ TZ=EST+05EDT,M3.2.0,M11.1.0 python -c 'import time;print(time.localtime(14400)[:])' (1969, 12, 31, 23, 0, 0, 2, 365, 0) --

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: I hate this long form display! Next time please use time.localtime(14400)[:]. Do you agree that this is a system bug? On my Mac, I get $ python -c 'import time; print(time.localtime(14400)[:])' (1969, 12, 31, 23, 0, 0,

[issue31894] test_timestamp_naive failed on NetBSD

Serhiy Storchaka added the comment: $ TZ=EST+05EDT,M3.2.0,M11.1.0 ./python -c 'import time; print(time.localtime(14400))' time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=1) --

[issue31894] test_timestamp_naive failed on NetBSD

Alexander Belopolsky added the comment: I don't have access to NetBSD and this looks like a bug in the system implementation of localtime. The timestamp method is implemented by probing system localtime in the vicinity of UTC timestamp. What does

[issue31894] test_timestamp_naive failed on NetBSD

New submission from Serhiy Storchaka : $ ./python -m test -vuall test_datetime ... == FAIL: test_timestamp_naive (test.datetimetester.TestDateTime_Pure)

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD

Serhiy Storchaka added the comment: I have got both (!) results in the same binary on NetBSD (gcc 4.8.5). tan(1.57079632679489611) = 1978937966095219.00 tan(0x1.921fb54442d16p+0) = 0x1.c1f559a01adccp+50 tan(1.57079632679489611) = 1978945885716843.00

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD

Stefan Krah added the comment: Also, does this occur in a VM on on the bare metal or both? What leaves me puzzled is that I cannot reproduce the Linux x86 report with almost the exact same compiler. But I'm on x64 and use -m32. --

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD

Tim Peters added the comment: BTW, has anyone tried running a tiny C program on these platforms to see what tan(1.5707963267948961) delivers? The kind of code fdlibm uses is sensitive not only to compiler (mis)optimization, but also to stuff like how the FPU's "precision

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD

Change by Serhiy Storchaka : -- components: +Tests -Extension Modules title: math.tan has poor accuracy near pi/2 on OpenBSD -> math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD versions: +Python 2.7, Python 3.6, Python 3.7

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +4138 stage: -> patch review ___ Python tracker ___

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

Serhiy Storchaka added the comment: There is the same result on NetBSD 7.1. -- ___ Python tracker ___

[issue31304] Update doc for starmap_async error_back kwarg

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +4137 stage: needs patch -> patch review ___ Python tracker

[issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x

Change by Cornelius Diekmann : -- pull_requests: +4136 ___ Python tracker ___ ___

[issue31893] Issues with kqueue

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +4135 stage: -> patch review ___ Python tracker ___

[issue31893] Issues with kqueue

New submission from Serhiy Storchaka : In Modules/selectmodule.c it is assumed that the kevent structure is defined on FreeBSD and NetBSD as: struct kevent { uintptr_t ident; short filter; u_short flags;

[issue31749] Request: Human readable byte amounts in the standard library

Martin Panter added the comment: Ken Kundert started a related discussion a while back on Python-ideas: . This was about SI-prefixed units in general; not restricted to bytes.

[issue31886] Multiprocessing.Pool hangs after re-spawning several worker process.

Change by Antoine Pitrou : -- nosy: +Olivier.Grisel, tomMoral ___ Python tracker ___ ___

[issue31886] Multiprocessing.Pool hangs after re-spawning several worker process.

Antoine Pitrou added the comment: Generally speaking, queues can remain in an inconsistent state after a process crash (because the process might have crashed just after acquiring a shared semaphore or sending part of a large message). It's not obvious to me how we could

[issue20047] bytearray partition bug

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue20047] bytearray partition bug

Serhiy Storchaka added the comment: New changeset 107f3cc791d223dc06b7c80f0de672e88ae6a8d1 by Serhiy Storchaka in branch '2.7': [2.7] bpo-20047: Make bytearray methods partition() and rpartition() rejecting (GH-4158) (#4163)

[issue20047] bytearray partition bug

Serhiy Storchaka added the comment: New changeset 9ea5a3a45b35d01b602e7e4da4f72b2db407e5c6 by Serhiy Storchaka in branch '3.6': [3.6] bpo-20047: Make bytearray methods partition() and rpartition() rejecting (GH-4158) (#4162)

[issue31892] ssl.get_server_certificate should allow specifying certificate / key type

New submission from Hanno Boeck : The function ssl.get_server_certificate() from the ssl module is supposed to allow fetching the certificate of a TLS server. However in its current form it provides no way to specify a key type. Many popular hosts (e.g. facebook, google)

[issue25720] Fix curses module compilation with ncurses6

Serhiy Storchaka added the comment: I'll try to test this on NetBSD after fixing curses on NetBSD. It uses a different implementation of curses which don't support is_pad. -- dependencies: +Make curses compiling on NetBSD 7.1 and tests passing versions:

[issue31891] Make curses compiling on NetBSD 7.1 and tests passing

Change by Serhiy Storchaka : -- nosy: +twouters ___ Python tracker ___ ___

[issue31891] Make curses compiling on NetBSD 7.1 and tests passing

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +4134 stage: -> patch review ___ Python tracker ___

[issue31891] Make curses compiling on NetBSD 7.1 and tests passing

New submission from Serhiy Storchaka : NetBSD perhaps is the last open OS that don't use ncurses. For now the _curses module is not compiled on NetBSD. Its curses implementation doesn't contain several ncurses functions. included for non-ncurses implementations

[issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if PyRun_InteractiveOneFlags() raises an error

Xavier de Gaye added the comment: The infinite loop may occur if one of the functions called by PyRun_InteractiveOneObject() returns persistently -1. This may be the case when there is no more memory and is handled by issue 30696. It is not possible anymore to reproduce

[issue25720] Fix curses module compilation with ncurses6

Masayuki Yamamoto added the comment: I opened PR 4164 to improve the is_pad configure check and previous PR was closed. -- ___ Python tracker

[issue25720] Fix curses module compilation with ncurses6

Change by Masayuki Yamamoto : -- pull_requests: +4133 ___ Python tracker ___ ___

[issue20047] bytearray partition bug

Change by Serhiy Storchaka : -- pull_requests: +4132 ___ Python tracker ___ ___

[issue20047] bytearray partition bug

Change by Serhiy Storchaka : -- pull_requests: +4131 ___ Python tracker ___ ___