[issue31908] trace module cli does not write cover files

Raymond Hettinger added the comment: It worked in Python 3.4, but not afterwards. -- components: +Library (Lib) nosy: +rhettinger versions: +Python 3.5, Python 3.7 ___ Python tracker

[issue31904] Python should support VxWorks RTOS

Change by Brian Kuhl : -- pull_requests: +4155 ___ Python tracker ___ ___

[issue31908] trace module cli does not write cover files

New submission from Michael Selik : The trace module command-line utility doesn't write cover files. I've noticed this issue for some years now. It works fine in Python 2. When using Python 3, no ".cover" files are written, regardless of how "--coverdir" is specified.

[issue31852] Crashes with lines of the form "async \"

Alexandre Hamelin added the comment: Awesome work, thanks to you! Would it also be the case for 'await' ? -- ___ Python tracker ___

[issue31852] Crashes with lines of the form "async \"

STINNER Victor added the comment: Thank you Alexandre Hamelin for the bug report and Pablo Galindo for the fix ;-) -- ___ Python tracker

[issue31852] Crashes with lines of the form "async \"

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

[issue31852] Crashes with lines of the form "async \"

STINNER Victor added the comment: New changeset 690c36f2f1085145d364a89bfed5944dd2470308 by Victor Stinner (Pablo Galindo) in branch '3.6': [3.6] bpo-31852: Fix segfault caused by using the async soft keyword (GH-4122)

[issue31629] Running test_curses on FreeBSD changes signal handlers

STINNER Victor added the comment: Pablo Galindo Salgado: > Also, it seems that calling initscr registers signal handlers for SIGTERM: > (...) The problem is that endwin() doesn't restore the old handler. Attached PR 4183 fixes the bug, it saves/restores signal

[issue31907] Clarify error message when attempting to call function via str.format()

New submission from mickey695 : PEP 3101 states that format strings may only use the "."(getattr) or the "[]" (getitem) operators to address either attributes or items of parameters. Should a programmer attempt to, for example, call a function of a parameter as follows:

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

Change by STINNER Victor : -- keywords: +patch pull_requests: +4154 stage: -> patch review ___ Python tracker ___

[issue31905] IPv4Networkcontains raises exception on None

Eric V. Smith added the comment: I agree with David. And since the PR says "not other", then it makes even less sense, since it's checking for any False-y object. I recommend closing this as "not a bug". -- nosy: +eric.smith

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

Pablo Galindo Salgado added the comment: Also, it seems that calling initscr registers signal handlers for SIGTERM: Without calling initscr: ... rt_sigaction(SIGINT, {sa_handler=0x55d9351a9155, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f7d22b36da0},

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

Pablo Galindo Salgado added the comment: I have tracked the issue down to the call inside the call to initscr in _cursesmodule.c. The issue *seems* related to the fact that all processes are sharing the same initialization of the curses internal structures, that

[issue31739] socket.close recommended but not demonstrated in same-page example code

Change by Todd Rovito : -- nosy: +Todd.Rovito ___ Python tracker ___ ___

[issue31739] socket.close recommended but not demonstrated in same-page example code

Adam Mitchell added the comment: I submitted a pull request, #4181, to fix this issue. I am now waiting for my contributor agreement to be approved. -- nosy: +AdamMitchell ___ Python tracker

[issue31739] socket.close recommended but not demonstrated in same-page example code

Change by Roundup Robot : -- keywords: +patch pull_requests: +4152 stage: -> patch review ___ Python tracker ___

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

STINNER Victor added the comment: The bug can be reproduced with attached bug.py. With "curses.initscr(); curses.endwin()", the exit code becomes 1. Without, the child processes exits with code -15 (-SIGTERM). -- Added file:

[issue31906] String literals next to each other does not cause error

Mariatta Wijaya added the comment: What Dmitry said :) I'm closing this as "not a bug". -- nosy: +Mariatta resolution: -> not a bug stage: -> resolved status: open -> closed versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6

[issue31906] String literals next to each other does not cause error

Dmitry Kazakov added the comment: This is a documented feature: https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation And yes, it was discussed before: https://mail.python.org/pipermail/python-ideas/2013-May/020527.html -- nosy:

[issue31897] Unexpected exceptions in plistlib.loads

Ned Williamson added the comment: Thank you for the quick PR! I will report as behavior next time. I'm also following the library reference and reporting only unexpected exceptions. I trust you to reject any bugs that are expected functionality. I may follow up with

[issue31906] String literals next to each other does not cause error

Change by Sam Lobel : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

STINNER Victor added the comment: Running these two tests is enough to reproduce the issue: test.test_curses.TestCurses.test_new_curses_panel test.test_multiprocessing_fork.WithProcessesTestProcess.test_many_processes Command: CURRENT-amd64% ./python -m test -vuall

[issue31906] String literals next to each other does not cause error

New submission from Sam Lobel : This seems too obvious to have been missed, but also too strange behaviour to be on purpose. The following works for some reason (note there's no + between the words) >>> variable = "first" "second" >>> print(variable) "firstsecond" In a

[issue31905] IPv4Networkcontains raises exception on None

R. David Murray added the comment: It is not obvious that this is a bug. Why should None be a valid value for 'in network'? -- nosy: +r.david.murray ___ Python tracker

[issue31905] IPv4Networkcontains raises exception on None

Change by Roundup Robot : -- keywords: +patch pull_requests: +4150 stage: -> patch review ___ Python tracker ___

[issue31905] IPv4Networkcontains raises exception on None

New submission from Gerard Weatherby : Given a IPvNetwork network if x in network: ... raises an AttributeError instead of returning False. -- components: Library (Lib) files: ne.py messages: 305250 nosy: Gerard Weatherby priority: normal severity: normal

[issue31904] Python should support VxWorks RTOS

Change by Brian Kuhl : -- keywords: +patch pull_requests: +4149 stage: -> patch review ___ Python tracker ___

[issue31903] `_scproxy` calls SystemConfiguration functions in a way that can cause deadlocks

Change by Max Bélanger : -- keywords: +patch pull_requests: +4148 stage: -> patch review ___ Python tracker ___

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Xavier de Gaye added the comment: Actually, sys.prefix is '/usr' because '/usr/bin' is in PATH while '/bin' is not in PATH. After adding '/bin' to the start of PATH, then sys.prefix becomes '/.' when Python is run as 'python3'. The confusion comes from the '/bin' symlink

[issue31904] Python should support VxWorks RTOS

New submission from Brian Kuhl : With the trend to use REST APIs between the cloud and the IoT there is increasing interest in Python on embedded devices. Cloud developer’s typical release a reference REST implementation of JSON and/or Python on Linux and leave it to

[issue31903] `_scproxy` calls SystemConfiguration functions in a way that can cause deadlocks

New submission from Maxime Belanger : Through the use of various Python packages (such as `pyobjc`), it is possible for a deadlock to occur due to how `_scproxy.c` calls `SCDynamicStoreCopyProxies`. In more recent versions of macOS (10.7+), this function can block on

[issue31304] Update doc for starmap_async error_back kwarg

Mariatta Wijaya added the comment: This has been fixed. Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31304] Update doc for starmap_async error_back kwarg

Mariatta Wijaya added the comment: New changeset 2702380870b63ebe0161dfa29a2d0a3de02401b4 by Mariatta (Miss Islington (bot)) in branch '3.6': bpo-31304: Update starmap_async documentation. (GH-4168) (GH-4177)

[issue31304] Update doc for starmap_async error_back kwarg

Change by Roundup Robot : -- pull_requests: +4147 ___ Python tracker ___

[issue31304] Update doc for starmap_async error_back kwarg

Mariatta Wijaya added the comment: New changeset 11225753a89c2907bb717e6c050fe907e5e11829 by Mariatta (Pablo Galindo) in branch 'master': bpo-31304: Update starmap_async documentation. (GH-4168)

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

STINNER Victor added the comment: See also commit c08177a1ccad2ed0d50898c2731b518c631aed14 of bpo-30703. -- ___ Python tracker

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

STINNER Victor added the comment: Latest change in test_many_processes(): commit e6cfdefa0c2f5bda177e49b228c2c7528f7c239c of bpo-31510 which was specific to macOS. -- ___ Python tracker

[issue31629] test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

Change by STINNER Victor : -- title: test_multiprocessing_fork failure on FreeBSD -> test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD ___ Python tracker

[issue31629] test_multiprocessing_fork failure on FreeBSD

STINNER Victor added the comment: test_many_processes() was added by bpo-30589. Antoine Pitrou commented: "In the end, I'm glad I added a stress test (test_many_processes) as part of this issue.". I confirm that test_multiprocessing_fork fails with "./python -m test

[issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows

Change by Jan Gosmann : -- nosy: +jgosmann ___ Python tracker ___ ___

[issue31222] datetime.py implementation of .replace inconsistent with C implementation

Paul Ganssle added the comment: Some time ago this was fixed in pypy3: https://bitbucket.org/pypy/pypy/issues/2635/datetimereplace-always-returns I made a PR fixing this for `datetime`, `date` and `time`. -- ___ Python tracker

[issue31222] datetime.py implementation of .replace inconsistent with C implementation

Change by Paul Ganssle : -- keywords: +patch pull_requests: +4145 stage: -> patch review ___ Python tracker ___

[issue29205] col_offset for AsyncFunctionDef AST nodes is wrong

Change by Guo Ci Teo : -- pull_requests: +4144 stage: -> patch review ___ Python tracker ___

[issue30333] test_multiprocessing_forkserver: poll() failed on AMD64 FreeBSD CURRENT Non-Debug 3.5

STINNER Victor added the comment: I didn't see this bug recently. I fixed many bugs in the meanwhile, so maybe I fixed the bug? See for example https://haypo.github.io/contrib-cpython-2017q3-part2.html -- resolution: -> out of date stage: -> resolved

[issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef, AsyncWith

Change by Guo Ci Teo : -- keywords: +patch pull_requests: +4143 stage: -> patch review ___ Python tracker ___

[issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef, AsyncWith

Change by Guo Ci Teo : -- components: Library (Lib) nosy: guoci priority: normal severity: normal status: open title: Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef, AsyncWith versions: Python 3.5, Python 3.6, Python 3.7

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: inconsistent_locale_encodings.py of closed issue #7442 is interesting: I copy it here. -- Added file: https://bugs.python.org/file47246/inconsistent_locale_encodings.py ___ Python tracker

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: Oh wow, this bug is older than what I expected :-) I added support for non-ASCII thousands separator in 2012: https://bugs.python.org/issue13706#msg151733 -- ___ Python tracker

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Stefan Krah added the comment: Same as #7442, I think. -- nosy: +skrah ___ Python tracker ___

[issue31273] [2.7] unittest: Unicode support in TestCase.skip

Serhiy Storchaka added the comment: I concur with Victor. Unlikely this affects many people since skipping messages usually are ASCII strings. As a workaround you can implement your own skip() method that encodes unicode to 8-bit string. def skip(self,

[issue31901] atexit callbacks only called for current subinterpreter

New submission from Marcel Plch : `Py_FinalizeEx()` only executes callbacks from the subinterpreter from which Py_FinalizeEx is called. What is the expected behavior here? Should the callbacks be specific to individual subinterpreters? -- components: Extension

[issue31273] [2.7] unittest: Unicode support in TestCase.skip

STINNER Victor added the comment: > Could be fixed with by changing to unicode(e) Replacing str(e) with unicode(e) can introduce Unicode errors regressions. I'm not confident in doing such change late in the old 2.7 branch. I suggest you to only use native strings

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Serhiy Storchaka added the comment: This is a duplicate of issue28604. See also issue25812. -- nosy: +serhiy.storchaka ___ Python tracker

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- title: localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding -> localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

[issue31900] localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Charalampos Stratakis added the comment: Tested the PR on a system with glibc 2.26.90 where the test was failing, and it successfully passed. -- ___ Python tracker

[issue31900] localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- versions: -Python 3.5 ___ Python tracker ___ ___

[issue31900] localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- keywords: +patch pull_requests: +4142 stage: -> patch review ___ Python tracker ___

[issue31900] localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- title: UnicodeDecodeError in localeconv() makes test_float fail with glibc 2.26.90 -> localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding ___ Python

[issue31900] UnicodeDecodeError in localeconv() makes test_float fail with glibc 2.26.90

STINNER Victor added the comment: I can reproduce the bug with Python 3.6 on Fedora 26 and these locales: * LC_ALL = LC_CTYPE = fr_FR (encoding = ISO8859-1) * LC_NUMERIC= es_MX.utf8 (encoding = UTF-8) Good: LC_NUMERIC = LC_CTYPE = LC_ALL = "es_MX.utf8" haypo@selma$

[issue31245] Asyncio UNIX socket and SOCK_DGRAM

Change by Yury Selivanov : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue31245] Asyncio UNIX socket and SOCK_DGRAM

Yury Selivanov added the comment: New changeset fe4ea9cf1ee04f5a60e4ed928d8624b95b031e18 by Yury Selivanov (Quentin Dawans) in branch 'master': bpo-31245: Asyncio unix socket datagram (#3164)

[issue31900] UnicodeDecodeError in localeconv() makes test_float fail with glibc 2.26.90

New submission from Charalampos Stratakis : Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1484497 It seems that on the development branch of Fedora, when we updated glibc from 2.26 to 2.26.90, test_float_with_comma started failing. Details from the

[issue31895] Native hijri calendar support

Marc-Andre Lemburg added the comment: There are other PyPI packages available for this specific calendar as well, e.g. https://pypi.python.org/pypi/umalqurra/ Perhaps you could send Neil a PR to make the calculation more accurate ?! In any case, the stdlib is not meant to

[issue31895] Native hijri calendar support

Haneef added the comment: Thanks @steven.daprano, yeah, it would be good to have support for other calendars as well. In my case, I use the Hijri Umm al-Qura, Gregorian and obviously UnixTime calendars. You're right, maybe it would be wiser to implement it in the PyPi

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Erik Bray added the comment: Well, we'll see how long it takes me to get them to respond on that. If it's not too much trouble then I'll be happy to drop this issue. -- ___ Python tracker

[issue25612] nested try..excepts don't work correctly for generators

Serhiy Storchaka added the comment: Thank you for the clarification Mark. I agree that the current behavior is well justified. Cython was fixed in https://github.com/cython/cython/commit/2d3392463b77eb550bd54a69bd28cc161947acb5. -- status: open -> closed

[issue31895] Native hijri calendar support

Gareth Rees added the comment: convertdate does not document which version of the Islamic calendar it uses, but looking at the source code, it seems that it uses a rule-based calendar which has a 30-year cycle with 11 leap years. This won't help Haneef, who wants the Umm

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Xavier de Gaye added the comment: Clarification about the test results: On archlinux /bin is a symlink to /usr/bin, so on archlinux the value of sys.prefix is '/usr' instead of the expected '/'. This is because in Modules/getpath.c, 'argv0_path' is the directory of the link

[issue25612] nested try..excepts don't work correctly for generators

Mark Shannon added the comment: Looking at the docs: https://docs.python.org/3.6/library/sys.html#sys.exc_info states: If the current stack frame is not handling an exception, the information is taken from the calling stack frame, or its caller, and so on until a stack

[issue31895] Native hijri calendar support

Marc-Andre Lemburg added the comment: I agree with Steven: It's best to use a PyPI package for calendar support such as https://pypi.python.org/pypi/convertdate/. We only have the standard Gregorian calendar support in datetime and calendar modules. -- nosy:

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Xavier de Gaye added the comment: To test PR 4172 on linux one needs a chroot. The following test is run on archlinux using systemd-nspawn (a chroot on steroids, see https://wiki.archlinux.org/index.php/Systemd-nspawn). 1) Setup systemd-nspawn by installing

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Change by Xavier de Gaye : -- keywords: +patch pull_requests: +4141 stage: needs patch -> patch review ___ Python tracker ___

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Serhiy Storchaka added the comment: This is a problem of AppVeyor. It should update Cygwin to a bugfix release. 2.8.0 contains other bugs. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Erik Bray added the comment: Well, I agree there's an unfortunate trade-off here: One can skip the test, allowing the test suite to work on slightly older versions of Cygwin, from before this issue was fixed. However, I then lose regression testing on newer versions.

[issue31897] Unexpected exceptions in plistlib.loads

Serhiy Storchaka added the comment: PR 4171 fixes the following errors: 1. OverflowError is raised by seek() for too large offsets of objects or the offset table. 2. Since read() past the file returns b'' and int.from_bytes() used for non-standard sizes accepts

[issue31114] 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used

Change by Xavier de Gaye : -- components: +Cross-Build -Build nosy: +Alex.Willmer stage: -> needs patch title: 'make install' fails when exec_prefix is '/' and DESTDIR not empty -> 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used versions:

[issue31897] Unexpected exceptions in plistlib.loads

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

[issue31897] Unexpected exceptions in plistlib.loads

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

[issue31895] Native hijri calendar support

Gareth Rees added the comment: It is a substantial undertaking, requiring a great deal of expertise, to implement the Islamic calendar. The difficulty is that there are multiple versions of the calendar. In some places the calendar is based on human observation of the

[issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files

Change by Tal Einat : -- pull_requests: +4139 ___ Python tracker ___ ___

[issue31897] Unexpected exceptions in plistlib.loads

Change by Serhiy Storchaka : -- title: RecursionError in plistlib.loads -> Unexpected exceptions in plistlib.loads ___ Python tracker

[issue31897] RecursionError in plistlib.loads

Serhiy Storchaka added the comment: Thank you for your report Ned. But there are no crashes. The term crash means a segmentation fault or similar error that causes the interpreter to exit immediately. -- assignee: -> serhiy.storchaka components: +Library