[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/issue17852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue17852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue17805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue17805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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" with "a AsyncResult/ApplyResult object" and a link to https://docs.python.org/2/library/multiprocessing.html#multiprocessing.pool.AsyncResult ------ nosy: +Volker Weißmann versions: +Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.3, Python 3.4 ___ Python tracker <https://bugs.python.org/issue17805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 binary, because as a test, I removed every python interpreter on my system that I could find and the "python" command inside gdb still worked. But it uses some of pythons shared libraries that get installed when you install python. I also suspect that it is a bug in gdb. I think the only thing you can do is take a look at python's source code on how it finds sys.executable and check if it looks fishy or if it looks like it should never point to a non existing file. And we can wait if the gdb programmers will respond. -- ___ Python tracker <https://bugs.python.org/issue40218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 program, set PYTHONUSERBASE to a non existing path, and I wondered why "import cython" raised a ModuleNotFoundError even though I had installed cython. -- ___ Python tracker <https://bugs.python.org/issue40203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue40218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 and python, we can produce situations where this is not true. Simple but unrealistic way to reproduce this bug: Install gdb with python support. E.g using $ pacman -S gdb Remove all the python binaries: $ rm /usr/bin/python $ rm /usr/bin/python3 $ rm /usr/bin/python3.8 Run $gdb -x gdbinit$ with the contents of gdbinit being: python import sys import os print(sys.executable) print(os.path.exists(sys.executable)) end Result: /usr/bin/python False Here, sys.executable is /usr/bin/python, but there is no python executable in /usr/bin/python, because we just deleted it. Complicated but realistic way to reproduce this bug: Build gdb with ../configure --with-python=python2 and run gdb with the gdbinit being: python import sys print(sys.executable) print(sys.version) end Result: /usr/bin/python 2.7.17 (default, Mar 21 2020, 00:47:07) [GCC 9.3.0] Here it says that the python2 executable lies in "/usr/bin/python", even if there is no python2 executable in /usr/bin/python. -- messages: 365934 nosy: Volker Weißmann priority: normal severity: normal status: open title: sys.executable is a non existing path if python is executed from gdb ___ Python tracker <https://bugs.python.org/issue40218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue40203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 if PYTHONUSERBASE is: 1. Not a valid path (e.g. "invalid//path") 2. A path to something else than a directory 3. A non existing path (maybe) I think that export PYTHONUSERBASE="invalid//path" python should generate a warning, because there is no good reason to do so. -- messages: 365851 nosy: Volker Weißmann priority: normal severity: normal status: open title: Warn about invalid PYTHONUSERBASE type: enhancement ___ Python tracker <https://bugs.python.org/issue40203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 argument of configure. -- messages: 365620 nosy: Volker Weißmann priority: normal severity: normal status: open title: Make python -V -V output arguments of configure type: enhancement ___ Python tracker <https://bugs.python.org/issue40159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
