New submission from Christian Ullrich :
Creating a venv using "py -m venv" fails when the debug binaries are installed
in the system-wide installation.
Note the below uses the 32-bit installation, but that is probably not
significant.
C:\Daten\pyv>py -3.7-32 -m venv v37-32
Er
Christian Ullrich added the comment:
Python version is 3.7.3.
--
___
Python tracker
<https://bugs.python.org/issue36441>
___
___
Python-bugs-list mailin
Christian Ullrich added the comment:
I have two ideas, but no idea if either is remotely feasible:
1. Replicate the launcher's selection logic in multiprocessing and
avoid the intermediate step via sys.executable. Perhaps put it
into pythonXX.dll or export it from the launcher
New submission from Christian Ullrich :
Using concurrent.futures.ProcessPoolExecutor on Windows fails immediately with
a lot of exceptions of the "access denied", "file not found", and "invalid
handle" varieties. Running the script that creates the ProcessPool
Change by Christian Ullrich :
--
keywords: +patch
pull_requests: +10084
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35374>
___
_
New submission from Christian Ullrich :
If hhc.exe is on the PATH when HTML Help is being built, the build fails
because make.bat does not correctly remember the fact. The set command is very
finicky with trailing spaces, leading to this:
'"hhc "' is not recognized as an internal o
Christian Ullrich added the comment:
Ma Lin, thanks for the suggestion!
Yes, it looks like this option fixes the problem. I can reproduce the crash at
will with a .chm built without this option, and not at all with one that has it
on.
If the .chm's directory is not writable, the .chw
New submission from Christian Ullrich :
Typing into the index keyword field frequently crashes the CHM viewer with the
first or second character. The Python CHMs are the only ones that I see this
crash with; it started around 3.6 or so.
>From event log:
Faulting application name: hh.
Christian Ullrich added the comment:
Not quite. Looking a bit further down get_progname()'s weird logic, we see that
it works like this:
1. prog = Py_GetProgramName()
2. progpath = GetModuleFileNameW()
3. if (prog is empty):
prog = "python"
4. if (slash in prog): # Or
Christian Ullrich added the comment:
That should have been
diff --git a/PC/getpathp.c b/PC/getpathp.c
index e7be704a9a..abb5e54c9f 100644
--- a/PC/getpathp.c
+++ b/PC/getpathp.c
@@ -443,8 +443,7 @@ get_progpath(void)
#else
dllpath[0] = 0;
#endif
-if (GetModuleFileNameW(NULL
New submission from Christian Ullrich:
I'm trying to do something that may be slightly tricky, and I think I just
found a vintage 1997 bug. Please correct me if I'm wrong.
This is PC/getpathp.c from current master:
430: static void
431: get_progpath(void)
432: {
433: extern wchar_t
Christian Ullrich added the comment:
I'll have to start with the ceterae again, won't I? OK, since you asked:
Ceterum censeo: This behavior could have been easily adapted to differing local
requirements if MSI had been used as the distribution package format by
appropriately transforming
Christian Ullrich added the comment:
Out of curiosity, can you point me to an example or two?
I have been living with, though not in, Win32 for quite a few years myself, and
I can say with certainty that I have never seen this notation before in my life.
Other than that, PR on the way soonish
New submission from Christian Ullrich:
In 3.6.1, the manual, section 3.1.3, has this to say:
"Your administrator will need to activate the “Enable Win32 long paths” group
policy, or set the registry value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem@LongPathsEnabled
New submission from Christian Ullrich:
The CHM help files on Windows always open maximized. I would prefer they opened
in a regular window instead, because the current behavior is annoying.
Fix: In Tools/msi/doc/doc.wxs line 34, change 'Show="maximized"' to
'Sh
Christian Ullrich added the comment:
Thank you.
As for the pointing out: It worked for Cato, didn't it? He may not have lived
to see it, but his perseverance in the face of rejection eventually brought
about the years-long bloody war he had dreamed about.
(Any historical inaccuracies
New submission from Christian Ullrich:
The Windows installation package registers a command line for uninstalling the
package. Running this command line does not uninstall the package.
The command line ends with "/modify". For uninstallation, it should be
"/passive /unins
Christian Ullrich added the comment:
This bug has been open for over a year and two subsequent releases, and its
planned resolution depends on a change to WiX. The related WiX bug (see comment
above) is scheduled to be implemented in WiX 4.0, which has no prospective
release date. According
Changes by Christian Ullrich <ch...@chrullrich.net>:
--
nosy: +Christian.Ullrich
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Christian Ullrich:
As described in PEP 397, the launcher can autoselect the "best" Python version
available on a system, or a full version number (major.minor) can be specified.
In the latter case, optionally a "-32" suffix can be given to select a 32
New submission from Christian Ullrich:
The new Windows installer always places the uninstallation registry key into
HKCU of the executing user. This is correct for a per-user installation, but
when run with InstallAllUsers=1, the key should go into HKLM instead.
The "Programs and Fea
New submission from Christian Ullrich:
When run with InstallAllUsers=1, the Windows installer displays
(%LOCALAPPDATA%)\Programs\Python\Python35 as the installation target directory,
but actually installs into the path for a system-wide installation,
"%PROGRAMFILES%\Python 3.5"
New submission from Christian Ullrich:
On Windows, a per-user installation uses
%LOCALAPPDATA%\Programs\Python\Python35 as the default target directory. A
system-wide (InstallAllUsers=1) installation, however, goes into
"%PROGRAMFILES%\Python 3.5" instead. The two directory na
New submission from Christian Ullrich:
A system-wide installation on Windows (using InstallAllUsers=1) still places
the uninstall executable into the profile (%LOCALAPPDATA%) of the installing
user. If that user profile is deleted, the (system-wide) installation cannot be
removed anymore
New submission from Christian Ullrich:
Uninstalling 3.5 on Windows removes the py.exe launcher. If it was installed in
the system-wide path (%SYSTEMROOT%), it may have replaced an existing copy from
an earlier version. In this case, removing the launcher will break this
remaining installation
New submission from Christian Ullrich:
The item "A new installer for Windows has replaced the old MSI" appears on the
"What's new" page as an "improvement". It is not. I disagree strongly with the
decision to abandon MSI packages for Windows distribution
Christian Ullrich added the comment:
Actually, this appears to be fixed in pip 1.5.6 (and 1.5.5, commit
79408cbc6fa5d61b74b046105aee61f12311adc9, AFAICT), which is included in 3.4.1;
I cannot reproduce the problem in 3.4.1. That makes this bug obsolete
Christian Ullrich added the comment:
According to procmon, ensurepip first installs the bundled packages in $TEMP,
then moves the resulting files to the Python installation directory. According
to http://support.microsoft.com/kb/310316, a file that is moved within the same
volume keeps its
Christian Ullrich added the comment:
Unprivileged users cannot install into the global site-packages, but they might
want to use the global pip to install with --user.
Also, this issue affects not only pip, but also the other bundled packages,
i.e. setuptools and pkg_resources
New submission from Christian Ullrich:
After installing python-3.4.0.amd64.msi on Windows 8.1 x64, the pip command
(and the versioned ones as well) only work for administrators. Regular users
get this:
Traceback (most recent call last):
File C:\Program Files\Python34\lib\runpy.py, line 171
30 matches
Mail list logo
