Tobias Däullary added the comment:
Alright, thanks for pointing me in the right direction.
I have to conclude that this issue is not present on a current operating
system, as I now tried to reproduce with Windows 10 (I came across it on an
ancient Windows XP (sic) system - I can just imagine
Tobias Däullary added the comment:
Because sometimes when a process is implicitly started by some 3rd party
library (i.e. COM via pythonwin here) the "old", unchanged environment is
retained as the process itself doesn't care if os.environ was changed or not,
the original env
Change by Tobias Däullary :
--
keywords: +patch, patch, patch
pull_requests: +11558, 11559, 11560
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Tobias Däullary :
--
keywords: +patch, patch, patch, patch
pull_requests: +11558, 11559, 11560, 11561
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Tobias Däullary :
--
keywords: +patch, patch
pull_requests: +11558, 11559
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Tobias Däullary :
--
keywords: +patch
pull_requests: +11558
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35862>
___
___
Py
New submission from Tobias Däullary :
There should be a possibility to change the environment of a process created
with multiprocessing.
For subprocess this is possible thanks to the "env" attribute.
Elaboration:
While it is trivial to change os.environ manually, in some cases t
