Martin Gfeller added the comment:
Thanks again Steve.
I will copy the installation. I require a lot of pip packaged, so the
embeddable distro doesn't look right for my case.
I still think the /targetdir should issue some kind of warning if used with an
existing installation, but th
Martin Gfeller added the comment:
Thank you, Steve, for your rapid response and explanation!
I would like to have my installation fully isolated in case somebody (running
the machine) fiddles with the installation in the standard location. I used to
do that without problems with the 2.7 .msi
Martin Gfeller added the comment:
Windows Version is Windows 10, version 1803 (build 17134.1726).
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from Martin Gfeller :
I would like to install Python in a new location, completely separate and not
affecting an existing installation of the same version.
Despite I use /TargetDir=newdir, the installer goes into the "Modify Setup"
dialog. If I chose "Modif
Martin Gfeller added the comment:
Sorry for passing on my confusion, and thanks for your help!
There was indeed an old python.dll lying in one of the places Windows likes to
put DLLs. Deleting it resolved the problem.
Thanks again and sorry to use your valuable time.
Best regards, Martin
Martin Gfeller added the comment:
@Georg, the referenced Debian issue
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704084) already contains the
stack.
--
___
Python tracker
<http://bugs.python.org/issue13
Martin Gfeller added the comment:
I see (under Windows) the same symptoms as reported for Debian under
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704084.
Python refuses to start.
2.7.4.rc1 Windows 32-bit.
--
nosy: +Martin.Gfeller
Martin Gfeller Martin Gfeller added
the comment:
Martin, we're running with this for years and with many extensions modules,
without an issue. What is 64-bit safe should be 32-bit safe, not only 31-bit
safe. But you're right, this is not a proof, and we hav
Martin Gfeller Martin Gfeller added
the comment:
Lukas, I'm afraid to admit you're right :-;.
Assuming that the Python code called under the "not release the GIL"
regime would not do anything that could be potentially blocking is
probably danger
