[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Volker Weißmann added the comment: The PR below fixed it: https://github.com/python/cpython/pull/23135 -- ___ Python tracker <https://bugs.python.org/issue17

[issue17852] Built-in module _io can lose data from buffered files in reference cycles

Change by Volker Weißmann : -- nosy: +Volker Weißmann nosy_count: 12.0 -> 13.0 pull_requests: +22049 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23135 ___ Python tracker <https://bugs.python.org/i

[issue17805] No such class: multiprocessing.pool.AsyncResult

Change by Volker Weißmann : -- pull_requests: +20440 pull_request: https://github.com/python/cpython/pull/21291 ___ Python tracker <https://bugs.python.org/issue17

[issue17805] No such class: multiprocessing.pool.AsyncResult

Volker Weißmann added the comment: Tomorror, or in a few days, I'm gonna create a pullrequest for it. -- ___ Python tracker <https://bugs.python.org/issue17

[issue17805] No such class: multiprocessing.pool.AsyncResult

Volker Weißmann added the comment: The documentation here: https://docs.python.org/3/library/multiprocessing.html#module-multiprocessing.pool says that apply_async is "A variant of the apply() method which returns a result object." You should replace "a result object"

[issue40218] sys.executable is a false path if python is executed from gdb

Volker Weißmann added the comment: Ok, thank you. I hope that the gdb guys will respon -- ___ Python tracker <https://bugs.python.org/issue40218> ___ ___ Pytho

[issue40218] sys.executable is a false path if python is executed from gdb

Volker Weißmann added the comment: "I have never used gdb, but I am curious what *is* the path to the python running the python code after 'python'? Is it part of or included with gdb?" I honestly don't know. I think the python interpreter gets compiled into the python binar

[issue40203] Warn about invalid PYTHONUSERBASE

Volker Weißmann added the comment: "there is no good reason to do so" meant that there is no good reason to set PYTHONUSERBASE to non existing path or a path that is not a directory. The history behind this bug report is that I used a program that, because of a bug in this pr

[issue40218] sys.executable is a non existing path if python is executed from gdb

Volker Weißmann added the comment: The gdb issue is here: https://sourceware.org/bugzilla/show_bug.cgi?id=25800 -- ___ Python tracker <https://bugs.python.org/issue40

[issue40218] sys.executable is a non existing path if python is executed from gdb

New submission from Volker Weißmann : Note: I'm not sure if this is a bug in python or in gdb. I will also submit a bug report to gdb and post a link here. Pythons documentation says that sys.executable is always either None, empty string or a path to the python interpreter. Using gdb

[issue40203] Warn about invalid PYTHONUSERBASE

Volker Weißmann added the comment: Forget the thing I said about "invalid//path", but my argument still stands for non existing paths or paths to something else than a directory. -- ___ Python tracker <https://bugs.python.o

[issue40203] Warn about invalid PYTHONUSERBASE

New submission from Volker Weißmann : https://docs.python.org/2/using/cmdline.html says that PYTHONUSERBASE defines the user base directory. If I understand this correctly, this implies that PYTHONUSERBASE should be a path a directory. I therefore think that python should print a warning

[issue40159] Make python -V -V output arguments of configure

Change by Volker Weißmann : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40159> ___ ___ Python-bugs-list

[issue40159] Make python -V -V output arguments of configure

New submission from Volker Weißmann : As you might know, you can e.g. compile a version with ../configure --with-pydebug or with ../configure Currently, there is no easy way to find out how an installation on your machine was compiled. It would be nice if python -V -V would output every