[issue37025] Misleading error message "Python failed to load the default activation context"

[Zackery Spytz]

Change by Zackery Spytz :


--
pull_requests: +16435
pull_request: https://github.com/python/cpython/pull/16897

___
Python tracker 

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

[issue38562] pip install --upgrade git submodule update --recursive does not exist

[Ayse]

New submission from Ayse :

Hi, 

I was trying to apply a github code, for that I need to get this first:git 
clone --recursive https://github.com/rbgirshick/py-faster-rcnn.git  but it when 
I run this it is saying this:
PS C:\Users\Ayse Dogan> python -m pip install --user --upgrade git clone 
--recursive https://github.com/rbgirshick/py-faste
r-rcnn.git

Usage:
  C:\ProgramData\Anaconda3\python.exe -m pip install [options]  [package-index-options] ...
  C:\ProgramData\Anaconda3\python.exe -m pip install [options] -r  [package-index-options] ...
  C:\ProgramData\Anaconda3\python.exe -m pip install [options] [-e]  ...
  C:\ProgramData\Anaconda3\python.exe -m pip install [options] [-e]  ...
  C:\ProgramData\Anaconda3\python.exe -m pip install [options]  ...

no such option: --recursive

As I see from Issue35135 this was happening for some other packages. 
Could you please help me about it?

Sincerely, 
Ayse

--
components: Installation
messages: 355208
nosy: aysedogan, docs@python, pgacv2, xtreak
priority: normal
severity: normal
status: open
title: pip install --upgrade git submodule update --recursive does not exist
versions: Python 3.7

___
Python tracker 

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

[issue38539] Update demo files

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset ea6041cd7ff0d752296d1759927eff898ceba864 by Raymond Hettinger in 
branch 'master':
bpo-38539:  Finish rename of ss1.py to spreadsheet.py (GH-16896)
https://github.com/python/cpython/commit/ea6041cd7ff0d752296d1759927eff898ceba864


--

___
Python tracker 

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

[issue38460] 3.8 Release Notes: document asyncio exception changes

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I'm personally not sure if we need to reflect *private*
> API change in Release Notes

The whatsnew 3.8 document is for significant changes to public APIs.  The 
changelog (built from the news entries) has much more extensive detail.  The 
main docs are where we put versionadded/versionchanged so that there is a 
source for knowing which features run in which versions of Python.

--

___
Python tracker 

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

[issue38539] Update demo files

[Raymond Hettinger]

Change by Raymond Hettinger :


--
pull_requests: +16434
pull_request: https://github.com/python/cpython/pull/16896

___
Python tracker 

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

[issue38539] Update demo files

[Raymond Hettinger]

Change by Raymond Hettinger :


--
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

[issue38539] Update demo files

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset a4aeb336697c85996d781271cc6b42bc6d4c2908 by Raymond Hettinger 
(Julin S) in branch 'master':
bpo-38539: Update demo files (GH-16890)
https://github.com/python/cpython/commit/a4aeb336697c85996d781271cc6b42bc6d4c2908


--

___
Python tracker 

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

[issue38561] multiprocessing.Queue fails intermittently with "Broken pipe"

[Samuel Grayson]

New submission from Samuel Grayson :

See [this SO post for more 
details](https://stackoverflow.com/q/51680479/1078199)

--
components: Library (Lib)
files: test.py
messages: 355204
nosy: Samuel Grayson
priority: normal
severity: normal
status: open
title: multiprocessing.Queue fails intermittently with "Broken pipe"
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48674/test.py

___
Python tracker 

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

[issue27873] multiprocessing.pool.Pool.map should take more than one iterable

[Kyle Stanley]

Kyle Stanley  added the comment:

> Is it still open? What else needs to be done?

Yes, this patch needs to be translated into a GitHub PR. See 
https://devguide.python.org/pullrequest/ for more information on our PR 
workflow if you're not already familiar with it. Since naught101 wrote a patch, 
we should have their name in "Co-Authored-By" of the final commit to the PR if 
they have a GitHub account. If not, just mention it in a comment to the PR that 
they originally wrote the patch. 

Feel free to @mention me when you open the PR so I can help to review it, 
although this will likely require a final approval from a maintainer of 
multiprocessing module before it can be merged.

--
nosy: +aeros

___
Python tracker 

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

[issue27530] Non-Critical Compiler WARNING: Python Embedding C++11 does not allow non-constant string literals

[STINNER Victor]

STINNER Victor  added the comment:

This issues has been fixed in Python 3: the second parameter of 
PyObject_CallMethod() is now a "const char*". Please upgrade to Python 3.

--
nosy: +vstinner
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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

STINNER Victor  added the comment:

I marked bpo-32026 as a duplicate of this issue.

--

___
Python tracker 

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

[issue32026] Memory leaks in Python on Windows

[STINNER Victor]

STINNER Victor  added the comment:

It's basically a duplicate of bpo-1635741.

--
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

___
Python tracker 

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

[issue28202] Python 3.5.1 C API, the global variable is not destroyed when delete the module

[STINNER Victor]

STINNER Victor  added the comment:

> The problem is resolved if call PyGC_Collect() after PyDict_DelItemString(). 
> Is it expected to call PyGC_Collect() here?

Yeah sadly, to handle such reference cycles, you have to trigger an explicit 
garbage collection.

It doesn't sound like a bug to me.

Python 3.4 made this way better with PEP 442.

Anyway, that's an old issue with no activity since 2016. I close it.

--
nosy: +vstinner
resolution:  -> out of date
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

[issue38419] The path of check-c-globals.py on README is wrong

[Dong-hee Na]

Change by Dong-hee Na :


--
assignee: docs@python -> 
components:  -Documentation
nosy:  -docs@python

___
Python tracker 

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

[issue38419] The path of check-c-globals.py on README is wrong

[Dong-hee Na]

Change by Dong-hee Na :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python

___
Python tracker 

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

[issue38419] The path of check-c-globals.py on README is wrong

[Dong-hee Na]

Dong-hee Na  added the comment:

Thank you for your contribution AMIR!

@willingc
Thank you for merging PR 16680 Carol :)
I am now closing this issue.

--
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

[issue12179] Race condition using PyGILState_Ensure on a new thread

[STINNER Victor]

STINNER Victor  added the comment:

Bug report in 2011. I close this old issue.

--
resolution:  -> out of date
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

[issue36107] aarch64 python3 buffer overflow with stack protector on rpi3 (alpine linux)

[STINNER Victor]

STINNER Victor  added the comment:

> It seems like python 3.7.2 works.

So yeah, use Python 3.7 or newer. Python 3.8 has been released ;-)

> Any idea which commit(s) may have fixed it?

I have no idea.

--
nosy: +vstinner
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

[issue38560] Allow iterable argument unpacking after a keyword argument?

[Brandt Bucher]

New submission from Brandt Bucher :

Calls of the form f(name=value, *args) are currently legal syntax. The 
resulting argument binding is awkward, and almost never does what you 
want/expect it to:

>>> def f(x, y, z):
... print(x, y, z)
... 

>>> f(x=0, *(1, 2))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() got multiple values for argument 'x'

>>> f(y=0, *(1, 2))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: f() got multiple values for argument 'y'

>>> f(z=0, *(1, 2))
1 2 0

I'm not sure if this is intentional, or an oversight. Every other way of 
passing positional arguments after keyword arguments results in an error:

f(kwarg=kwarg, arg)  # SyntaxError: positional argument follows keyword argument
f(**kwargs, arg) # SyntaxError: positional argument follows keyword 
argument unpacking
f(**kwargs, *args)   # SyntaxError: iterable argument unpacking follows keyword 
argument unpacking

I think this case should raise a "SyntaxError: iterable argument unpacking 
follows keyword argument".

I'd like to work on this if we believe it should be changed.

--
components: Interpreter Core
messages: 355195
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Allow iterable argument unpacking after a keyword argument?
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

STINNER Victor  added the comment:

One part of this issue is that all C extensions of the stdlib should be updated 
to implement the PEP 489 "Multi-phase extension module initialization".

--

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

STINNER Victor  added the comment:

I marked bpo-21387 as a duplicate of this issue.

--

___
Python tracker 

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

[issue21387] Memory leaks when embedded interpreter is reinitialized

[STINNER Victor]

STINNER Victor  added the comment:

Duplicate of bpo-1635741.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

STINNER Victor  added the comment:

I marked bpo-26888 as a duplicate of this issue.

--

___
Python tracker 

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

[issue26888] Multiple memory leaks after raw Py_Initialize and Py_Finalize.

[STINNER Victor]

STINNER Victor  added the comment:

That's basically a duplicate of bpo-1635741.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

___
Python tracker 

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

[issue24770] Py_Finalize() doesn't stop daemon threads

[STINNER Victor]

Change by STINNER Victor :


--
title: Py_Finalize not cleaning up all threads -> Py_Finalize() doesn't stop 
daemon threads

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

STINNER Victor  added the comment:

I marked bpo-6741 as a duplicate of this issue.

--

___
Python tracker 

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

[issue6741] Garbage collector release method

[STINNER Victor]

STINNER Victor  added the comment:

That's basically a duplicate of bpo-1635741.

--
nosy: +vstinner
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

STINNER Victor  added the comment:

I tested on the master branch of Python:
---
#include 

void func()
{
Py_Initialize(); Py_Finalize();
Py_ssize_t cnt = _Py_GetRefTotal();
printf("sys.gettotalrefcount(): %zd\n", cnt);
}

int main(int argc, char *argv[])
{
Py_SetProgramName(L"./_testembed");
for (int i=0; i < 10; i++) {
func();
}
}
---

Each iteration leaks around 5,000 Python objects:
---
sys.gettotalrefcount(): 15113
sys.gettotalrefcount(): 19527
sys.gettotalrefcount(): 23941
sys.gettotalrefcount(): 28355
sys.gettotalrefcount(): 32769
sys.gettotalrefcount(): 37183
sys.gettotalrefcount(): 41597
sys.gettotalrefcount(): 46011
sys.gettotalrefcount(): 50425
sys.gettotalrefcount(): 54839
---

--
nosy: +vstinner
title: Interpreter seems to leak references after finalization -> Py_Finalize() 
doesn't clear all Python objects at exit
versions: +Python 3.9 -Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue26693] Exception ignored in: in _shutdown, assert tlock.locked()

[STINNER Victor]

STINNER Victor  added the comment:

Extract of test2.C:
---
  // in main thread
  Py_Initialize();
  PyEval_InitThreads();
  PyEval_SaveThread();

  // creating a new sub-interpreter, in my real app, this would be created
  //   in a sub-thread.
  PyInterpreterState* const mainInterpreterState = PyInterpreterState_New();
  PyThreadState* const taskState = PyThreadState_New(mainInterpreterState);
  PyEval_AcquireThread(taskState);
  PyThreadState * const sub_interp = Py_NewInterpreter();
  PyThreadState_Swap( taskState );
  PyEval_ReleaseThread( taskState );
---

IMO this code is not supported. It creates 3 interpreters:

* Py_Initialize(): good
* PyInterpreterState_New(): partially initialized
* Py_NewInterpreter(): created from the partially initialized interpreter

IMHO PyInterpreterState_New() should never be used outside Python internals. 
Only Py_NewInterpreter() should be used.

At least, this code now fails since PyInterpreterState_New() configuration 
(interp->config) is empty/uninitizalized, and so _PySys_InitMain() fails.

Moreover, the example uses PyGILState C API which isn't compatible with 
subinterpreters yet :-(

--

___
Python tracker 

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

[issue26693] Exception ignored in: in _shutdown, assert tlock.locked()

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +eric.snow

___
Python tracker 

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

[issue38419] The path of check-c-globals.py on README is wrong

[Carol Willing]

Carol Willing  added the comment:


New changeset 20bf8e08a18c0f1eab49c54f3bd56f8364a2f5cc by Carol Willing (AMIR) 
in branch 'master':
 bpo-38419: fix "check-c-globals" path (GH-16680)
https://github.com/python/cpython/commit/20bf8e08a18c0f1eab49c54f3bd56f8364a2f5cc


--
nosy: +willingc

___
Python tracker 

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

[issue12806] argparse: Hybrid help text formatter

[David Steele]

David Steele  added the comment:

I came across this thread after making a simple argparse formatter for 
preserving paragraphs. The submissions here look better than that effort. Here 
is a quick, hacky look at the patches from one perspective.

I wanted to prefer ParagraphFormatterML, but didn't like that it doesn't appear 
to wrap bullet lines, and it wrapped help and epilogs to different lengths. For 
all options I found an initial textwrap.dedent() was needed to get the results 
I expected. When I did the dedent with ParagraphFormatter*, a subsequent 
textwrap.indent(" ") hack was needed to restore spaces at the wrap point. 
FlexiFormatter was incomplete - epilogs weren't affected.

Ultimately, I settled on reworking FlexiFormatter. My version has the following 
changes:

- Refactor the formatting code out a la ParagraphFormatter, and add to 
_fill_text() as well, so formatting is available for both epilogs and option 
help
- Add a leading textwrap.dedent(), to get it to feel more like HelpFormatter.

Note
- The result requires line feed escapes within paragraphs.
- I'm not using the "indent" argument for _fill_text(), with no apparent 
consequences.
- Automated tests show that FlexiFormatter adds a space to each blank line. I 
decided that was not a problem

Code is at:
https://github.com/davesteele/argparse_formatter
https://pypi.org/project/argparse-formatter/

Regarding licensing, my contributions (and presumably the others') is addressed 
by the CLA.

I'd very much like to see something from this thread merged. This looks to me 
to be good enough. Any objections to a pull request?

--
nosy: +daves

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[STINNER Victor]

STINNER Victor  added the comment:

It seems like attached patches are outdated: Python has been fixed to support 
Android. For example, Python now uses the UTF-8 codec rather than mbstowcs() to 
decode byte strings. I'm quite sure that there are still corner cases which are 
not well supported on Android, but I would suggest to open more specific issues 
in that case.

--
nosy: +vstinner
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

[issue16353] add function to os module for getting path to default shell

[STINNER Victor]

STINNER Victor  added the comment:

This issue has been fixed. The subprocess module now uses '/system/bin/sh' by 
default on Android thanks to Xavier de Gaye!

--
nosy: +vstinner
resolution:  -> fixed
stage: needs patch -> 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

[issue34309] Trouble when reloading extension modules.

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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

[issue30060] Crash with subinterpreters and Py_NewInterpreter()

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +eric.snow
title: Crash on Py_Finalize if Py_NoSiteFlag is used -> Crash with 
subinterpreters and Py_NewInterpreter()

___
Python tracker 

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

[issue3367] Uninitialized value read in parsetok.c

[STINNER Victor]

STINNER Victor  added the comment:

I close the issue, it has been fixed.


I'm no longer able to reproduce the initial issue:

$ ./configure --with-pydebug --with-valgrind
$ make clean
$ make
$ valgrind --suppressions=Misc/valgrind-python.supp ./python 

==2670== Memcheck, a memory error detector
==2670== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2670== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==2670== Command: ./python
==2670== 
Python 3.9.0a0 (heads/master:91528f40c3, Oct 23 2019, 01:36:01) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> exec("")
>>> ^D # CTRL+D
==2670== 
==2670== HEAP SUMMARY:
==2670== in use at exit: 1,530,371 bytes in 26,288 blocks
==2670==   total heap usage: 49,485 allocs, 23,197 frees, 10,318,174 bytes 
allocated
==2670== 
==2670== LEAK SUMMARY:
==2670==definitely lost: 0 bytes in 0 blocks
==2670==indirectly lost: 0 bytes in 0 blocks
==2670==  possibly lost: 872,665 bytes in 5,936 blocks
==2670==still reachable: 657,706 bytes in 20,352 blocks
==2670== suppressed: 0 bytes in 0 blocks
==2670== Rerun with --leak-check=full to see details of leaked memory
==2670== 
==2670== For lists of detected and suppressed errors, rerun with: -s
==2670== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


Moreover, Python initialization code has been reworked in the PEP 587 
implementation to ensure that sys.argv is never empty. If it's called with an 
empty list, [""] is used instead.

--
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

[issue33384] Build does not work with closed stdin on NetBSD

[STINNER Victor]

STINNER Victor  added the comment:

I'm quite that this issue has been fixed by bpo-30225 which is part Python 
3.7.4, Python 3.8.0 and newer. I mark the issue as duplicate of bpo-30225. 
Please reopen the bug if these versions still fail on NetBSD.


commit 1c4670ea0cc3d208121af11b9b973e6bb268e570
Author: Victor Stinner 
Date:   Thu May 4 00:45:56 2017 +0200

bpo-30225: Fix is_valid_fd() on macOS Tiger (#1443)

is_valid_fd() now uses fstat() instead of dup() on macOS to return 0
on a pipe when the other side of the pipe is closed. fstat() fails
with EBADF in that case, whereas dup() succeed.

--
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> EBADF error on x86 Tiger 3.x buildbot
title: Build does not work with closed stdin -> Build does not work with closed 
stdin on NetBSD

___
Python tracker 

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

[issue13986] ValueError: cannot convert float NaN to integer

[STINNER Victor]

STINNER Victor  added the comment:

The issue has not been seen since 2017-03-04, I close the issue as out of date.

--
resolution:  -> out of date
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

[issue31074] Startup failure if executable is a \\?\ path on Windows

[STINNER Victor]

STINNER Victor  added the comment:

I got the same bug recently and I fixed it:

commit dec39716ca93ee2e8d9b94915ece33014eb58e9e
Author: Victor Stinner 
Date:   Mon Sep 30 14:49:34 2019 +0200

bpo-38322: Fix gotlandmark() of PC/getpathp.c (GH-16489)

Write the filename into a temporary buffer instead of reusing prefix.
The problem is that join() modifies prefix inplace. If prefix is not
normalized, join() can make prefix shorter and so gotlandmark()
does modify prefix instead of returning it unmodified.

--
nosy: +vstinner
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed
superseder:  -> Azure Pipelines: appx tests fail: init_fs_encoding: failed to 
get the Python codec of the filesystem encoding

___
Python tracker 

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

[issue22139] python windows 2.7.8 64-bit did not install

[STINNER Victor]

STINNER Victor  added the comment:

No activity since 2016, I close the issue.

--
nosy: +vstinner
resolution: works for me -> out of date
status: open -> closed

___
Python tracker 

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

[issue9098] MSYS build fails with `S_IXGRP' undeclared

[STINNER Victor]

STINNER Victor  added the comment:

No activity since 2012, I close the issue.

--
nosy: +vstinner
resolution:  -> out of date
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

[issue17922] Crash in clear_weakref

[STINNER Victor]

STINNER Victor  added the comment:

There is no activity since 2013. I guess that the user found a way to 
workaround this crash, or managed to get it fixed. I close the issue.

--
nosy: +vstinner
resolution:  -> out of date
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

[issue12919] Control what module is imported first

[STINNER Victor]

STINNER Victor  added the comment:

I close the issue since I see disagreement on the feature request.

Modules/getpath.c and PC/getpathp.c use Lib/os.py to detect the stdlib 
directory.

_PyUnicode_InitEncodings() is the first function importing modules: to import 
the Python codec of the filesystem encoding. If this import fails, Python now 
dumps the "path configuration" to help users to debug their setup. See 
bpo-38236.

Example:

$ PYTHONHOME=/xxx ./python -c pass
Python path configuration:
  PYTHONHOME = '/xxx'
  PYTHONPATH = (not set)
  program name = './python'
  isolated = 0
  environment = 1
  user site = 1
  import site = 1
  sys._base_executable = '/home/vstinner/python/master/python'
  sys.base_prefix = '/xxx'
  sys.base_exec_prefix = '/xxx'
  sys.executable = '/home/vstinner/python/master/python'
  sys.prefix = '/xxx'
  sys.exec_prefix = '/xxx'
  sys.path = [
'/xxx/lib/python39.zip',
'/xxx/lib/python3.9',
'/xxx/lib/python3.9/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the 
filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x7f845ca19740 (most recent call first):


--
nosy: +vstinner
resolution:  -> rejected
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

[issue33375] warnings: get filename from frame.f_code.co_filename

[STINNER Victor]

STINNER Victor  added the comment:

I closed bpo-8787 as a duplicate of this issue.

--
versions: +Python 3.8

___
Python tracker 

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

[issue8787] warnings inside PyRun_SimpleString() display argv[1]

[STINNER Victor]

Change by STINNER Victor :


--
resolution: fixed -> duplicate
superseder:  -> warnings: get filename from frame.f_code.co_filename

___
Python tracker 

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

[issue8787] warnings inside PyRun_SimpleString() display argv[1]

[STINNER Victor]

STINNER Victor  added the comment:

Fixed in bpo-33375.

commit 11a896652ee98aa44e59ed25237f9efb56635dcf
Author: Thomas Kluyver 
Date:   Fri Jun 8 21:28:37 2018 +0200

bpo-33375: Get filename for warnings from frame.f_code.co_filename (GH-6622)

More consistent with how other parts of Python find the filename (e.g. 
tracebacks and pdb).

--
nosy: +vstinner
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

[issue15047] Cygwin install (regen) problem

[STINNER Victor]

STINNER Victor  added the comment:

No activity since 2012, I close the issue.

--
nosy: +vstinner
resolution:  -> out of date
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

[issue13562] Notes about module load path

[STINNER Victor]

STINNER Victor  added the comment:

No activity since 2012, I close the issue.

Moreover, the PEP 587 now provides a clean C API to configure sys.path.

https://docs.python.org/dev/c-api/init_config.html#c.PyConfig.module_search_paths

--
nosy: +vstinner
resolution:  -> out of date
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

[issue12232] embedded python import cmath

[STINNER Victor]

STINNER Victor  added the comment:

No activity since 2011, I close the issue.

--
nosy: +vstinner
resolution:  -> out of date
stage: test needed -> 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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

STINNER Victor  added the comment:

The initial issue has been fixed, I close the issue.

> I would like to keep the issue open since I plan to do one more change: use 
> PyWideStringList in _PyPathConfig for module_search_paths to support paths 
> which contains DELIM (":" on Unix).

I may use bpo-38353 instead for that. See also bpo-31210.

--
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

[issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times

[STINNER Victor]

STINNER Victor  added the comment:

Program described in msg189250 does not crash on the master branch of Python. 
The PEP 587 deeply reworked Python initialization code. There is now a 
preinitialization phase, for example.

Moreover, Programs/_testembed.c has a test calling 
Py_Initialize()+Py_Finalize() multiple times, and this test calls 
Py_SetProgramName() as well.

Upgrade to Python 3.8 to get the fix. (I didn't check if Python 3.7 is also 
fixed.)

--
nosy: +vstinner
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

[issue38559] async generators aclose() behavior in 3.8

[Yury Selivanov]

Yury Selivanov  added the comment:

> So I think asyncio.run is actually totally fine with the 3.8.0 behavior.

Yes.  Looks like it.

> It's only explicit calls to shutdown_asyncgens that might run into this, and 
> I think that's probably OK?

Yes.  Calling shutdown_asyncgens after all tasks are cancelled is still useful 
to cleanup asynchronous generators that were created but not yet GCed or 
iterated.

> And if we did allow aclose() to run at any time, then I worry that that could 
> cause serious problems. Users can call aclose() at will, and it's generally 
> good practice to always call aclose() on your async generators explicitly. So 
> it's entirely possible that users will accidentally call aclose() themselves 
> while they have another task is blocked in __anext__. And in that case 
> what do we do?

I agree.  Avoiding that kind of mess was the main motivation to fix ag_running.

> So... this is super subtle and confusing, but I *think* the conclusion is 
> that yeah, 3.8.0 is fine and there's no urgent action needed.

Let's see if anyone else thinks this might be a problem, but yeah, it seems 
that the only programs that can suffer from this change are those that don't 
use 'asyncio.run'.  And if so they should be fixed to explicitly cancel all 
tasks before calling shutdown_asyncgens.

--

___
Python tracker 

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

[issue12598] Move sys variable initialization from import.c to sysmodule.c

[STINNER Victor]

STINNER Victor  added the comment:

No activity for 7 years, I close the issue.

--
nosy: +vstinner
resolution:  -> out of date
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

[issue38559] async generators aclose() behavior in 3.8

[Nathaniel Smith]

Nathaniel Smith  added the comment:

I think conceptually, cancelling all tasks and waiting for them to exit is the 
right thing to do. That way you run as much shutdown code as possible in 
regular context, and also avoid this problem – if there are no tasks, then 
there can't be any tasks blocked in __anext__/asend/athrow/aclose, so calling 
aclose is safe.

This is also the right way to handle it from Trio's perspective – we always 
wait for all tasks to exit before exiting our run loop. For asyncio it might be 
a bit more complicated though so we should think through the trade-offs.

> The only way (at least known to me) that that could be the case if some tasks 
> ignores cancellation.  

Looking at runners.py, it seems like asyncio.run doesn't just call 
task.cancel(), but actually waits for all tasks to exit. (See the call to 
gather() inside _cancel_all_tasks.) So I think that does guarantee that by the 
time we hit shutdown_asyncgens(), we can be certain that all tasks have exited. 
(If a task ignores cancellation, then that will cause _cancel_all_tasks to 
hang, so we never reach shutdown_asyncgens at all. Not ideal, but not really 
our problem either – if someone complains we just tell them they need to stop 
ignoring cancellation if they want  their program to shutdown cleanly.)

So I think asyncio.run is actually totally fine with the 3.8.0 behavior. It's 
only explicit calls to shutdown_asyncgens that might run into this, and I think 
that's probably OK? If you're calling shutdown_asyncgens by hand then you're 
kind of taking responsibility for dealing with any subtle issues around 
shutdown.

And if we did allow aclose() to run at any time, then I worry that that could 
cause serious problems. Users can call aclose() at will, and it's generally 
good practice to always call aclose() on your async generators explicitly. So 
it's entirely possible that users will accidentally call aclose() themselves 
while they have another task is blocked in __anext__. And in that case what 
do we do?

The aclose call has to consume the generator's frame, by definition. But in the 
mean time, we still have this __anext__ coroutine object hanging around 
pointing to the consumed frame, that the task scheduler thinks needs to be 
resumed at some point in response to some event, and that can cause all kinds 
of weird situations. The __anext__ might try to resume while the aclose() is 
running. The __anext__ might get stuck and never resume, because of the code 
run by aclose() accidentally unregistering the event that was going to wake it 
up, so you just get a deadlock instead of a useful error. It might cause some 
other code entirely to crash – like if the __anext__ was blocked inside a call 
to 'await queue.get()', then aclose() interrupting that might corrupt the 
queue's internal state, so the next time some other task calls queue.put() they 
get an exception or other incorrect behavior. It all seems really tricky and 
messy to me.

So... this is super subtle and confusing, but I *think* the conclusion is that 
yeah, 3.8.0 is fine and there's no urgent action needed.

--

___
Python tracker 

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

[issue38554] A fatal error in test_descr

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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

[issue32526] Closing async generator while it is running does not raise an exception

[Yury Selivanov]

Yury Selivanov  added the comment:

Was fixed as part of #30773.

--
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

[issue38466] [Easy doc] threading.excepthook doc talks about "object"

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Daniel Baskal for the fix and Sebastian Rittau for the bug report. The 
doc is now fixed in 3.8 and master branches.

--
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

[issue38559] async generators aclose() behavior in 3.8

[Yury Selivanov]

Yury Selivanov  added the comment:

Just discussed this issue off-list with Nathaniel.  Maybe this isn't as severe 
as I thought it is.

If we cancel all asyncio tasks before calling `loop.shutdown_asyncgens()` this 
*probably* becomes a non-issue.  And "asyncio.run()" does just that [1].

Any asynchronous generator ultimately needs a task to iterate it, so if we 
cancel tasks, we should cancel all asynchronous generators too.  Calling 
`loop.shutdown_asyncgens()` then ensures that there are no orphan async 
generators.  The only way (at least known to me) that that could be the case if 
some tasks ignores cancellation.  

Nathaniel, what do you think about this in the context of Trio?

If anything, we can update asyncio docs explaining the new behavior of async 
generators and how to use "loop.shutdown_asyncgens()".

[1] 
https://github.com/python/cpython/blob/91528f40c30717563a478920861c81d18da5bf63/Lib/asyncio/runners.py#L46

--

___
Python tracker 

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

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[STINNER Victor]

STINNER Victor  added the comment:

It seems like MultiLoopChildWatcher doesn't respect the PEP 475: 
siginterrupt(False) must not be used. But the following change isn't enough to 
fix this issue (test_close_kill_running hang).

diff --git a/Lib/asyncio/unix_events.py b/Lib/asyncio/unix_events.py
index d8f653045a..887f837bad 100644
--- a/Lib/asyncio/unix_events.py
+++ b/Lib/asyncio/unix_events.py
@@ -1192,9 +1192,6 @@ class MultiLoopChildWatcher(AbstractChildWatcher):
"restore to default handler on watcher close.")
 self._saved_sighandler = signal.SIG_DFL
 
-# Set SA_RESTART to limit EINTR occurrences.
-signal.siginterrupt(signal.SIGCHLD, False)
-
 def _do_waitpid_all(self):
 for pid in list(self._callbacks):
 self._do_waitpid(pid)

--

___
Python tracker 

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

[issue38559] async generators aclose() behavior in 3.8

[Yury Selivanov]

New submission from Yury Selivanov :

I believe I might have discovered a problem with asynchronous generators in 3.8.


# Prelude

In Python prior to 3.8 it was possible to overlap running of "asend()" and 
"athrow()" methods for the same asynchronous generator.

In plain English, it was possible to await on "agen.asend()" while some other 
coroutine is already awaiting on "agen.asend()".  That created all kinds of 
problems with asynchronous generators when people used them to implement 
channels by trying to push values into the same asynchronous generator from 
different coroutines.  Regular code that used asynchronous generators in plain 
and non-sophisticated way did not care.

For classic synchronous generators we have a check for preventing overlapping 
use of "send()" and "throw()" -- the "gi_running" flag.  If the flag is set, 
both methods raise a RuntimeError saying that "generator already executing".


# Python 3.8

As was discussed in issues #30773 and #32526 we decided to replicate the same 
behavior for asynchronous generators, mainly:

* add an "ag_running" flag;

* set "ag_running" when "anext()" or "athrow()" begin to rung, and set it off 
when they are finished executing;

* if the flag is set when we are about to run "anext()" or "athrow()" it means 
that another coroutine is reusing the same generator object in parallel and so 
we raise a RuntimeError.


# Problem

Closing a generator involves throwing a GeneratorExit exception into it.  
Throwing the exception is done via calling "throw()" for sync generators, and 
"athrow()" for async generators.

As shown in https://gist.github.com/1st1/d9860cbf6fe2e5d243e695809aea674c, it's 
an error to close a synchronous generator while it is being iterated.  This is 
how async generators *started to behave* in 3.8.

The problem is that asyncio's "loop.shutdown_asyncgens()" method tries to 
shutdown orphan asynchronous generators by calling "aclose()" on them.  The 
method is public API and is called by "asyncio.run()" automatically.

Prior to 3.8, calling "aclose()" worked (maybe not in the most clean way). A 
GeneratorExit was thrown into an asynchronous generator regardless of whether 
it was running or not, aborting the execution.

In 3.8, calling "aclose()" can crash with a RuntimeError.  It's no longer 
possible to *reliably cancel* a running asynchrounous generator.


# Dilemma

Replicating the behavior of synchronous generators in asynchronous generators 
seems like the right thing.  But it seems that the requirements for 
asynchronous generators are different, and 3.8 breaks backwards compat.


# Proposed Solution

We keep "asend()" and "athrow()" as is in 3.8.  They will continue to raise 
RuntimeError if used in parallel on the same async generator.

We modify "aclose()" to allow it being called in parallel with "asend()" or 
"athrow()".  This will restore the <3.8 behavior and fix the 
"loop.shutdown_asyncgens()" method.


Thoughts?

--
components: Interpreter Core
messages: 355158
nosy: asvetlov, gvanrossum, lukasz.langa, ncoghlan, njs, yselivanov
priority: normal
severity: normal
status: open
title: async generators aclose() behavior in 3.8
type: behavior
versions: Python 3.8, Python 3.9

___
Python tracker 

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

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[STINNER Victor]

Change by STINNER Victor :


--
title: test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 
3.x -> asyncio: MultiLoopWatcher has a race condition (test_asyncio: 
test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

___
Python tracker 

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

[issue38323] test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I'm able to reproduce the issue locally using the command:

./python -m test test_asyncio 
--match=test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests.test_close_kill_running
 -v -F -j20 --timeout=30.0

Example:

...
0:00:47 load avg: 14.35 [287] test_asyncio passed -- running: test_asyncio 
(31.1 sec)
0:00:47 load avg: 14.35 [288] test_asyncio passed -- running: test_asyncio 
(31.3 sec)
0:00:47 load avg: 14.35 [289/1] test_asyncio crashed (Exit code 1)
Timeout (0:00:30)!
Thread 0x7f3bbd098740 (most recent call first):
  File "/home/vstinner/python/master/Lib/selectors.py", line 468 in select
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 1837 in 
_run_once
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 589 in 
run_forever
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 621 in 
run_until_complete
  File "/home/vstinner/python/master/Lib/test/test_asyncio/test_subprocess.py", 
line 484 in test_close_kill_running
...


I added some debug traces.

Logs when it works:
---
0:01:39 load avg: 21.21 [512] test_asyncio passed -- running: test_asyncio 
(31.0 sec)
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... 
MultiLoopChildWatcher: attach_loop <_UnixSelectorEventLoop running=False 
closed=False debug=False>
MultiLoopChildWatcher: SIGCHLD signal registered
MultiLoopChildWatcher: attach_loop None
MultiLoopChildWatcher: attach_loop None
MultiLoopChildWatcher: SIGCHLD signal registered
ok

--

Ran 1 test in 0.054s

OK
MultiLoopChildWatcher: _do_waitpid 27887
MultiLoopChildWatcher: _do_waitpid (0, 0)
kill 27887 9
MultiLoopChildWatcher: _sig_chld
MultiLoopChildWatcher: _do_waitpid_all
MultiLoopChildWatcher: _do_waitpid 27887
MultiLoopChildWatcher: _do_waitpid (27887, 9)
MultiLoopChildWatcher: _do_waitpid: call (>, <_UnixSelectorEventLoop running=True 
closed=False debug=False>)
---

Logs when it hangs:
---
0:01:40 load avg: 21.21 [514/1] test_asyncio crashed (Exit code 1)
test_close_kill_running 
(test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... 
MultiLoopChildWatcher: attach_loop <_UnixSelectorEventLoop running=False 
closed=False debug=False>
MultiLoopChildWatcher: SIGCHLD signal registered
MultiLoopChildWatcher: _do_waitpid 26010
MultiLoopChildWatcher: _do_waitpid (0, 0)
kill 26010 9
Timeout (0:00:30)!
Thread 0x7f4b73f35740 (most recent call first):
  File "/home/vstinner/python/master/Lib/selectors.py", line 468 in select
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 1837 in 
_run_once
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 589 in 
run_forever
  File "/home/vstinner/python/master/Lib/asyncio/base_events.py", line 621 in 
run_until_complete
  File "/home/vstinner/python/master/Lib/test/test_asyncio/test_subprocess.py", 
line 484 in test_close_kill_running
...
---

It seems like sometimes, MultiLoopChildWatcher._sig_chld() is not called.

--

___
Python tracker 

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

[issue35448] ConfigParser .read() - handling of nonexistent files

[Adrian Wielgosik]

Adrian Wielgosik  added the comment:

Yeah, I lost steam on this issue, sorry. Go ahead :)

--

___
Python tracker 

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

[issue38538] dictobject dictviews don't return NotImplemented for unrecognized types.

[Julien Palard]

Julien Palard  added the comment:

> It is not strange since dict.keys() in Python 2.7 returns list.

Oh, ok thanks :)

Do you think that it should be fixed? As it works with sets, I think so:

>>> set() | Ror()
set()

but it's not that simple as the __or__ of dictviews is less strict that the 
__or__ of set: __or__ of dictview accept any iterable, __or__ of set only 
accepts sets.

--

___
Python tracker 

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

[issue38466] [Easy doc] threading.excepthook doc talks about "object"

[miss-islington]

miss-islington  added the comment:


New changeset 6329a56ca7f99075caa95a075024736a90ad2857 by Miss Skeleton (bot) 
in branch '3.8':
bpo-38466: Fix threading.excepthook doc (GH-16891)
https://github.com/python/cpython/commit/6329a56ca7f99075caa95a075024736a90ad2857


--
nosy: +miss-islington

___
Python tracker 

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

[issue38466] [Easy doc] threading.excepthook doc talks about "object"

[miss-islington]

Change by miss-islington :


--
pull_requests: +16433
pull_request: https://github.com/python/cpython/pull/16894

___
Python tracker 

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

[issue38466] [Easy doc] threading.excepthook doc talks about "object"

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 91528f40c30717563a478920861c81d18da5bf63 by Victor Stinner 
(Daniel Baskal) in branch 'master':
bpo-38466: Fix threading.excepthook doc (GH-16891)
https://github.com/python/cpython/commit/91528f40c30717563a478920861c81d18da5bf63


--

___
Python tracker 

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

[issue38558] Data Structures documentation out of sync with new Walrus operator

[Matt Ward]

New submission from Matt Ward :

The 3.8 documentation still includes the text.

```Note that in Python, unlike C, assignment cannot occur inside expressions. C 
programmers may grumble about this, but it avoids a common class of problems 
encountered in C programs: typing = in an expression when == was intended.```

https://docs.python.org/3.8/tutorial/datastructures.html#more-on-conditions

This would seem to no longer be the case with with the inclusion of 
https://www.python.org/dev/peps/pep-0572/ in 3.8 unless I am misunderstanding 
the above statement.

--
assignee: docs@python
components: Documentation
messages: 355151
nosy: Matt Ward, docs@python
priority: normal
severity: normal
status: open
title: Data Structures documentation out of sync with new Walrus operator
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[STINNER Victor]

STINNER Victor  added the comment:

According to Adam J. Stewart, my PR 16717 fix the Python build on ICC:
https://github.com/python/cpython/pull/16717#issuecomment-544812182

So I merged it in 3.7, 3.8 and master branches.

Adam saw other failures, but it's unrelated issues which should be reported 
separately.

Thanks for the bug report Borja. It should now be fixed. Until a new Python 
version is released with the fix, you should either apply the patch manually or 
use a different compiler. GCC and Clang are well supported on Linux for example.

--
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

[issue38323] test_ayncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

Also on x86 Gentoo Refleaks 3.x:

https://buildbot.python.org/all/#/builders/1/builds/754

6:11:43 load avg: 1.44 [419/419/2] test_asyncio crashed (Exit code 1)
beginning 6 repetitions
123456
Timeout (3:15:00)!
Thread 0xb7c4d700 (most recent call first):
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.refleak/build/Lib/selectors.py",
 line 468 in select
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.refleak/build/Lib/asyncio/base_events.py",
 line 1837 in _run_once
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.refleak/build/Lib/asyncio/base_events.py",
 line 589 in run_forever
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.refleak/build/Lib/asyncio/base_events.py",
 line 621 in run_until_complete
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.refleak/build/Lib/test/test_asyncio/test_subprocess.py",
 line 484 in test_close_kill_running

--

___
Python tracker 

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

[issue38323] test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x

[STINNER Victor]

Change by STINNER Victor :


--
title: test_ayncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x 
-> test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x

___
Python tracker 

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

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[miss-islington]

miss-islington  added the comment:


New changeset dbcea39ba713cc5b31fa1a243b16a0128c231c98 by Miss Skeleton (bot) 
in branch '3.8':
bpo-37415: Fix stdatomic.h header check for ICC compiler (GH-16717)
https://github.com/python/cpython/commit/dbcea39ba713cc5b31fa1a243b16a0128c231c98


--

___
Python tracker 

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

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[miss-islington]

miss-islington  added the comment:


New changeset b102e4f05278c1b06130885eba961bd0193733b4 by Miss Skeleton (bot) 
in branch '3.7':
bpo-37415: Fix stdatomic.h header check for ICC compiler (GH-16717)
https://github.com/python/cpython/commit/b102e4f05278c1b06130885eba961bd0193733b4


--
nosy: +miss-islington

___
Python tracker 

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

[issue38447] test_multiprocessing_spawn: Dangling processes: {} on AMD64 RHEL7 Refleaks 3.7

[STINNER Victor]

STINNER Victor  added the comment:

New failure on AMD64 RHEL7 Refleaks 3.7:

https://buildbot.python.org/all/#/builders/311/builds/34

0:18:35 load avg: 2.24 [414/416/1] test_multiprocessing_spawn failed (env 
changed) (13 min 55 sec) -- running: test_concurrent_futures (8 min 43 sec), 
test_asyncio (5 min 48 sec)
beginning 6 repetitions
123456
.Warning -- Dangling processes: {}
.

--

___
Python tracker 

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

[issue28562] test_asyncio fails on Android upon calling getaddrinfo()

[STINNER Victor]

STINNER Victor  added the comment:

Ok, thanks Xavier. If someone has an issue with test_asyncio on Android, either 
reopen this issue or open a new issue ;-)

--
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

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[miss-islington]

Change by miss-islington :


--
pull_requests: +16432
pull_request: https://github.com/python/cpython/pull/16893

___
Python tracker 

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

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 028f7349a0f6eaea0fec31becb587fcdf6e3cb28 by Victor Stinner in 
branch 'master':
bpo-37415: Fix stdatomic.h header check for ICC compiler (GH-16717)
https://github.com/python/cpython/commit/028f7349a0f6eaea0fec31becb587fcdf6e3cb28


--

___
Python tracker 

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

[issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t

[miss-islington]

Change by miss-islington :


--
pull_requests: +16431
pull_request: https://github.com/python/cpython/pull/16892

___
Python tracker 

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

[issue38466] [Easy doc] threading.excepthook doc talks about "object"

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +16430
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16891

___
Python tracker 

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

[issue38460] 3.8 Release Notes: document asyncio exception changes

[Andrew Svetlov]

Andrew Svetlov  added the comment:

> code that incorrectly imported directly from the submodules will break

That's true. Please note: incorrect code will break. The correct code keeps 
working.

I'm personally not sure if we need to reflect *private* API change in Release 
Notes.

Another question is: should Release Notes reflect all API updates? We strictly 
control `versionadded` and `versionchanged` usage in asyncio docs but don't do 
it for whatsnew files.

--

___
Python tracker 

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

[issue24313] json fails to serialise numpy.int64

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

We could use __index__ for serializing numpy.int64. But what to do with 
numpy.float32 and numpy.float128? It is a part of a much larger problem (which 
includes other numbers, collections, encoded strings, named tuples and data 
classes, etc). I am working on it, but there is a lot of work.

--

___
Python tracker 

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

[issue38460] 3.8 Release Notes: document asyncio exception changes

[Sebastian Rittau]

Sebastian Rittau  added the comment:

Also it seems there are various new arguments and methods in asyncio that are 
not in the release notes. (Via https://github.com/python/typeshed/issues/2313).

--

___
Python tracker 

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

[issue38557] PyTuple_GetSlice docs minor inaccuracy

[wim glenn]

New submission from wim glenn :

https://docs.python.org/3/c-api/tuple.html#c.PyTuple_GetSlice

In the c-api it says (emphasis mine):

PyObject* PyTuple_GetSlice(PyObject *p, Py_ssize_t low, Py_ssize_t high)¶
Return value: New reference.

Take a slice of the tuple pointed to by p from low to high and return it 
**as a new tuple**.

But when slicing the entire tuple, CPython will return already existing 
instance, not a new tuple.

https://github.com/python/cpython/blob/3.8/Objects/tupleobject.c#L448-L451

I propose the language in the docs be loosened so as not to tie the hands of 
implementation

--
assignee: docs@python
components: Documentation
messages: 355141
nosy: docs@python, wim.glenn
priority: normal
severity: normal
status: open
title: PyTuple_GetSlice docs minor inaccuracy
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue38556] Walrus operator in list comprehensions [Python 3.8.0]

[Eric V. Smith]

Eric V. Smith  added the comment:

This is explicitly mentioned in PEP 572 as being disallowed:

"Due to design constraints in the reference implementation (the symbol table 
analyser cannot easily detect when names are re-used between the leftmost 
comprehension iterable expression and the rest of the comprehension), named 
expressions are disallowed entirely as part of comprehension iterable 
expressions (the part after each "in", and before any subsequent "if" or "for" 
keyword):"

The error message also makes it clear.

--
nosy: +eric.smith
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

[issue38554] A fatal error in test_descr

[Emmanuel Arias]

Emmanuel Arias  added the comment:

I' am using:
Python 3.9.0a0 (heads/master:f548a3e4a2, Oct 22 2019, 12:02:14) 
[GCC 6.3.0 20170516]

On Debian 9

--

___
Python tracker 

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

[issue38554] A fatal error in test_descr

[Emmanuel Arias]

Emmanuel Arias  added the comment:

I can't reproduce the error

--
nosy: +eamanu

___
Python tracker 

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

[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> out of date
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

[issue38539] Update demo files

[Julin]

Julin  added the comment:

I've made a PR. Can you review it?

--

___
Python tracker 

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

[issue35448] ConfigParser .read() - handling of nonexistent files

[Batuhan]

Batuhan  added the comment:

Adrian are you still want to work on this or can i take it?

--
nosy: +BTaskaya

___
Python tracker 

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

[issue25635] urllib2 cannot fully read FTP file

[Batuhan]

Batuhan  added the comment:

It works as expected on master (3.9.0a0). I think we can close this

--
nosy: +BTaskaya

___
Python tracker 

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

[issue38539] Update demo files

[Julin]

Change by Julin :


--
keywords: +patch
pull_requests: +16428
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16890

___
Python tracker 

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

[issue24313] json fails to serialise numpy.int64

[Batuhan]

Batuhan  added the comment:

What is the next step of this 4-year-old issue? I think i can prepare a patch 
for using __index__ (as suggested by @r.david.murray)

--
nosy: +BTaskaya

___
Python tracker 

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

[issue28562] test_asyncio fails on Android upon calling getaddrinfo()

[Xavier de Gaye]

Xavier de Gaye  added the comment:

According to my last post on this issue 2 years ago, this test "does not fail 
on android-24-x86_64". This means that it does not fail on API level 24. IMO 
the issue may be closed.

--

___
Python tracker 

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

[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

[Batuhan]

Batuhan  added the comment:

we can close this (raymond resolved this in bpo-35864)

--
nosy: +BTaskaya

___
Python tracker 

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

[issue38556] Walrus operator in list comprehensions [Python 3.8.0]

[EGN]

EGN  added the comment:

Even the simple code like this doesn't work:

[print(p) for n in (p := ['a', 'b', 'c'])]

--

___
Python tracker 

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

[issue38556] Walrus operator in list comprehensions [Python 3.8.0]

[EGN]

EGN  added the comment:

But if I'm taking main for loop out of the square brackets everything works 
fine.

from os import getcwd, listdir, rename
import re

for n in listdir(p := f"{getcwd()}\\{input('Folder: ')}\\"):
[rename(f'{p}{n}', f"{p}{''.join([w[:3] if len(w) > 3 else w for w in 
re.split('[-_. ]', n)[:-1]])}.{n.split('.')[-1]}")]

--

___
Python tracker 

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

[issue38556] Walrus operator in list comprehensions [Python 3.8.0]

[EGN]

EGN  added the comment:

from os import getcwd, listdir, rename
import re

[rename(f'{p}{n}', f"{p}{''.join([w[:3] if len(w) > 3 else w for w in 
re.split('[-_. ]', n)[:-1]])}.{n.split('.')[-1]}")
 for n in listdir(p := f"{getcwd()}\\{input('Folder: ')}\\")]

When I run this code, I'm getting:
  File "C:\Users\1\Desktop\sn.py", line 4
[rename(f'{p}{n}',f"{p}{''.join([w[:3] if len(w)>3 else w for w in 
re.split('[-_. ]',n)[:-1]])}.{n.split('.')[-1]}") for n in 
listdir(p:=f"{getcwd()}\\{input('Folder: ')}\\")]

 ^
SyntaxError: assignment expression cannot be used in a comprehension iterable 
expression

Process finished with exit code 1

--

___
Python tracker 

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

[issue38303] Make audioop PEP-384 compatible

[Tyler Kieft]

Change by Tyler Kieft :


--
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

[issue38303] Make audioop PEP-384 compatible

[miss-islington]

miss-islington  added the comment:


New changeset f548a3e4a28c5496755f9f8d057fc8d031b27655 by Miss Skeleton (bot) 
(Tyler Kieft) in branch 'master':
bpo-38303: Make audioop extension module PEP-384 compatible (GH-16497)
https://github.com/python/cpython/commit/f548a3e4a28c5496755f9f8d057fc8d031b27655


--
nosy: +miss-islington

___
Python tracker 

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