[issue42314] Incorrect documentation entry for venv
New submission from Adrien : Hello, I am reading the venv official documentation available here: https://docs.python.org/3/library/venv.html If I pick English - 3.9.0, it's stated: "Changed in version 3.8: Add --upgrade-deps option to upgrade pip + setuptools to the latest on PyPI" When I run this my laptop: $ python3 --version Python 3.8.5 $ python3 -m venv venv-myproject --clear --upgrade-deps usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear] [--upgrade] [--without-pip] [--prompt PROMPT] ENV_DIR [ENV_DIR ...] venv: error: unrecognized arguments: --upgrade-deps If I pick English - 3.8(.6), I (correctly) don't see the option in the documentation. Please fix the documentation of 3.9 to indicates that this option was changed (added) in 3.9 and not 3.8 Thanks! Adrien -- assignee: docs@python components: Documentation messages: 380684 nosy: ari75, docs@python priority: normal severity: normal status: open title: Incorrect documentation entry for venv type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38520] There is no proper way to know if a process is the main one
New submission from Adrien : Hi. I noticed that there exists the function "threading.main_thread()", but there is no equivalent for the "multiprocessing" module. Is there a reason for this absence? These StackOverflow questions are related to this problem: - https://stackoverflow.com/questions/42283265/how-to-determine-if-running-current-process-is-parent - https://stackoverflow.com/questions/30790660/python-multiprocessing-name-of-the-main-process - https://stackoverflow.com/questions/18216050/is-there-a-way-to-check-if-a-module-is-being-loaded-by-multiprocessing-standard Current proposed solutions have flaws. It's suggested to check if "current_process().name == 'MainProcess'" but anyone can re-write the name of a process with "current_process().name = 'foobar'" so this does not seem to be a reliable solution. Another alternative is to check for the type of the process, which is different for main and child, respectively "mulitprocessing.process._MainProcess" and "multiprocessing.process.Process". This is obviously hacky as it relies on implementation detail. What are you thoughts on adding a new "multiprocessing.main_process()" function? -- components: Library (Lib) messages: 354918 nosy: Delgan priority: normal severity: normal status: open title: There is no proper way to know if a process is the main one type: enhancement ___ Python tracker <https://bugs.python.org/issue38520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37365] RecursionError not caught explicitly may crash with "Aborted (core dumped)"
Adrien added the comment: Thanks to your answer, @ned.deily. Sorry to insist, but are you sure this is a duplicate of issue18075 / issue35542? According to the discussion in issue36272, it seems this is not related to stack exhaustion nor to issue18075. Also, @remi.lapeyre suggested that a fix could be possible by modifying ceval.c. (re-raise RecursionError if it has been cleared). issue18075 and issue35542 are both of status "closed", I would expect this issue to be duplicate to an "open" issue because there is a clear reproducible "bug" which crashes the interpreter. There is also the problems still remaining in logging Handlers that I linked. I think this is an issue with how recursion error are handled in ceval.c, this is related to "tstate->overflowed" and "tstate->recursion_depth > recursion_limit + 50". If I understand correctly, this is implemented like this to allow gracefully catch and handle RecursionError from the calling function. For example, why not re-raise the exception if the first one could not be handled correctly? -- ___ Python tracker <https://bugs.python.org/issue37365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37365] RecursionError not caught explicitly may crash with "Aborted (core dumped)"
New submission from Adrien : This is an issue that I first saw repoted by @remi.lapeyre on issue36272: https://bugs.python.org/issue36272#msg337843 It also be reported some years ago: https://stackoverflow.com/a/54171640/2291710 I searched but I did not find any existing issue, so I open a new one, I hope this is not a duplicate. It's easily reproducible: def rec(): try: rec() except Exception: rec() rec() It will kill the CPython interpreter (@remi.lapeyre provided explanation in the issue I linked). Of course, this is a contrived example. Still, I guess CPython should avoid to crash in any situation. This is a tricky edge case: by doing `except Exception:` one could expect to correctly handle all kind of errors without being aware that in some situation the "RecursionError" need to be managed too. Particularly, the fix in issue36272 solely patches "StreamHandler": https://github.com/python/cpython/blob/65f64b1903ae85b97a30f514bbc1b7ce940c3af2/Lib/logging/__init__.py#L1082-L1102 There is many other handlers that are still affected, every time you see "except Exception" in "emit()": https://github.com/python/cpython/blob/65f64b1903ae85b97a30f514bbc1b7ce940c3af2/Lib/logging/handlers.py Finally, it should also be noted that the "except RecursionError" workaround implies that loggers are not longer able to catch recursive erros in "write()" or "format()" without re-raising the RecursionError and (probably) halting the program. It may happen for example that a faulty implementation of a custom Handler or LogRecord attribute cause a RecursionError. Thanks to the "raiseExceptions = false" logging option, this would usually be caught and a message printed on stderr without killing the app. -- messages: 346232 nosy: Delgan priority: normal severity: normal status: open title: RecursionError not caught explicitly may crash with "Aborted (core dumped)" type: crash ___ Python tracker <https://bugs.python.org/issue37365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None
Adrien added the comment: Actually, this also occurs while using "astimezone()" on a custom child class (I suppose this method is used by "fromtimestamp()"). -- ___ Python tracker <https://bugs.python.org/issue35364> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None
New submission from Adrien : Hello. I created a class inheriting from "datetime.datetime". While creating a new instance using the classmethod "fromtimestamp" it seems to work, except if I provide a timezone object. In such case, the returned object is of base type datetime. This looks like a bug, isn't it? If not, I guess this should be mentioned somewhere in the documentation. Tested on Python 3.6 and 3.7, my apologies if this has been fixed in 3.8. NB: I first opened a question on SO -> https://stackoverflow.com/questions/53561996/datetime-fromtimestamp-ignores-inheritance-if-timezone-is-not-none -- components: Library (Lib) files: test.py messages: 330811 nosy: Delgan priority: normal severity: normal status: open title: Datetime “fromtimestamp()” ignores inheritance if timezone is not None type: behavior versions: Python 3.6, Python 3.7 Added file: https://bugs.python.org/file47960/test.py ___ Python tracker <https://bugs.python.org/issue35364> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35038] AttributeError: 'frame' object has no attribute 'f_restricted'
New submission from Adrien : In the documentation (https://docs.python.org/3/library/inspect.html#types-and-members), the attribute `f_restricted` is listed as a member of `frame` objects. However, while trying to access it or even when calling `help()`, the object does not seem to have such attribute. Is it a issue with the documentation that has not been updated? I'm using Python 3.6.3 on Linux. -- assignee: docs@python components: Documentation messages: 328217 nosy: Delgan, docs@python priority: normal severity: normal status: open title: AttributeError: 'frame' object has no attribute 'f_restricted' type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue35038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33047] "RuntimeError: dictionary changed size during iteration" using trace.py module
Adrien <delgan...@gmail.com> added the comment: Thanks for your attention to this issue. I am not surprised that you was not able to reproduce it as it seems deeply related to multiprocessing and threads. I tested it on 3 others completely different computers, and I was able to reproduce the error for 2 of them which were running Ubuntu 16.04 and Windows 10. I made a totally fresh install of Python 3.6.4, the Windows machine never had Python installed before. The only common point between computers where the error occurs compared to the third one, whether running Windows or Linux, is that they have a fairly old or weak hardware, and therefore are slower. Fortunately, the error was systematic on my machine. So I was able to study the trace.py code to try to isolate the problem. Piece by piece, I simplified trace.py to get a small snippet that reproduces the bug (I joined the file to this message). Sometimes, there is also a "BrokenPipeError" which pop-out. I do not know if this is related. The error seems to come from the fact that "counts" start to be iterated while compiled code execution is not fully terminated, and so "localtrace_count" may add another item to the dict. Move the "time.sleep()" before the loop and the error should gone. This is most likely related to the internal thread used by Queue as using a SimpleQueue doesn't raise an exception. As I do not have access for now to a computer where the error does not occur, I can not continue my investigations. However I hope that I give a little more information so that you maybe succeed to reproduce it. -- Added file: https://bugs.python.org/file47493/minitrace.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33076] Trying to cleanly terminate a threaded Queue at exit of program raises an "EOFError"
New submission from Adrien <delgan...@gmail.com>: Hi. I use a worker Thread to which I communicate trough a multiprocessing Queue. I would like to properly close this daemon thread when my program terminates, so I registered a "stop()" function using "atexit.register()". However, this raises an "EOFError" because the multiprocessing module uses "atexit.register()" too and closes the Queue internal pipe connections before that my thread ends. After scratching inside the multiprocessing module, I tried to summarize my understanding of the problem here: https://stackoverflow.com/a/49244528/2291710 I joined a demonstration script that triggers the bug with (at least) Python 3.5/3.6 on both Windows and Linux. The issue is fixable by forcing multiprocessing "atexit.register()" before mine with "import multiprocessing.queues", but this means I would rely on an implementation detail, and others dynamic calls made to "atexit.register()" (like one I saw in multiprocessing "get_logger()" for example) could break it again. I first thought that "atexit.register()" could accept an optional "priority" argument, but every developers would probably want to be first. Could a subtle change be made however to guarantee that registered functions are executed before Python internal ones? As for now, the atexit statement "The assumption is that lower level modules will normally be imported before higher level modules and thus must be cleaned up later" is not quite true. I do not know what to do with it, from what I know there is no way to achieve an automatic yet clean closure of such worker, so I would like to know if some kind of fix is possible for a future version of Python. Thanks for your time. -- components: Library (Lib) files: bug.py messages: 313841 nosy: Delgan priority: normal severity: normal status: open title: Trying to cleanly terminate a threaded Queue at exit of program raises an "EOFError" type: behavior versions: Python 3.5, Python 3.6 Added file: https://bugs.python.org/file47486/bug.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33047] "RuntimeError: dictionary changed size during iteration" using trace.py module
New submission from Adrien <delgan...@gmail.com>:
Hello.
I am strangely encountering an error whil trying to run "python -m trace -c
script.py" on this simple code:
> import multiprocessing
> queue = multiprocessing.Queue()
> queue.put("a")
Which raises on Windows 10 using Python 3.6.3:
> Traceback (most recent call last):
> File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
> "__main__", mod_spec)
> File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
> exec(code, run_globals)
> File "/usr/lib/python3.6/trace.py", line 742, in
> main()
> File "/usr/lib/python3.6/trace.py", line 739, in main
> results.write_results(opts.missing, opts.summary, opts.coverdir)
> File "/usr/lib/python3.6/trace.py", line 258, in write_results
> for filename, lineno in self.counts:
> RuntimeError: dictionary changed size during iteration
Fixing it seems straightforward, but I do not know what is causing the bug
internally.
--
components: Library (Lib)
messages: 313604
nosy: Delgan
priority: normal
severity: normal
status: open
title: "RuntimeError: dictionary changed size during iteration" using trace.py
module
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33047>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32698] Improper gzip compression if output file extension is not "gz"
Adrien <delgan...@gmail.com> added the comment: Thanks @martin.panter for your response. I will close this issue as "not a bug" as there is a workaround and as the current behavior could be deduced by reading carefully the entire documentation. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32698] Improper gzip compression if output file extension is not "gz"
New submission from Adrien <delgan...@gmail.com>:
Hello.
The following code produces a improper compressed "test.txt.gzip" file:
import gzip
import shutil
input_path = "test.txt"
output_path = input_path + ".gzip"
with open(input_path, 'w') as file:
file.write("abc" * 10)
with gzip.open(output_path, 'wb') as f_out:
with open(input_path, 'rb') as f_in:
shutil.copyfileobj(f_in, f_out)
Although the content can be read correctly using `gzip.open(outputh_path,
'rb')`, it cannot be correctly opened using software like 7-Zip or WinRar.
If I open the "test.txt.gzip" file, it contains another "test.txt.gzip" file.
If I change the code to use ".gz" extension and then open "test.txt.gz", it
contains the expected "test.txt" file.
The contained "test.txt.gzip" is actually the same (at bytes level) that
"test.txt", just the filename differs which causes tools like 7-Zip to mess up.
The bug is not present using compressions functions from "bz2" and "lzma"
modules. I can use custom extension, it still can be (un)compressed without
issue.
As to why I need to use an extension differents from ".gz": I would like to
compress arbitrary ".tar" file given in input to ".tgz". I wish the user could
open the file in his favorite software archiver and see that it contains a
".tar" file, rather than he does not understand why it contains the same ".tgz"
file.
--
components: Library (Lib)
files: test.py
messages: 310978
nosy: Delgan
priority: normal
severity: normal
status: open
title: Improper gzip compression if output file extension is not "gz"
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47414/test.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32698>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30865] python cannot import module located on a "VOLUME" directory
New submission from Adrien Pré: This issue created on python-docker project https://github.com/docker-library/python/issues/210 indicates that python cannot import a module if it is located on a docker-volume. yosifkit's comment suggest there is an issue in the UNC resolution with paths starting with `\\?\` Thesre is probably a fix to do in Lib\ntpath.py, however I am not sure how to fix that. Steps to reproduce the issues are here: https://github.com/apre/windows-volume-issue -- components: Library (Lib) messages: 297820 nosy: Adrien Pré priority: normal severity: normal status: open title: python cannot import module located on a "VOLUME" directory type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10839] email module should not allow some header field repetitions
New submission from Adrien Saladin adrien.sala...@gmail.com: Hi, The following script shows two problems with email.mime.text.MIMEText: - first the use of msg['To'] seems confusing because its dictionnary-like syntax made me think it acts as a set or replace, but in fact is working as a stream operation - second this behavior allows for the same field to be repeated several times in a header which is discouraged in rfc-822 and forbidden for many fields in rfc-2822. # from email.mime.text import MIMEText msg = MIMEText(Hello World) dest = [o...@example.com, t...@example.com, th...@example.com, f...@example.com] for d in dest: msg[From] = mys...@example.com msg[To] = d msg[subject] = just a test print (msg) # + send the buggy mail... ### the last sent mail will looks like this: - Hello World Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: mys...@example.com To: o...@example.com subject: just a test From: mys...@example.com To: t...@example.com subject: just a test From: mys...@example.com To: th...@example.com subject: just a test From: mys...@example.com To: f...@example.com subject: just a test Hello World -- I see some possible modifications: * make the [] operator work as a dictionnary-like syntax. So calling msg['To'] multiple times would simply replace the previous 'To:' field. The additional constraint is that some fields like 'comments' or 'keywords' can be repeated * (or) throw an error when some fields are repeated in this list: from, sender, reply-to, to, cc, bcc, message-id, in-reply-to, references, subject -- components: Library (Lib) messages: 125473 nosy: adrien-saladin priority: normal severity: normal status: open title: email module should not allow some header field repetitions versions: Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10839] email module should not allow some header field repetitions
Changes by Adrien Saladin adrien.sala...@gmail.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
