[issue34813] child process disappears when removing a print statement after its creation

2018-09-26 Thread calimeroteknik
calimeroteknik added the comment: So this is invalid library usage, we need to run .wait() on the Popen object. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34813] child process disappears when removing a print statement after its creation

2018-09-26 Thread calimeroteknik
Change by calimeroteknik : Added file: https://bugs.python.org/file47830/except-out.py ___ Python tracker <https://bugs.python.org/issue34813> ___ ___ Python-bugs-list m

[issue34813] child process disappears when removing a print statement after its creation

2018-09-26 Thread calimeroteknik
New submission from calimeroteknik : When two processes are created and killed, the behaviour is different if print or sleep statements are inserted. It can also be random (different results executing the same program several times) on certain machines and versions of python. Attached two

[issue34781] infinite waiting in multiprocessing.Pool

2018-09-26 Thread calimeroteknik
calimeroteknik added the comment: Attaching the version that randomly raises ChildProcessError: [Errno 10] No child processes. The child process is lost in limbo if we don't sleep/print after creating it. -- Added file: https://bugs.python.org/file47828/except-out.py

[issue34781] infinite waiting in multiprocessing.Pool

2018-09-26 Thread calimeroteknik
calimeroteknik added the comment: A friend has found a very simple example that triggers such an issue in a very reproducible manner. Attached two versions, one where the child process mysteriously disappears in the cpython interpreter. pypy is unaffected. -- nosy: +calimeroteknik

[issue31831] EmailMessage.add_attachment(filename="long or spécial") crashes or produces invalid output

2017-10-21 Thread calimeroteknik
calimeroteknik <calimerotek...@free.fr> added the comment: Eventually there is no bug, I was just confused at the output of print() on the EmailMessage. I noticed that in email/_header_value_parser.py policy.utf8 was True. The reason is found in email/message.py line 970 (class MI

[issue31831] EmailMessage.add_attachment(filename="long or spécial") crashes or produces invalid output

2017-10-21 Thread calimeroteknik
calimeroteknik <calimerotek...@free.fr> added the comment: I confirm that as for the crash, the patch in gh-3488 fixes it. The first code excerpt in my initial report now outputs the following, valid headers: Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Dispo

[issue31831] EmailMessage.add_attachment(filename="long or spécial") crashes or produces invalid output

2017-10-20 Thread calimeroteknik
calimeroteknik <calimerotek...@free.fr> added the comment: Erratum: the output generated by python 3.5 and 3.4 causes line wraps in the SMTP delivery chain, which cause exactly the same breakage as ulterior versions: the crucially needed indendation of one space ends up being

[issue31831] EmailMessage.add_attachment(filename="long or spécial") crashes or produces invalid output

2017-10-20 Thread calimeroteknik
New submission from calimeroteknik <calimerotek...@free.fr>: The following code excerpt demonstrates a crash: import email.message mail = email.message.EmailMessage() mail.add_attachment( b"test", maintype = "text", subtype = "plain", filename