[issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application.
eryksun added the comment:
Steve, do you think it's OK to abandon localization for exception messages? If
so, should we be using English for all FormatMessage calls? It's a bit ugly
that Python's exceptions and the CRT error messages are in English, but then
whenever we call FormatMessage with LANG_NEUTRAL/SUBLANG_DEFAULT we're getting
localized error text. For example, the import error in the following case has a
mix or Russian and English:
import io, sys, ctypes
kernel32 = ctypes.WinDLL('kernel32')
MUI_LANGUAGE_NAME = 8
kernel32.SetThreadPreferredUILanguages(MUI_LANGUAGE_NAME, u'ru-RU\0', None)
kernel32.SetConsoleOutputCP(1251)
sys.stderr = io.TextIOWrapper(open(r'\\.\con', 'wb'), encoding='1251')
open('blah.pyd', 'w').close()
>>> import blah
Traceback (most recent call last):
File "", line 1, in
ImportError: DLL load failed: %1 не является приложением Win32.
--
___
Python tracker
<http://bugs.python.org/issue25585>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25585] Bad path leads to: ImportError: DLL load failed: %1 is not a valid Win32 application.
eryksun added the comment: The "DLL load failed" message is from Python, but the rest is the text for the Windows error code, ERROR_BAD_EXE_FORMAT (0x00c1) [1]. The "%1" in the string can be expanded as the first element of the Arguments array parameter of FormatMessage [2]. But currently the code in Python/dynload_win.c uses FORMAT_MESSAGE_IGNORE_INSERTS and does no post-processing to replace the "%1". I don't know why the Windows loader reported ERROR_BAD_EXE_FORMAT instead of ERROR_MOD_NOT_FOUND. Possibly it found another version of a dependent DLL that was corrupt or for a different architecture. Note that the setup in this case is odd in that the package is installed in C:\Python27 instead of in the site-packages directory. [1]: https://msdn.microsoft.com/en-us/library/ms681382#ERROR_BAD_EXE_FORMAT [2]: https://msdn.microsoft.com/en-us/library/ms679351 -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25565] subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes
Changes by eryksun : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Windows: subprocess.Popen: race condition for leaking inheritable handles ___ Python tracker <http://bugs.python.org/issue25565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017
eryksun added the comment: > As for the suggestion to install SP1 1... As for the manual > installation I am not sure which file to download from It's one of these three, depending on your system architecture: windows6.1-KB976932-X86.exe - This application installs Sp1 to a 32-bit machine running Windows 7. windows6.1-KB976932-X64.exe - This application installs Sp1 to a 64-bit machine running Windows 7 or Windows Server 2008 R2. windows6.1-KB976932-IA64.exe - This application installs Sp1 to an Itanium 64-bit Windows Server 2008 R2. Detailed instructions for installing Windows 7 SP1: http://windows.microsoft.com/installwindows7sp1. -- ___ Python tracker <http://bugs.python.org/issue25157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24765] Move .idlerc to %APPDATA%\IDLE on Windows
eryksun added the comment: On Windows, how about creating a junction (_winapi.CreateJunction in 3.5, or the shell's mklink /j) from ~\.idlerc to %APPDATA%\idle? If ~\.idlerc already exists, it could be moved to %APPDATA%\idle before creating the junction. New code would directly use %APPDATA%\idle, but old code would continue to use ~\.idlerc. Creating junctions requires no special privilege, but IDLE would need write access to the user's home directory. If write access is denied, at least newer IDLE versions that use %APPDATA% would work. On Linux, a symbolic link could be created from ~/.idlerc to [$XDG_CONFIG_HOME|~/.config]/idle. -- ___ Python tracker <http://bugs.python.org/issue24765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
Changes by eryksun : Added file: http://bugs.python.org/file40890/ctypes_from_buffer_2.patch ___ Python tracker <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
Changes by eryksun : Removed file: http://bugs.python.org/file40884/ctypes_from_buffer_1.patch ___ Python tracker <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
Changes by eryksun : -- keywords: +patch Added file: http://bugs.python.org/file40884/ctypes_from_buffer_1.patch ___ Python tracker <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
Changes by eryksun : Added file: http://bugs.python.org/file40883/ctypes_crash.py ___ Python tracker <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25492] subprocess with redirection fails after FreeConsole
eryksun added the comment: I forgot to first check whether p2cread is None: ERROR_INVALID_HANDLE = 0x0006 if stdin is None: p2cread = _winapi.GetStdHandle(_winapi.STD_INPUT_HANDLE) if p2cread is not None: try: os.get_handle_inheritable(p2cread) except OSError as e: if e.winerror != ERROR_INVALID_HANDLE: raise p2cread = None if p2cread is None: p2cread, _ = _winapi.CreatePipe(None, 0) p2cread = Handle(p2cread) _winapi.CloseHandle(_) -- ___ Python tracker <http://bugs.python.org/issue25492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25492] subprocess with redirection fails after FreeConsole
eryksun added the comment: For me, fails() lives up to its name in Windows 7, but it doesn't fail in Windows 10. It shouldn't fail in Windows 8, either. In Windows 8+ the console interface is implemented using a kernel device. Console handles reference virtual files on the ConDrv device, such as Connect, Input, and Output. The example doesn't fail because the I/O handles (Input and Output) are valid even if the main console handle (Connect) has been closed by calling FreeConsole. OTOH, prior to Windows 8, console I/O handles don't reference kernel objects. You may have noticed that the old API tags the values by setting the lower 2 bits (e.g. 3, 7, 11). This enables redirecting actions on console I/O handles to functions in the console host process (i.e. conhost.exe in Win 7, and csrss.exe in XP/Vista). For example, for a regular kernel object, the DuplicateHandle API is serviced by the system call NtDuplicateObject. But for a console handle, Windows instead sends the request to the console LPC port, to be dispatched to SrvDuplicateHandle in the console. Obviously this can't work after the client has called FreeConsole. Prior to Windows 8, this invalid-handle error can also be the result of running pythonw.exe from a console application such as python.exe or cmd.exe. See issue 3905. In this case Windows is copying the values of the parent's standard handles into the pythonw.exe process parameters, but they're meaningless values since pythonw.exe doesn't attach to a console automatically. (You could of course manually call AllocConsole or AttachConsole.) The new implementation in Windows 8 and 10 is smart enough to initialize the standard handles to 0 in this case. Thus in Windows 10 Terry's example in msg220218 doesn't raise and exception, and p.stdout.read() == b'32\r\n'. A workaround for Python 3.4+ on older Windows versions would be to check os.get_handle_inheritable, which calls WinAPI GetHandleInformation [1]: ERROR_INVALID_HANDLE = 0x0006 if stdin is None: p2cread = _winapi.GetStdHandle(_winapi.STD_INPUT_HANDLE) try: os.get_handle_inheritable(p2cread) except OSError as e: if e.winerror != ERROR_INVALID_HANDLE: raise p2cread = None if p2cread is None: p2cread, _ = _winapi.CreatePipe(None, 0) p2cread = Handle(p2cread) _winapi.CloseHandle(_) For 2.7, GetHandleInformation could be added to _subprocess. But then it may as well be added to Python 3's _winapi as well. [1]: https://msdn.microsoft.com/en-us/library/ms724329 -- versions: +Python 3.4, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25481] PermissionError in subprocess.check_output() when running as a different user (not login shell)
eryksun added the comment:
In subprocess.py there's the following code that builds a sequence of potential
paths for the executable [1]:
executable = os.fsencode(executable)
if os.path.dirname(executable):
executable_list = (executable,)
else:
# This matches the behavior of os._execvpe().
executable_list = tuple(
os.path.join(os.fsencode(dir), executable)
for dir in os.get_exec_path(env))
In this case it tries to execute "/home/user1/bin/asdf", which fails with
EACCES (to log this using strace, use -f to follow the fork). This occurs in
child_exec in _posixsubprocess.c, in the following loop [2]:
/* This loop matches the Lib/os.py _execvpe()'s PATH search when */
/* given the executable_list generated by Lib/subprocess.py. */
saved_errno = 0;
for (i = 0; exec_array[i] != NULL; ++i) {
const char *executable = exec_array[i];
if (envp) {
execve(executable, argv, envp);
} else {
execv(executable, argv);
}
if (errno != ENOENT && errno != ENOTDIR && saved_errno == 0) {
saved_errno = errno;
}
}
/* Report the first exec error, not the last. */
if (saved_errno)
errno = saved_errno;
saved_errno will be set to EACCES and stored back to errno after all attempts
to execute potential paths fail. This is then reported back to the parent
process, which raises a PermissionError.
[1]: https://hg.python.org/cpython/file/3.5/Lib/subprocess.py#l1463
[2]: https://hg.python.org/cpython/file/3.5/Modules/_posixsubprocess.c#l487
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue25481>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25356] Idle (Python 3.4 on Ubuntu) does not allow typing accents
eryksun added the comment: This seems to be a problem with Tk 8.6 when using an international keyboard layout on Linux. I ran the following test.tcl script via wish: text .t pack .t Initially dead keys work, but they stop working if I switch away from the text entry to another window and then back. Using the menu to save a file in IDLE has the same effect. I suggest opening a ticket at http://core.tcl.tk/tk. -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25476] close() behavior on non-blocking BufferedIO objects with sockets
eryksun added the comment:
I meant that you need a check in buffered_close such as the following:
if (res == NULL) {
if (PyErr_ExceptionMatches(PyExc_BlockingIOError))
goto end;
PyErr_Fetch(&exc, &val, &tb);
} else
Py_DECREF(res);
For 2.7 you could create a function similar to _PyIO_trap_eintr, but trap the
errors that Python 3 maps to BlockingIOError: EAGAIN/EWOULDBLOCK, EALREADY, and
EINPROGRESS.
--
___
Python tracker
<http://bugs.python.org/issue25476>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25476] close() behavior on non-blocking BufferedIO objects with sockets
eryksun added the comment: Per issue 16597, when an exception occurs in flush(), the file is closed anyway. You'd have to check the exception and only skip to the end for EWOULDBLOCK or EAGAIN. That way you're not introducing a regression for ENOSPC and other exceptions for which retrying will just repeatedly fail. I'm adding 2.7 to keep the io module consistent; however, socket.makefile in 2.7 doesn't use the io module. -- nosy: +eryksun versions: +Python 2.7, Python 3.4, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25450] Python 3.5 starts in C:\Windows\system32 as current directory
eryksun added the comment:
Steve, I think you're right that it's simpler and more reliable to add a
command-line option that sets IDLE's working directory to the current user's
home directory.
Terry, the default behavior in Linux, at least in Ubuntu, is to start IDLE with
the working directory set to the user's home directory.
The Linux equivalent of a Windows .lnk shortcut is an XDG .desktop file [1]. A
desktop application entry sets the working directory using the "Path" key, such
as Path=/absolute/path (or also, and maybe only in Ubuntu Unity,
Path=relative/path) in the main "Desktop Entry" or in a "Desktop Action" (i.e.
right-click menu action). Environment variables are not supported.
If "Path" isn't defined, I can only say from experience what Ubuntu's Unity
shell does, since the spec doesn't define a default behavior. In this case, the
child process inherits Unity's working directory. Since it's a plugin for the
Compiz window manager, the child inherits the working directory of Compiz. This
is the current user's $HOME directory, which Compiz inherits indirectly from
the user-mode init process. I confirmed the behavior by attaching gdb to compiz
and executing `call chdir("/home")`, and then continued compiz and opened IDLE
to verify that the working directory was inherited as "/home".
[1]: http://standards.freedesktop.org/desktop-entry-spec/latest
--
___
Python tracker
<http://bugs.python.org/issue25450>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25450] Python 3.5 starts in C:\Windows\system32 as current directory
eryksun added the comment: > 'Start in:' is blank and for what ever reason, the default is ...system32. When the "Start in" field of a .lnk shortcut is blank, the child process inherits the working directory of the parent process (i.e. the process that runs the shortcut), unless the parent passes some other directory to ShellExecute. If you copy the shortcut to the desktop, for example, Explorer sets the working directory to the desktop. If it's run from the command prompt, cmd uses its own working directory. When run from the Start menu, the child inherits Explorer's working directory, %SystemRoot%\System32. The old installer (pre-3.5) sets "Start in" to the installation directory. IMO, a better choice would be "%USERPROFILE%". The Windows shell expands the environment variable to the current user's profile directory when it runs the shortcut. I'm not keen on using a profile subdirectory such as "Documents" or "Desktop", since a user can relocate most of the special folders in his or her profile. Unfortunately the "Start in" field won't accept shell: locations such as "shell:Personal" or "shell:Desktop". It would be nice if it did, since those take into account relocated folders. -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25448] Exception ABC doesn't work in Python 3 (but does in Python 2.7)
Changes by eryksun : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Catching virtual subclasses in except clauses ___ Python tracker <http://bugs.python.org/issue25448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25448] Exception ABC doesn't work in Python 3 (but does in Python 2.7)
eryksun added the comment: In Python 2, PyErr_GivenExceptionMatches [1] calls PyObject_IsSubclass. To handle calling __subclasscheck__ in this case, 2.7 (but not 2.6) temporarily increases the recursion limit by 5. For example: class CMeta(type): def __subclasscheck__(self, other): import sys print 'recursion limit: %d' % sys.getrecursionlimit() frame = sys._getframe(1) n = 0 while frame: n += 1 frame = frame.f_back print 'frame: %d' % n return True class C(Exception): __metaclass__ = CMeta def f(): try: f() except C: pass >>> sys.getrecursionlimit() 1000 >>> f() recursion limit: 1005 frame: 1000 >>> sys.getrecursionlimit() 1000 If the recursion limit weren't temporarily increased, then trying to call __subclasscheck__ in the above case would raise another RuntimeError. In Python 3, PyErr_GivenExceptionMatches [2] instead calls PyType_IsSubtype. See issue 2534. In that issue Antoine's reason for the change is that "otherwise there are some nasty issues with recursion checking". [1]: https://hg.python.org/cpython/file/v2.7.10/Python/errors.c#l84 [2]: https://hg.python.org/cpython/file/v3.5.0/Python/errors.c#l166 -- components: +Interpreter Core nosy: +eryksun versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue25448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25432] isinstance documentation doesn't explain what happens when type is tuple
eryksun added the comment:
Since Python has multiple inheritance, it could be misconstrued as a
conjunctive test. For example, if c is an instance of C, which subclasses both
A and B, then someone might think isinstance(c, (A, B)) requires c to be an
instance of both A and B. The description could clarify that it's a disjunctive
test with short circuiting.
class MetaA(type):
def __instancecheck__(self, other):
print('MetaA.__instancecheck__')
return False
class A(metaclass=MetaA): pass
>>> isinstance(1, (A, int))
MetaA.__instancecheck__
True
>>> isinstance(1, (int, A))
True
------
keywords: +easy
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue25432>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25405] User install of 3.5 removes py.exe from C:\Windows
eryksun added the comment: Setting a new default for py.exe doesn't require admin privileges. You can use the PY_PYTHON environment variable: C:\>py --version Python 2.7.10 C:\>set PY_PYTHON=3 C:\>py --version Python 3.5.0 which you can easily persist in the registry using setx.exe: C:\>setx PY_PYTHON 3 SUCCESS: Specified value was saved. Check that it was saved: C:\>reg query HKCU\Environment /v PY_PYTHON HKEY_CURRENT_USER\Environment PY_PYTHONREG_SZ3 You can also use %LOCALAPPDATA%\py.ini to set the default: C:\>py --version Python 2.7.10 C:\>copy con "%localappdata%\py.ini" [defaults] python=3 ^Z 1 file(s) copied. C:\>py --version Python 3.5.0 Note that the environment variable is preferred: C:\Temp>set PY_PYTHON=2 C:\Temp>py --version Python 2.7.10 and an active virtual environment is most preferred: C:\Temp>py -3.5 -m venv testenv C:\Temp>testenv\Scripts\activate.bat (testenv) C:\Temp>py --version Python 3.5.0 (testenv) C:\Temp>py -c "import sys; print(sys.prefix)" C:\Temp\testenv -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25386] msvcrt_putch/msvcrt_putwch don't check the return value of _putch/_putwch
eryksun added the comment:
> It would be interesting to know under what circumstances these
> functions can fail.
The CRT _put[w]ch and _get[w]ch[e] functions will fail when called in a process
that doesn't have a console. (Except get[w]ch may succeed if it follows
unget[w]ch.) This is the case when running under pythonw.exe if the process
hasn't first attached to a console via AllocConsole() or AttachConsole(). It
also applies to python.exe when run as a detached process (i.e. the creation
flag DETACHED_PROCESS) or after having detached the console via FreeConsole().
Note that even though the docs for get[w]ch [1] and get[w]che [2] state that
"[t]here is no error return", these functions actually do return an error value
of [W]EOF. This has been the case since at least back to Windows NT. Maybe
Steve Dower can shed light on why this is undocumented.
Here's an example, tested on 64-bit Windows 10 in Python 3.5. This example
calls the console I/O functions using both msvcrt and ctypes. Since there's no
attached console, an error is expected, except when calling ungetwch followed
by getwch.
import os
import sys
import subprocess
cmds_msvcrt = [
"import msvcrt; msvcrt.ungetwch('a'); msvcrt.getwch()",
"import msvcrt; msvcrt.ungetwch('a'); msvcrt.ungetwch('a')",
"import msvcrt; msvcrt.getwch()",
"import msvcrt; msvcrt.putwch('a')",
]
csetup = "import sys,ctypes; ucrt = ctypes.cdll.ucrtbase; "
cmds_ctypes = [
csetup + "ucrt._ungetwch(ord('a')); sys.exit(ucrt._getwch())",
csetup + "ucrt._ungetwch(ord('a')); sys.exit(ucrt._ungetwch(ord('a')))",
csetup + "sys.exit(ucrt._getwch())",
csetup + "sys.exit(ucrt._putwch(ord('a')))",
]
def test(cmds):
pythonw = os.path.join(sys.prefix, 'pythonw.exe')
return [subprocess.call([pythonw, '-c', cmd]) for cmd in cmds]
>>> test(cmds_msvcrt)
[0, 1, 0, 0]
>>> test(cmds_ctypes)
[97, 65535, 65535, 65535]
65535 is WEOF.
[1]: https://msdn.microsoft.com/en-us/library/078sfkak
[2]: https://msdn.microsoft.com/en-us/library/kswce429
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue25386>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If so should we mention this?
eryksun added the comment: Sorry, I forgot to include the link to readme.txt: [2]: https://hg.python.org/cpython/file/v3.5.0/PCbuild/readme.txt -- ___ Python tracker <http://bugs.python.org/issue25361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If so should we mention this?
eryksun added the comment: Building Python 3.5 requires Visual Studio 2015 and Windows 8.1, so this would be a vanishingly small audience that's building to deploy on old 32-bit Windows 7 machines. I don't think the PSF needs to worry about this. Anyway, the "/arch (x86)" docs [1] explain how to configure a project to use IA32, and PCBuild/readme.txt [2] explains how to build Python using Visual Studio 2015. I know this doesn't really help a novice user; just tell them to install Python 3.4! [1]: https://msdn.microsoft.com/en-us/library/7t5yh4fd -- ___ Python tracker <http://bugs.python.org/issue25361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If so should we mention this?
eryksun added the comment: > Windows requires SSE these days, since Vista IIRC, so the problem > is probably someone on XP. Windows 8 is the first to require SSE2 [1][2]. I'm sure it's no coincidence that this became the default in VS 2012. There is probably a small minority of users that upgraded to 32-bit Windows 7 on old hardware. Python 3.5 excludes them, but I don't think the build should switch to using /arch:IA32 just to support them. If a user on such a system really needs 3.5, it's possible to create a private build without SSE2. Most packages that have extension modules will also have to be built from source instead of using prebuilt wheels. [1]: http://windows.microsoft.com/en-us/windows7/products/system-requirements [2]: http://windows.microsoft.com/en-US/windows-8/system-requirements -- ___ Python tracker <http://bugs.python.org/issue25361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If so should we mention this?
eryksun added the comment: With Visual Studio 2010 and earlier, SSE support had to be explicitly enabled. Starting with VS2012 it's on by default [1]: Because the x86 compiler generates code that uses SSE2 instructions by default, you must specify /arch:IA32 to disable generation of SSE and SSE2 instructions for x86 processors. For 3.5, the 32-bit build does use SSE2 instructions. For example, float_add uses the addsd instruction (opcode F2 0F 58): 0:000> s python35!float_add l100 f2 0f 58 71f6c5d8 f2 0f 58 44 24 08 8b 0d-84 11 18 72 f2 0f 11 44 ..XD$..r...D 0:000> u 71f6c5d8 l3 python35!float_add+0x98: 71f6c5d8 f20f58442408addsd xmm0,mmword ptr [esp+8] 71f6c5de 8b0d84111872mov ecx,dword ptr [python35!free_list (72181184)] 71f6c5e4 f20f11442410movsd mmword ptr [esp+10h],xmm0 Thus 3.5 doesn't support older CPUs that lack SSE2, such as the AMD Athlon XP. I didn't check the installer itself, but that would be a pointless exercise. [1]: https://msdn.microsoft.com/en-us/library/7t5yh4fd -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25360] pyw should search for pythonw to implement #!/usr/bin/env python
Changes by eryksun : -- nosy: +vinay.sajip ___ Python tracker <http://bugs.python.org/issue25360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25360] pyw should search for pythonw to implement #!/usr/bin/env python
New submission from eryksun: The Windows launcher searches PATH to implement the shebang "#!/usr/bin/env". Given "#!/usr/bin/env python", it always searches for L"python" (see issue 17903), even in pyw.exe. maybe_handle_shebang in PC/launcher.c should instead use a macro that's conditionally defined as L"pythonw" when building pyw.exe and L"python" when building py.exe. This parallels the existing PYTHON_EXECUTABLE macro. -- components: Windows messages: 252681 nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: pyw should search for pythonw to implement #!/usr/bin/env python type: behavior versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25358] Unexpected behaviour when converting large float to int
eryksun added the comment:
int(float_version) is returning the actual integer value represented by the
float, which is the closest approximation possible using an [IEEE 754
binary64][1], i.e. a C double. Here's one way to compute this value manually:
from struct import pack
from fractions import Fraction
some_number = 1 * 10**44
float_version = float(some_number)
n = int.from_bytes(pack('>d', float_version), 'big')
sign = n >> 63
exp = ((n >> 52) & (2**11 - 1)) - 1023
nmantissa = n & (2**52 - 1)
significand = 1 + sum(Fraction((nmantissa >> (52 - i)) & 1, 2**i)
for i in range(52))
>>> (-1)**sign * significand * 2**exp
Fraction(18821361405306422640701865984, 1)
Or just use the as_integer_ratio method:
>>> float_version.as_integer_ratio()
(18821361405306422640701865984, 1)
[1]: https://en.wikipedia.org/wiki/Double-precision_floating-point_format
--
nosy: +eryksun
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25358>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25345] Unable to install Python 3.5 on Windows 10
eryksun added the comment: Please attach "Python 3.5.0 (32-bit)_*_core_JustForMe.log", if it exists. According to the log, initially the installer can't create a restore point because, I assume, you have the volume shadow copy (VSS) service disabled, i.e. the error code is ERROR_SERVICE_DISABLED (0x80070422). That shouldn't derail the installation, but it's unusual to disable this service since restore points are critically important in case something goes wrong while modifying the system. Next, installing core.msi fails with the error code ERROR_INSTALL_ALREADY_RUNNING (0x80070652). This means you had an existing installation in progress. Check for running instances of msiexec.exe. If the existing installation process is hung, try installing Python 3.5 again after rebooting. -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017
eryksun added the comment: > it does not generates any .evtx file Start a command prompt; change to the directory that has the MSU, and run it with the option "/log:kb2999226.evtx". For me this creates kb2999226.evtx in the current directory, which can be converted to XML using wevtutil. If this doesn't create a log file, then possibly the .msu file association is incorrect. In that case, try running wusa.exe directly, e.g. "%SystemRoot%\System32\wusa.exe" Windows8.1-KB2999226-x64.msu /log:kb2999226.evtx -- ___ Python tracker <http://bugs.python.org/issue25157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25327] Python 3.5 Windows 10 Installation Fails With Corrupt Directory Error
Changes by eryksun : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <http://bugs.python.org/issue25327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25327] Python 3.5 Windows 10 Installation Fails With Corrupt Directory Error
Changes by eryksun : Removed file: http://bugs.python.org/file40706/Python 3.5.0 (64-bit)_20151006150920.log ___ Python tracker <http://bugs.python.org/issue25327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25325] UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE encodings don't add/remove BOM on encode/decode
eryksun added the comment: Yes, if you explicitly use big-ending or little-endian UTF, then you need to manually include a BOM if that's required. That said, if a file format or data field is specified with a particular byte order, then using a BOM is strictly incorrect. See the UTF BOM FAQ: http://www.unicode.org/faq/utf_bom.html#BOM For regular text documents, in which the byte order doesn't really matter, use the native byte order of your platform via UTF-16 or UTF-32. Also, instead of manually encoding strings, use the "encoding" parameter of the built-in open function, or io.open or codecs.open in Python 2. This only writes a single BOM, even when writing to a file multiple times. -- nosy: +eryksun resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue25325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017
eryksun added the comment: Error code WU_E_NOT_APPLICABLE (0x80240017) just tells us that "there are no applicable updates". Perhaps the Windows Update log has more information. Shirshendu, try directly installing the [Universal CRT update][1] from the command prompt. Run it with the /log option, e.g. Windows8.1-KB2999226-x64.msu /log:kb2999226.evtx You can view this log in the Windows event viewer, or convert it to text XML on the command line as follows: wevtutil qe kb2999226.evtx /lf:true /f:XML /e:MSULog > kb2999226.xml If the update fails, please attach the XML log to this issue. [1]: http://www.microsoft.com/en-us/download/details.aspx?id=48234 -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25323] Bus error: 10 when executing recursive program
eryksun added the comment: I don't know about OS X, but in 64-bit Linux I can increase the recursion limit to 10 if I allow the main thread to grow to 64 MiB by setting the RLIMIT_STACK soft limit. For example: soft, hard = resource.getrlimit(resource.RLIMIT_STACK) soft = max(soft, 64 << 20) if hard != resource.RLIM_INFINITY: soft = min(soft, hard) resource.setrlimit(resource.RLIMIT_STACK, (soft, hard)) Alternatively it also works to use a worker thread with a fixed 64 MiB stack size, set as follows: old_size = threading.stack_size(64 << 20) # create worker thread threading.stack_size(old_size) ------ nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4926] putenv() accepts names containing '=', return value of unsetenv() not checked
eryksun added the comment:
AFAICT, on Windows using the posix_putenv_garbage dict is unnecessary. The
Windows C runtime creates a private copy of the string, so there's no need to
keep a reference. Moreover, since there's no unsetenv, deleting a variable is
accomplished by calling putenv with an empty value, e.g. putenv('foo', '').
This leaks an item in posix_putenv_garbage, which is left set as ('foo',
'foo=').
--
nosy: +eryksun
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue4926>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
eryksun added the comment:
My suggestion is only for 3.5 / 3.6, because Windows XP is no longer supported.
Starting with Windows Vista, both cmd.exe and CreateProcess support this
behavior. I realize that disabling searching the current director by default is
going beyond what cmd.exe does, which is to require opting in via the
environment variable. But Python can choose to follow the more-modern behavior
of PowerShell as a precedent here.
As Steve mentioned, technically a program isn't supposed to check for the
environment variable, but instead call NeedCurrentDirectoryForExePath. This
would require either adding a built-in function, e.g. to the _winapi module, or
require ctypes:
>>> kernel32.NeedCurrentDirectoryForExePathW('command')
1
>>> os.environ['NoDefaultCurrentDirectoryInExePath'] = '1'
>>> kernel32.NeedCurrentDirectoryForExePathW('command')
0
Note that it requires first normalizing the path to replace slashes with
backslashes, which is unusual for the Windows API.
>>> kernel32.NeedCurrentDirectoryForExePathW(r'.\command')
1
>>> kernel32.NeedCurrentDirectoryForExePathW('./command')
0
--
___
Python tracker
<http://bugs.python.org/issue24505>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
eryksun added the comment: Please don't default to searching the current directory: if is_windows: # The current directory takes precedence on Windows. if not os.curdir in path: path.insert(0, os.curdir) Add a keyword option to enable this, with a warning that including the current directory isn't secure. This option should not be able to override the environment variable [NoDefaultCurrentDirectoryInExePath][1]. [1]: https://msdn.microsoft.com/en-us/library/ms684269 -- components: +Windows nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.6 -Python 3.5 ___ Python tracker <http://bugs.python.org/issue24505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22080] Add windows_helper module helper
Changes by eryksun : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue22080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25273] Console interpreter holds a hard link on last displayed object
eryksun added the comment:
In interactive mode the extra reference is held by the "_" built-in variable.
>>> a
'test string A'
>>> del __builtin__._; sys.getrefcount(a) - 1
1
Look at the following disassembled code, compiled in the 'single' interactive
mode:
>>> dis.dis(compile('a', '', 'single'))
1 0 LOAD_NAME0 (a)
3 PRINT_EXPR
4 LOAD_CONST 0 (None)
7 RETURN_VALUE
[PRINT_EXPR][1] calls [sys.displayhook][2]. The default display hook prints a
non-None value and sets it as __builtin__._. You can replace this with your own
display hook. The original function is always available as sys.__displayhook__.
[1]: https://hg.python.org/cpython/file/v2.7.10/Python/ceval.c#l1727
[2]: https://docs.python.org/2/library/sys.html#sys.displayhook
--
nosy: +eryksun
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25273>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25125] "Edit with IDLE" does not work for shortcuts
eryksun added the comment: > Does notepad handle clicking "edit" on a shortcut to a batch file? > Maybe subcommands don't have exactly the same semantics as regular > verbs... In Windows 7 SP1 a regular verb works fine from a shortcut, but apparently not a subcommand. OTOH, Windows 10 seems to have no problem with this. I just tested the following subcommand for editing .bat files with notepad: reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad\command reg add HKCU\Software\Classes\batfile\shell\editother /v MUIVerb /d "Edit Other" reg add HKCU\Software\Classes\batfile\shell\editother /v Subcommands reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad /v MUIVerb /d "Edit With Notepad" reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad\command /ve /d "C:\Windows\notepad.exe %1" When accessed from the file itself, this works fine in both Windows 7 SP1 and Windows 10 RTM. When accessed from a shortcut, the command works in Windows 10 but does nothing in Windows 7. This independently confirms the issue reported by Thijs as a Windows 7 bug/limitation. -- ___ Python tracker <http://bugs.python.org/issue25125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25125] "Edit with IDLE" does not work for shortcuts
eryksun added the comment: > I don't believe %1 is necessarily correct here either, but maybe > with %* it's redundant anyway %0, %1, or %L is lpFile. On older systems "%L" guarantees using the long filename, but this is pointless nowadays. %* (i.e. %2 through %9) is lpParameters, which is unusual to have in an edit command. Here's the edit command for .bat files: C:\>reg query hklm\software\classes\batfile\shell\edit\command HKEY_LOCAL_MACHINE\software\classes\batfile\shell\edit\command (Default)REG_EXPAND_SZ%SystemRoot%\System32\NOTEPAD.EXE %1 It seems using quotes around "%1" is optional. -- ___ Python tracker <http://bugs.python.org/issue25125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23606] ctypes.util.find_library("c") no longer makes sense
eryksun added the comment: > some code that uses it will need updating (due to API changes > since VC9/VC10) For example, I discovered that the stdio exports don't include printf, etc. Using __stdio_common_vfprintf to implement printf relies on calling __acrt_iob_func to get stdout and (in general) dynamically building a va_list argument list. Of course, relying on either operation is a bad idea. -- ___ Python tracker <http://bugs.python.org/issue23606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25241] ctypes: access violation reading
eryksun added the comment: Here's a rewrite with a cleaner while loop, at least to me: def list_volumes(): vname = ctypes.create_unicode_buffer(wintypes.MAX_PATH) vhandle = kernel32.FindFirstVolumeW(vname, len(vname)) if vhandle == INVALID_HANDLE_VALUE: raise ctypes.WinError(ctypes.get_last_error()) volumes = [vname.value] try: while kernel32.FindNextVolumeW(vhandle, vname, len(vname)): volumes.append(vname.value) last_error = ctypes.get_last_error() if last_error != ERROR_NO_MORE_FILES: raise ctypes.WinError(last_error) finally: if not kernel32.FindVolumeClose(vhandle): raise ctypes.WinError(ctypes.get_last_error()) return volumes -- ___ Python tracker <http://bugs.python.org/issue25241> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25125] "Edit with IDLE" does not work for shortcuts
eryksun added the comment: > Ah, I misread that part. Will have to look deeper, but I'm not > actually sure that shortcuts are supposed to support the same > operations (though if it shows up, I guess it should work). A LNK shortcut should support the same commands (e.g. open, edit) as its target. This works for me in Windows 10. BTW, I don't see how to ShellExecute a subcommand documented on MSDN. One way is to just pass the subkey path as the 'verb', e.g. r"editwithidle\shell\edit35". Probably it's just passed along to RegOpenKeyEx as the subkey, so this shouldn't be used in practice. Could the installer create a simple "edit" command? It doesn't have to be smart about it. Just overwrite the current value, and let a per-user install take precedence. -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25241] ctypes: access violation reading
eryksun added the comment:
The default function pointer restype is c_int, and the default integer argument
conversion is also c_int. However, the handle returned by FindFirstVolume is a
pointer to a private structure that it uses for the volume enumeration, so you
must set restype to a pointer type. Similarly, if restype is a simple type that
gets converted to a Python integer (e.g. wintypes.HANDLE), then you must either
set FindNextVolumeW.argtypes or manually wrap the handle value (e.g. vhandle =
wintypes.HANDLE(vhandle)). The default c_int conversions will only work if the
address happens to fit in a 32-bit int.
Don't forget to call FindVolumeClose if the process is expected to continue.
Otherwise you're leaking memory.
Also, if you're defining function pointer prototypes for a library, please do
not use ctypes.cdll or ctypes.windll. The loaders are global to ctypes and by
design cache the loaded library, which by design caches function pointers.
Projects such as pyreadline and colorama have demonstrated the problems that
this creates due to inconsistent prototype definitions, especially for commonly
used Win32 APIs.
Here is one way to rewrite your code to have it work more reliably:
import ctypes
from ctypes import wintypes
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
kernel32.FindFirstVolumeW.restype = wintypes.HANDLE
kernel32.FindNextVolumeW.argtypes = (wintypes.HANDLE,
wintypes.LPWSTR,
wintypes.DWORD)
kernel32.FindVolumeClose.argtypes = (wintypes.HANDLE,)
INVALID_HANDLE_VALUE = wintypes.HANDLE(-1).value
ERROR_NO_MORE_FILES = 18
def list_volumes():
vname = ctypes.create_unicode_buffer(wintypes.MAX_PATH)
vhandle = kernel32.FindFirstVolumeW(vname, len(vname))
if vhandle == INVALID_HANDLE_VALUE:
raise ctypes.WinError(ctypes.get_last_error())
volumes = []
try:
while True:
volumes.append(vname.value)
if not kernel32.FindNextVolumeW(vhandle, vname, len(vname)):
last_error = ctypes.get_last_error()
if last_error == ERROR_NO_MORE_FILES:
break
else:
raise ctypes.WinError(last_error)
finally:
if not kernel32.FindVolumeClose(vhandle):
raise ctypes.WinError(ctypes.get_last_error())
return volumes
if __name__ == '__main__':
for volume in list_volumes():
print(volume)
--
nosy: +eryksun
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25241>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll
eryksun added the comment: > Dependency Walker doesn't know how to resolve those DLLs on > any platform - Win10 looks exactly the same. On older systems the api-ms-win-crt-* DLLs should be physically installed in System32, so Dependency Walker should find them if they exist. For example, on a Windows 7 box: >dir /b C:\Windows\System32\api-ms-win-crt*.dll api-ms-win-crt-conio-l1-1-0.dll api-ms-win-crt-convert-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-filesystem-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-locale-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-multibyte-l1-1-0.dll api-ms-win-crt-private-l1-1-0.dll api-ms-win-crt-process-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll api-ms-win-crt-utility-l1-1-0.dll In Windows 10 these DLLs are an API Set contract; they don't actually exist in the filesystem. For example, on Windows 10 GetModuleHandle for all of these DLLs returns a handle to ucrtbase.dll, whereas on Windows 7 each is a uniquely loaded module. -- ___ Python tracker <http://bugs.python.org/issue25223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll
eryksun added the comment: > this update doesn't apply to you system Was that Windows6.0-KB2999226-x86.msu? Open a command prompt and enter the following: wmic os get Version, OSArchitecture Windows Vista SP 2 is version 6.0.6002, and the OS architecture should be 32-bit. -- ___ Python tracker <http://bugs.python.org/issue25223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4918] Windows installer created with Python X.Y does not work with Python X.Y+1
eryksun added the comment: There haven't been any fundamental changes to bdist_wininst in years, and bdist_wheel has mostly replaced it nowadays. I'm fairly certain this issue was fixed by Mark Hammond's fix for issue 4566. Just to be certain, I updated the code to use print as a function and used 3.4 to build "Simple-Python 3.4.3.win-amd64.exe". I installed this to 3.5, and the post-install script ran successfully. So I'm re-tagging this issue for versions 2.7 and 3.2 and closing it as a duplicate. In summary, Python built with VS 2008 needs an activation context for the CRT assembly, which is required to load msvcr90.dll. Normally this comes from the application executable, such as python.exe. But when Python is embedded, it may be the case that the application lacks the required activation context (e.g. a bdist_wininst installer created by Python 2.5). Mark Hammond's fix works around this problem by saving and reusing the activation context from when the Python DLL was loaded. This activation context is based on the DLL's resource #2 manifest, which includes the CRT assembly. One remaining problem for embedding Python 2.7 is accessing msvcr90.dll via ctypes. But it's ctypes! Just dynamically create an activation context. -- nosy: +eryksun resolution: -> duplicate status: open -> closed superseder: -> 2.6.1 breaks many applications that embed Python on Windows versions: +Python 2.7, Python 3.2 -Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue4918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe
eryksun added the comment: Creating a symbolic link can't be relied on for a per-user installation. Administrators have to elevate to create symbolic links, and most regular users also lack this privilege. -- ___ Python tracker <http://bugs.python.org/issue21506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll
eryksun added the comment: Try directly installing the Universal CRT update, [Windows6.0-KB2999226-x86.msu][1]. Run it with the /log option, e.g. Windows6.0-KB2999226-x86.msu /log:kb2999226.evtx You can view this log in the Windows event viewer, or convert it to text XML on the command line as follows: wevtutil qe kb2999226.evtx /lf:true /f:XML /e:MSULog > kb2999226.xml If the update fails, please attach the XML log to this issue. Steve, since these updates require an up-to-date Windows installation, maybe you should test for SP2 on Vista, SP1 on Windows 7, and S14 on Windows 8.1. Display a warning if the OS is outdated, including Windows XP, but let the install proceed. [1]: http://www.microsoft.com/en-us/download/details.aspx?id=48234 -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25164] Windows default installation path is inconsistent between per-user and system-wide installation
eryksun added the comment: Also, why does the per-user install path have a seemingly pointless "Python" base directory? I expected it to install directly into FOLDERID_UserProgramFiles, to be consistent with installing to FOLDERID_ProgramFiles. Also, I doubt anyone cares, but the roaming "user scheme" is still using the name "Python35" without appending a -32 suffix. So 32-bit and 64-bit --user installs are still competing for the same site-packages directory. I know, hardly anyone seems to use this. I doubt Jane User wants large packages such as PyQt4 and SciPy in her roaming profile. -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25205] setattr accepts invalid identifiers
eryksun added the comment: Even MvL appears to slip up when he states "some may accept non-strings as attribute names". That would be pointless in a __setattr__ method since setattr / PyObject_SetAttr reject non-string values as 'names'. -- ___ Python tracker <http://bugs.python.org/issue25205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25166] Windows AllUsers installation places uninstaller in user profile
eryksun added the comment: Where is the API documented to change the install scope dynamically? I see where it's apparently defined in the burn manifest (extracted from the executable) as PerMachine="no": http://schemas.microsoft.com/wix/2008/Burn";> <> http://www.python.org/"; DisableModify="button"/> -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25117] Windows installer: precompiling stdlib fails with missing DLL errors
eryksun added the comment: > The problem here is probably that installing the CRT update > required a restart I saw that, but it didn't make any sense to me that the DLL isn't available immediately after wusa.exe exits. Is it in limbo until the system is restarted? I know in Windows 10 these api-ms-win-crt* DLLs are actually virtual API sets managed by the loader (i.e. they all have the same module handle, that of ucrtbase.dll). How does this relate to what's going on with Windows 8/Server 2012, if at all? Marius reports that "Python seems to work", but doesn't mention whether or not a reboot was necessary. -- ___ Python tracker <http://bugs.python.org/issue25117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25205] setattr accepts invalid identifiers
eryksun added the comment: This is a documentation issue and not specific to a particular version of Python. What's the rule on version tagging in this case? -- components: +Documentation ___ Python tracker <http://bugs.python.org/issue25205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25213] Regression: Python 3.5.0 shutil.copy2 doesn't raise PermissionError on Windows 7
eryksun added the comment:
This issue doesn't pertain to the 64-bit version.
C:\Temp>py -3.5
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37)
[MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copy2('test.txt', 'C:\\')
Traceback (most recent call last):
File "", line 1, in
File "C:\Program Files\Python 3.5\lib\shutil.py", line 251, in copy2
copyfile(src, dst, follow_symlinks=follow_symlinks)
File "C:\Program Files\Python 3.5\lib\shutil.py", line 115, in copyfile
with open(dst, 'wb') as fdst:
PermissionError: [Errno 13] Permission denied: 'C:\\test.txt'
In the 32-bit version, creating a file in the system root directory gets
virtualized when the user doesn't have write access. It's not specific to
shutil.copy2.
C:\Temp>py -3.5-32
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59)
[MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> open('C:\\test.txt', 'w').close()
>>> import pathlib
>>> pathlib.Path('C:\\test.txt').resolve()
WindowsPath('C:/Users/usradm/AppData/Local/VirtualStore/test.txt')
You can verify in the task manager's details tab that UAC Virtualization is
enabled for 32-bit python.exe and disabled for 64-bit python.exe. The problem
is that the manifest is missing the requestedExecutionLevel, which should be
present and set to "asInvoker". This is discussed in the MSDN article [New UAC
Technologies for Windows Vista][1].
>>> os.system('sigcheck -q -m "%s"' % sys.executable)
c:\users\usradm\appdata\local\programs\python\python35-32\python.exe:
Verified: Signed
Signing date: 2:17 AM 9/13/2015
Publisher: Python Software Foundation
Description:Python
Product:Python
Prod version: 3.5.0
File version: 3.5.0
MachineType:32-bit
Manifest:
3.4's manifest sets the requestedExecutionLevel:
C:\Temp>py -3.4-32
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06)
[MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> os.system('sigcheck -q -m "%s"' % sys.executable)
c:\users\usradm\appdata\local\programs\python\python34-32\python.exe:
Verified: Unsigned
Link date: 9:43 PM 2/24/2015
Publisher: n/a
Description:n/a
Product:n/a
Prod version: n/a
File version: n/a
MachineType:32-bit
Manifest:
[1]: https://msdn.microsoft.com/en-us/library/bb756960
--
components: +Windows -Library (Lib)
keywords: +3.5regression
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issue25213>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
eryksun added the comment:
> import locale
> locale.setlocale(locale.LC_ALL, '')
>
> import importlib
> import time
> importlib.reload(time)
>
> it does not work when imported after importing time.
> What is the reason? Does reload() work only for
> modules coded as Python sources?
The import system won't reinitialize a builtin or dynamic extension module.
Reloading just returns a reference to the existing module. It won't even reload
a PEP 489 multi-phase extension module. (But you can create and exec a new
instance of a multi-phase extension module.)
> Is there any other approach that would implement the
> workaroundXXX.py module?
If the user's default locale and the current thread's preferred language are
compatible with the system ANSI encoding [1], then you don't actually need to
call _tzset nor worry about time.tzname. Call setlocale(LC_CTYPE, ''), and then
call time.strftime('%Z') to get the timezone name.
If you use Win32 directly instead of the CRT, then none of this ANSI business
is an issue. Just call GetTimeZoneInformation to get the standard and daylight
names as wide-character strings. You have that option via ctypes.
[1]: A user can select a default locale (language) that's unrelated to the
system ANSI locale (the ANSI setting is per machine, located under
Region->Administrative). Also, the preferred language can be selected
dynamically by calling SetThreadPreferredUILanguages or
SetProcessPreferredUILanguages. All three could be incompatible with each
other, in which case you have to explicitly set the locale (e.g. "ru-RU"
instead of an empty string) and call _tzset.
--
___
Python tracker
<http://bugs.python.org/issue16322>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25205] setattr accepts invalid identifiers
eryksun added the comment: To clarify using a unicode name in 2.x, it has to be encodable using the default encoding, sys.getdefaultencoding(). Normally this is ASCII. -- ___ Python tracker <http://bugs.python.org/issue25205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25205] setattr accepts invalid identifiers
eryksun added the comment: The name can be any str/unicode string, including language keywords: >>> setattr(o, 'def', 'allowed') >>> getattr(o, 'def') 'allowed' >>> o.def File "", line 1 o.def ^ SyntaxError: invalid syntax and even an empty string: >>> setattr(o, '', 'mu') >>> getattr(o, '') 'mu' This includes instances of str and unicode subclasses, at least in CPython. -- assignee: -> docs@python components: +Documentation nosy: +docs@python, eryksun priority: normal -> low versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue25205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
eryksun added the comment:
> local_encoding = locale.getdefaultlocale()[1]
Use locale.getpreferredencoding().
> b = eval('b' + ascii(result))
> result = b.decode(local_encoding)
It's simpler and more reliable to use 'latin-1' and 'mbcs' (ANSI). For example:
result = result.encode('latin-1').decode('mbcs')
If setlocale(LC_CTYPE, "") is called before importing the time module, then
tzname is already correct. In this case, the above is either harmless or raises
a UnicodeEncodeError that can be handled. OTOH, your approach silently corrupts
the value:
>>> result = 'Střední Evropa (běžný čas)'
>>> b = eval('b' + ascii(result))
>>> b.decode('1251')
'St\\u0159ednн Evropa (b\\u011b\\u017enэ \\u010das)'
Back to the issue. In review, on initial import of the time module, if the CRT
is using the default "C" locale, we have this inconsistency in which the time
functions encode/decode tzname as ANSI and mbstowcs decodes tzname as Latin-1.
(Plus strftime in the new CRT calls wcsftime, which adds another transcoding
layer to compound the mojibake goodness.)
If time.tzset is implemented on Windows, then at startup an application can set
the locale (specifically LC_CTYPE for tzname, and LC_TIME for strftime) and
then call time.tzset().
Example with Russian system locale:
Initially we're in the "C" locale and the CRT's tzname is in ANSI. time.tzname
incorrectly decodes this as Latin-1 since that's what mbstowcs uses in the "C"
locale:
>>> time.tzname[0]
'\xc2\xf0\xe5\xec\xff \xe2 \xf4\xee\xf0\xec\xe0\xf2\xe5 UTC'
The way the CRT's strftime is implemented compounds the problem:
>>> time.strftime('%Z')
'A?aiy a oi?iaoa UTC'
It's implemented by calling the wide-character function, wcsftime. Just like
Python, this gets a wide-character string by calling mbstowcs on the ANSI
tzname. Then the CRT's strftime encodes the wide-character string back as a
best-fit ANSI string, and finally time.strftime decodes the result as Latin-1
via mbstowcs. The result is mutated mojibake:
>>> time.tzname[0].encode('mbcs', 'replace').decode('latin-1')
'A?aiy a oi?iaoa UTC'
Ironically, Python stopped calling wcsftime on Windows because of these
problems, but changes to the code since then, plus the new CRT, have brought
the problem back, and worse. See my comment in issue 10653, msg243660.
Fix this by setting the locale and calling _tzset:
>>> import ctypes, locale
>>> locale.setlocale(locale.LC_ALL, '')
'Russian_Russia.1251'
>>> ctypes.cdll.ucrtbase._tzset()
0
>>> time.strftime('%Z')
'Время в формате UTC'
If time.tzset were implemented on Windows, calling it would reload the
time.tzname tuple.
--
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue16322>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error
eryksun added the comment: Lauri changed the version from 3.4 to 3.2, and I was able to reproduce the problem in 3.2.5: C:\Temp>py -3.2 --version Python 3.2.5 C:\Temp>py -3.2 nospace.py removing fill.txt Traceback (most recent call last): File "nospace.py", line 8, in n = f.write(b"\0") IOError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "nospace.py", line 8, in n = f.write(b"\0") IOError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "nospace.py", line 12, in os.remove(fill) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'T:\\fill.txt' It's a sharing violation, since the file handle isn't closed and wasn't opened with FILE_SHARE_DELETE. There's no problem in 3.4 or 3.5 since it properly closes the file handle even if flush() fails: C:\Temp>py -3.4 --version Python 3.4.3 C:\Temp>py -3.4 nospace.py removing fill.txt C:\Temp>py -3.5 --version Python 3.5.0 C:\Temp>py -3.5 nospace.py removing fill.txt -- ___ Python tracker <http://bugs.python.org/issue25202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error
eryksun added the comment: See issue 16597. This wasn't fixed for 3.2, so it won't close the file if flush() fails. You'll either have to work around this or upgrade to 3.3+. ------ nosy: +eryksun resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue25202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25189] An issue about os.access
eryksun added the comment: > This looks as a duplicate of issue2528. No, yangyanbo's problem is unrelated to the file's security descriptor, and it's not a bug. telnet.exe is manually installed via "Programs and Features", which only installs a 64-bit version into System32 (despite the 32 in its name, this directory has native 64-bit executables). But yangyanbo is running 32-bit Python, so accessing "System32" gets redirected to SysWOW64 (despite the 64 in its name, this directory has 32-bit executables that run in the "Windows 32-bit on Windows 64-bit" system). >From a 32-bit app the real System32 directory is available as "SysNative", >e.g.: os.access(r'C:\Windows\SysNative\telnet.exe', os.X_OK) -- nosy: +eryksun resolution: duplicate -> not a bug superseder: Change os.access to check ACLs under Windows -> ___ Python tracker <http://bugs.python.org/issue25189> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding
eryksun added the comment:
To decode the tzname strings, Python calls mbstowcs, which on Windows uses
Latin-1 in the "C" locale. However, in this locale the tzname strings are
actually encoded using the system ANSI codepage (e.g. 1250 for Central/Eastern
Europe). So it ends up decoding ANSI strings as Latin-1 mojibake. For example:
>>> s
'Střední Evropa (běžný čas) | Střední Evropa (letní čas)'
>>> s.encode('1250').decode('latin-1')
'Støední Evropa (bì\x9ený èas) | Støední Evropa (letní èas)'
You can work around the inconsistency by calling setlocale(LC_ALL, "") before
anything imports the time module. This should set a locale that's not "C", in
which case the codepage should be consistent. Of course, this won't help if you
can't control when the time module is first imported.
The latter wouldn't be a issue if time.tzset were implemented on Windows. You
can at least use ctypes to call the CRT's _tzset function. This solves the
problem with time.strftime('%Z'). You can also get the CRT's tzname by calling
the exported __tzname function. Here's a Python 3.5 example that sets the
current thread to use Russian and creates a new tzname tuple:
import ctypes
import locale
kernel32 = ctypes.WinDLL('kernel32')
ucrtbase = ctypes.CDLL('ucrtbase')
MUI_LANGUAGE_NAME = 8
kernel32.SetThreadPreferredUILanguages(MUI_LANGUAGE_NAME,
'ru-RU\0', None)
locale.setlocale(locale.LC_ALL, 'ru-RU')
# reset tzname in current locale
ucrtbase._tzset()
ucrtbase.__tzname.restype = ctypes.POINTER(ctypes.c_char_p * 2)
c_tzname = ucrtbase.__tzname()[0]
tzname = tuple(tz.decode('1251') for tz in c_tzname)
# print Cyrillic characters to the console
kernel32.SetConsoleOutputCP(1251)
stdout = open(1, 'w', buffering=1, encoding='1251', closefd=0)
>>> print(tzname, file=stdout)
('Время в формате UTC', 'Время в формате UTC')
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue16322>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25117] Windows installer: precompiling stdlib fails with missing DLL errors
eryksun added the comment: Per "Python 3.5.0 (32-bit)_20150914055131.log", the installer detects the OS as NT 6.2.9200 (Windows 8/Server 2012), and installs Windows8-RT-KB2999226-x64.msu. [0A68:0EC8][2015-09-14T05:51:31]i001: Burn v3.10.0.1823, Windows v6.2 (Build 9200: Service Pack 0), path: C:\Users\mg\Downloads\python-3.5.0.exe [0F48:03B4][2015-09-14T05:54:05]i301: Applying execute package: crt_14.0_v6.2_x64, action: Install, path: C:\ProgramData\Package Cache\ 0F275C704EE13CA9E98834DB6DA50D4693FF2BAF\ Windows8-RT-KB2999226-x64.msu, arguments: '"C:\Windows\SysNative\wusa.exe" "C:\ProgramData\Package Cache\ 0F275C704EE13CA9E98834DB6DA50D4693FF2BAF\ Windows8-RT-KB2999226-x64.msu" /quiet /norestart' which seems to succeed: [0A68:0EC8][2015-09-14T05:54:24]i319: Applied execute package: crt_14.0_v6.2_x64, result: 0x0, restart: Required Yet trying to run py.exe to compile the standard library fails with STATUS_DLL_NOT_FOUND (0xC135): [0F48:03B4][2015-09-14T05:55:11]i301: Applying execute package: compileall_AllUsers, action: Install, path: C:\ProgramData\Package Cache\ 1D1205B0F2D3B4B31CC368C86271206AEF327163\py.exe, arguments: '"C:\ProgramData\Package Cache\ 1D1205B0F2D3B4B31CC368C86271206AEF327163\py.exe" -3.5-32 -E -s -Wi "C:\Python35\Lib\compileall.py" -f -x "bad_coding|badsyntax|site-packages|py2_| lib2to3\\tests|venv\\scripts" "C:\Python35\Lib"' [0F48:03B4][2015-09-14T05:57:24]e000: Error 0xc135: Process returned error: 0xc135 Your screenshot shows that api-ms-win-crt-runtime-l1-1-0.dll is missing. Does this DLL exist in "%SystemRoot%\SysWOW64"? -- ___ Python tracker <http://bugs.python.org/issue25117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25117] Windows installer: precompiling stdlib fails with missing DLL errors
eryksun added the comment: > Pre-compiling should generally not be needed It's a useful optimization if Python is installed to a directory that doesn't grant write access to regular users, such as %ProgramFiles%. -- ___ Python tracker <http://bugs.python.org/issue25117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25117] Windows installer: precompiling stdlib fails with missing DLL errors
eryksun added the comment: There should be a bunch of logs named "Python 3.5.0*.log" in your user's %TEMP% directory. If you don't mind, zip them up and attach the file to this issue for Steve Dower to review when he returns from vacation. In the mean time, try directly installing the Universal CRT update, [KB2999226][1]. For Server 2012 R2, [KB2919355][2] should be installed first. [1]: http://www.microsoft.com/en-us/download/details.aspx?id=48234 [2]: http://www.microsoft.com/en-us/download/details.aspx?id=42334 -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1
eryksun added the comment: The issue as I understand it is that, on this particular Windows 8.1 system, passing a non-NULL lpEnvironment to CreateProcess works when starting a native 64-bit executable, but fails when starting a 32-bit executable via the WOW64 system. The child process instead gets an empty environment block. As an additional check, run the following command in 64-bit cmd.exe: start "" /I "%SystemRoot%\SysWOW64\cmd.exe" The /I option of the start command passes the shell's original environment to CreateProcess, so it should exhibit the same empty-environment problem when starting 32-bit cmd.exe. In this case you'll get cmd's default environment, which includes COMSPEC, PATHEXT, and PROMPT. Since inheriting the current environment works in all cases and passing a custom environment works for 64-bit executables, the workaround that I suggested is to use shell=True to pass your custom environment to the shell. The 32-bit executable thus inherits the custom environment from the shell. If using shell=True is a security concern, then you can replace it with a Python script that executes and waits for the child process. > when passing shell=True everything worked - except > when passing `cwd` as well, then it's broken again. Since the shell executes the file, a relative path is resolved against the shell's working directory. If you set the latter via the cwd parameter, then pass the file's path as either relative to the cwd path or as a fully qualified path. -- ___ Python tracker <http://bugs.python.org/issue24493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25119] Windows installer fails to install VCRUNTIME140.DLL
eryksun added the comment: virtualenv fails to copy vcruntime140.dll. Use the standard library's venv module instead. -- nosy: +eryksun resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue25119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25120] No option displayed in the Python install on windows XP
eryksun added the comment: Maybe the download page should direct XP users to install 3.4.x. -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25118] OSError in os.waitpid
eryksun added the comment:
This bug is due to issue 23285, which improved support for EINTR handling.
os_waitpid_impl was changed to use the following do-while loop:
do {
Py_BEGIN_ALLOW_THREADS
res = _cwait(&status, pid, options);
Py_END_ALLOW_THREADS
} while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals()));
if (res != 0)
return (!async_err) ? posix_error() : NULL;
The last test should be (res < 0) instead of (res != 0). That's why you're
getting a no-error exception.
It seems to me this entire loop should be removed. The Windows C runtime
doesn't set errno to EINTR. In the case of _cwait it doesn't even use an
alertable wait (i.e. it can't be interrupted by a regular asynchronous
procedure call).
--
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue25118>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4
eryksun added the comment: But it should go without saying that clearing errno from Python isn't reliable considering how much code executes between Python statements. It needs to be cleared right before call strftime, and optionally the old value needs to be saved first in order to restore it, if you're concerned about that. -- ___ Python tracker <http://bugs.python.org/issue25092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4
eryksun added the comment:
> Is there a way people can set errno to zero from Python code?
> Or do we need to ship 3.5.1 already?
The only the thing that comes to mind is using ctypes based on the CRT's
implementation of errno:
import ctypes
import errno
import time
ucrtbase = ctypes.CDLL('ucrtbase')
ucrtbase._errno.restype = ctypes.POINTER(ctypes.c_int)
c_errno = ucrtbase._errno().contents
>>> time.strftime('')
''
>>> c_errno.value = errno.EINVAL; time.strftime('')
Traceback (most recent call last):
File "", line 1, in
ValueError: Invalid format string
--
___
Python tracker
<http://bugs.python.org/issue25092>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4
eryksun added the comment: > errno should always be cleared before use (in C99 at least, > not sure what the crt does). The CRT's strftime doesn't clear errno. I suggested clearing it in issue 25029, msg250215. ------ nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25107] Windows 32-bit: exe-files doesn't run
Changes by eryksun : -- components: +Windows -IDLE ___ Python tracker <http://bugs.python.org/issue25107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25107] Windows 32-bit: exe-files doesn't run
eryksun added the comment: The latest version that supports Windows XP is 3.4.3. -- components: +IDLE -Windows nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue25107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25051] 'compile' refuses BOM.
eryksun added the comment:
You're passing an already decoded string, so the BOM is treated as text.
Instead open the file in binary mode, i.e. open("bom3.py", "rb"). This way the
BOM will be detected when decoding the source bytes. Here's an example that
passes the source as a bytes object:
>>> source = b'\xef\xbb\xbf#coding: utf-8\nprint("spam")'
>>> code = compile(source, '', 'exec')
>>> exec(code)
spam
Or you could also decode the file contents without the BOM via open("bom3.py",
encoding="utf-8-sig").
--
nosy: +eryksun
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25051>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
eryksun added the comment:
I think 3.5 should be distributed with vcruntime140.dll. It seems a waste for
python.exe, python35.dll, and all of the extension modules and dependent DLLs
to each take an FLS slot:
>>> import ctypes # +1 for _ctypes
>>> kernel32 = ctypes.WinDLL('kernel32')
>>> kernel32.FlsGetValue.restype = ctypes.c_void_p
>>> [x for x in range(128) if kernel32.FlsGetValue(x)]
[1, 2, 4, 5, 6, 8]
>>> import pyexpat, select, unicodedata, winsound
>>> import _bz2, _decimal, _elementtree, _hashlib
>>> import _lzma, _msi, _multiprocessing, _overlapped
>>> import _socket, _sqlite3, _ssl, _tkinter
>>> [x for x in range(128) if kernel32.FlsGetValue(x)]
[1, 2, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22,
23, 24, 25, 26, 27]
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue25027>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25029] MemoryError in test_strptime
eryksun added the comment:
Steve, it seems to me that for MSVC the EINVAL test should come first:
_Py_BEGIN_SUPPRESS_IPH
olderr = errno;
errno = 0;
buflen = format_time(outbuf, i, fmt, &buf);
err = errno;
errno = olderr;
_Py_END_SUPPRESS_IPH
if (buflen == 0 && err == EINVAL) {
PyErr_SetString(PyExc_ValueError, "Invalid format string");
break;
}
Then the old test could be restored, i.e. (buflen > 0 || i >= 256 * fmtlen).
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue25029>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25023] time.strftime('%a'), ValueError: embedded null byte, in ko locale
eryksun added the comment:
It seems VC 14 has a bug here. In the new C runtime, strftime is implemented by
calling wcsftime as follows:
size_t const result = _Wcsftime_l(wstring.get(), maxsize, wformat.get(),
timeptr, lc_time_arg, locale);
if (result == 0)
return 0;
// Copy output from wide char string
if (!WideCharToMultiByte(lc_time_cp, 0, wstring.get(), -1, string,
static_cast(maxsize), nullptr, nullptr))
{
__acrt_errno_map_os_error(GetLastError());
return 0;
}
return result;
The WideCharToMultiByte call returns the number of bytes in the converted
string, but strftime doesn't update the value of "result".
This worked correctly in the old CRT. For example, in 3.4 built with VC 10:
>>> sys.version_info[:2]
(3, 4)
>>> locale.setlocale(locale.LC_ALL, 'kor_kor')
'Korean_Korea.949'
>>> time.strftime('%a')
'\ud654'
Here's an overview of the problem in 3.5, stepped through in the debugger:
>>> sys.version_info[:2]
(3, 5)
>>> locale.setlocale(locale.LC_ALL, 'ko')
'ko'
>>> time.strftime('%a')
Breakpoint 0 hit
ucrtbase!Wcsftime_l:
07fe`e9e6fd74 48895c2410 mov qword ptr [rsp+10h],rbx
ss:`003df6d8=00666ce0
wcsftime returns the output buffer length in wide characters:
0:000> pt; r rax
rax=0001
WideCharToMultiByte is called to convert the wide-character string to the
locale encoding:
0:000> pc
ucrtbase!Strftime_l+0x17f:
07fe`e9e6c383 ff15dfa00200callqword ptr
[ucrtbase!_imp_WideCharToMultiByte (07fe`e9e96468)] ds:07fe`
e9e96468={KERNELBASE!WideCharToMultiByte (07fe`fd631be0)}
0:000> p
ucrtbase!Strftime_l+0x185:
07fe`e9e6c389 85c0testeax,eax
This returns the length of the converted string (including the null):
0:000> r rax
rax=0003
But strftime ignores this value, and instead returns the wide-character string
length, which gets passed to PyUnicode_DecodeLocaleAndSize:
0:000> bp python35!PyUnicode_DecodeLocaleAndSize
0:000> g
Breakpoint 1 hit
python35!PyUnicode_DecodeLocaleAndSize:
`5ec15160 4053pushrbx
0:000> r rdx
rdx=0001
U+D654 was converted correctly to '\xc8\cad' (codepaged 949):
0:000> db @rcx l3
`007e5d20 c8 ad 00 ...
However, since (str[len] != '\0'), PyUnicode_DecodeLocaleAndSize errors out as
follows:
0:000> bd 0,1; g
Traceback (most recent call last):
File "", line 1, in
ValueError: embedded null byte
It works as expected if the length is manually changed to 2:
>>> time.strftime('%a')
Breakpoint 1 hit
python35!PyUnicode_DecodeLocaleAndSize:
`5ec15160 4053pushrbx
0:000> r rdx=2
0:000> g
'\ud654'
The string is null-terminated, so can time_strftime simply substitute
PyUnicode_DecodeLocale in place of PyUnicode_DecodeLocaleAndSize?
--
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue25023>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24917] time_strftime() Buffer Over-read
eryksun added the comment:
With MSVC, if errno is cleared before calling strftime, then when buflen == 0
you know whether it's an invalid format string (EINVAL) or maxsize is too small
(ERANGE). There's no need to guess. Oddly, only EINVAL is documented, even
though setting ERANGE has been in the implementation for years.
VC 10 (strftime.c):
/* error - return an empty string */
*(strstart)='\0';
/* now return our error/insufficient buffer indication */
if ( !failed && left <= 0 )
{
/* do not report this as an error to allow the caller to resize
*/
errno=ERANGE;
}
else
{
_VALIDATE_RETURN( FALSE, EINVAL, 0);
}
VC 14 (time/wcsftime.cpp):
// Error: return an empty string:
*string = L'\0';
// Now return our error/insufficient buffer indication:
if (!failed && remaining <= 0)
{
// Do not report this as an error to allow the caller to resize:
errno = ERANGE;
}
else
{
_VALIDATE_RETURN(false, EINVAL, 0);
}
--
___
Python tracker
<http://bugs.python.org/issue24917>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24917] time_strftime() Buffer Over-read
eryksun added the comment:
> MSVC seems somewhat inconsistent about its response:
> >>> strftime('aaa%')
> ''
That's not due to MSVC. It's setting errno to EINVAL. The problem is that
time_strftime is testing (buflen > 0 || i >= 256 * fmtlen). The initial value
of the outbuf size i is 1024, so when (fmtlen <= 4), the value of (256 *
fmtlen) is less than or equal to i, and it assumes "the format yields an empty
result" without considering the value of errno. So instead of raising an
exception for EINVAL, it calls PyUnicode_DecodeLocaleAndSize to return an empty
string:
>>> strftime('aaa%')
Breakpoint 1 hit
ucrtbase!strftime:
07fe`e2bac3e0 4883ec38sub rsp,38h
0:000> gu
python35!time_strftime+0x1f5:
`5de9c785 488bcb mov rcx,rbx
0:000> be 0; g
Breakpoint 0 hit
ucrtbase!_errno:
07fe`e2b341b0 48895c2408 mov qword ptr [rsp+8],rbx
ss:`0028f320=
errno is 22:
0:000> pt; dd @rax l1
`002ddb50 0016
0:000> bd 0; g
Breakpoint 2 hit
python35!PyUnicode_DecodeLocaleAndSize:
`5df55070 4053pushrbx
0:000> k 2
Child-SP RetAddr Call Site
`0028f318 `5de9c81a python35!PyUnicode_DecodeLocaleAndSize
`0028f320 `5df1d5c2 python35!time_strftime+0x28a
0:000> g
''
--
___
Python tracker
<http://bugs.python.org/issue24917>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25012] pathlib should allow converting to absolute paths without resolving symlinks
eryksun added the comment: There's a public method that's almost what you want: >>> print(pathlib.Path.absolute.__doc__) Return an absolute version of this path. This function works even if the path doesn't point to anything. No normalization is done, i.e. all '.' and '..' will be kept along. Use resolve() to get the canonical path to a file. However, it appears to be only accidentally public. It isn't tested; it isn't mentioned in the docs; and it doesn't do the [expected] path normalization. Currently it's used as a default in resolve() if self._flavour.resolve(self) returns None. -- nosy: +eryksun versions: +Python 3.4 -Python 2.7 ___ Python tracker <http://bugs.python.org/issue25012> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24917] time_strftime() Buffer Over-read
eryksun added the comment: > Rather than debating about how various platforms handle malformed > format strings for strftime(), and whether or not they crash, we > should simply prevent the native strftime() function from seeing > them in the first place. Of course the check needs to be restored. I wasn't suggesting to go back to the default IPH to have it terminate the process. That won't help, anyway. The potential over-read is in the for loop, before calling strftime. I just thought the context for the accidental removal was relevant. Care needs to be taken when removing checks that were put in place to avoid the default IPH, because those checks may serve a dual purpose in the surrounding code. The patch also fixes the AIX/Sun code, which needs to be applied to 3.4 as well. I don't think this issue applies to 3.2 and 3.3. -- ___ Python tracker <http://bugs.python.org/issue24917> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24917] time_strftime() Buffer Over-read
eryksun added the comment:
> On Windows, the C lib strftime() segfaults with a trailing '%',
> just as it does with unsupported format codes.
No, it doesn't segfault; it invokes the invalid parameter handler (IPH). This
could always be configured for the whole process, but with VC 14 it can also be
configured per thread. I think it was Steve Dower who updated time_strftime to
take advantage of this feature in 3.5, using the new macros
_Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH. This allowed removing the
following check that used to be in the code prior to 3.5:
if (outbuf[1]=='\0' ||
!strchr("aAbBcdHIjmMpSUwWxXyYzZ%", outbuf[1]))
{
PyErr_SetString(PyExc_ValueError, "Invalid format string");
Py_DECREF(format);
return NULL;
}
With this change the time module no longer has to make assumptions about what
the CRT considers to be a valid format string in order to avoid invoking the
IPH. However, this also accidentally removed checking whether outbuf[1]=='\0'.
Now, instead of calling the default IPH that terminates the process, Python's
_silent_invalid_parameter_handler gets called, which of course does nothing by
design:
>>> import time
>>> time.strftime('A%')
Breakpoint 0 hit
python35!_silent_invalid_parameter_handler:
`5eadae50 c2 ret 0
0:000> k8
Child-SP RetAddr Call Site
`002af018 07fe`e9d8d2ab
python35!_silent_invalid_parameter_handler
`002af020 07fe`e9d8d2c9 ucrtbase!invalid_parameter+0x103
`002af060 07fe`e9dafedc ucrtbase!invalid_parameter_noinfo+0x9
`002af0a0 07fe`e9dac359 ucrtbase!Wcsftime_l+0x168
`002af140 07fe`e9dac3f5 ucrtbase!Strftime_l+0x155
`002af1d0 `5e9fc785 ucrtbase!strftime+0x15
`002af210 `5ea7d5c2 python35!time_strftime+0x1f5
`002af2b0 `5eaf8fd0 python35!PyCFunction_Call+0x122
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue24917>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24998] docs: subprocess.Popen example has extra/invalid parameter
Changes by eryksun : -- keywords: +easy priority: normal -> low versions: +Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24977] shutil copy to non-existant directory
eryksun added the comment: Do you mean the dst path has a trailing slash, but the directory doesn't exist? shutil.copy doesn't check for a trailing slash, so it attempts to open dst as a regular file. On Linux, and probably most POSIX systems, this results in an EISDIR (is a directory) error. On Windows the error is ERROR_INVALID_NAME, which the CRT maps to EINVAL (invalid argument). -- components: +Library (Lib) nosy: +eryksun versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24983] Wrong AttributeError propagation
eryksun added the comment: > exception instance raised in __getattr__ should not lead > to its another call but propagated to outer level In this case the next outer level is your descriptor implementation. You have to ensure it doesn't leak the AttrubuteError. Otherwise the associated __getattribute__ call is implicitly raising AttributeError, and [by design][1] Python must default to calling __getattr__. [1]: https://docs.python.org/3/reference/datamodel.html#object.__getattribute__ ------ nosy: +eryksun stage: -> resolved ___ Python tracker <http://bugs.python.org/issue24983> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24971] os.environ.get() does not return the Environment Value in Linux
eryksun added the comment:
Did you mark the variable for export in your shell? For example:
$ v=1
$ python -c 'import os;print os.environ.get("v")'
None
$ export v
$ python -c 'import os;print os.environ.get("v")'
1
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue24971>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24958] Segfault in REPL after pressing "r" and PgUp twice (on Mageia Linux x86-64 6)
eryksun added the comment: A gdb backtrace may be of more help than strace. -- ___ Python tracker <http://bugs.python.org/issue24958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24958] Segfault in REPL after pressing "r" and PgUp twice (on Mageia Linux x86-64 6)
eryksun added the comment: Maybe the problem is using escape characters (0x1b) instead of \e. Try using the following: "\e[5~": history-search-backward FWIW, your inputrc doesn't crash my system (64-bit Linux, readline 6.3 and Python 3.4). ------ nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue24958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24829] Use interactive input even if stdout is redirected
eryksun added the comment: > If you dropped the isatty() check for stdout in Linux, you may > end up with the output of Readline in the file (assuming > Readline is okay with this). The file would include all the > cursor positioning codes, backspaces, etc, that Readline > generates. But I haven’t actually tried this. Yes, that's what happens. It seems to me the isatty check could be moved to call_readline in Modules/readline.c. This way PyOS_ReadlineFunctionPointer decides whether to call PyOS_StdioReadline. (See issue 512981 for the patch that introduced the isatty check.) A related issue in Windows is that when stdout isn't a console, the text encoding defaults to the locale's ANSI encoding (e.g. cp1252). UTF-8 can be forced by setting the environment variable PYTHONIOENCODING=utf-8. Also of concern is the pyreadline module. Its [Console class] assumes that the process standard handles are console handles. This is generally valid given the isatty check. OTOH, when I removed this check and redirected stdout to a file, pyreadline crashed in an endless loop. pyreadline's hook could punt to PyOS_StdioReadline if stdin and stdout don't both refer to the console. The problem there is calling the CRT's _fileno (POSIX) function in Python. Maybe the os module could wrap fileno in Modules/posixmodule.c. In addition to accepting a FILE pointer, os.fileno could accept an enum of C_STDIN, C_STDOUT, and C_STDERR. [1]: https://github.com/pyreadline/pyreadline/blob/0be3f019ecfdaf740555dc91a1156ddd5dd195f2/pyreadline/console/console.py#L176 -- nosy: +eryksun versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue24829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24920] shutil.get_terminal_size throws AttributeError
eryksun added the comment: FYI, the size of the terminal associated with the C's stdout isn't related to the IDLE shell. For example, in Linux when I run IDLE from the GUI, the associated terminal size is 0x0. On Windows, os.get_terminal_size uses the console API GetConsoleScreenBufferInfo. This can't work given IDLE has no attached console. Also, for a GUI app the Windows C runtime leaves the standard FILE streams uninitialized to an invalid file descriptor (-1), so Python's sys.__stdout__ is None. That's why you get an AttributeError complaining that NoneType (i.e. type(None)) has no attribute 'fileno'. Currently shutil.get_terminal_size returns the fallback size when os.get_terminal_size(sys.__stdout__.fileno()) raises NameError or OSError. I think AttributeError and ValueError should be added to this list. -- components: +Windows -IDLE nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24919] Use user shell in subprocess
eryksun added the comment: Here's the rationale given for ignoring SHELL in POSIX system(): One reviewer suggested that an implementation of system() might want to use an environment variable such as SHELL to determine which command interpreter to use. The supposed implementation would use the default command interpreter if the one specified by the environment variable was not available. This would allow a user, when using an application that prompts for command lines to be processed using system(), to specify a different command interpreter. Such an implementation is discouraged. If the alternate command interpreter did not follow the command line syntax specified in the Shell and Utilities volume of POSIX.1-2008, then changing SHELL would render system() non-conforming. This would affect applications that expected the specified behavior from system(), and since the Shell and Utilities volume of POSIX.1-2008 does not mention that SHELL affects system(), the application would not know that it needed to unset SHELL. -- ___ Python tracker <http://bugs.python.org/issue24919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24919] Use user shell in subprocess
eryksun added the comment:
I expect Popen's shell=True option to use the same shell as os.system. The
POSIX spec for the [system function][1] requires running sh, as follows:
execl(, "sh", "-c", command, (char *)0);
glibc uses "/bin/sh" for the shell path. Modifying the SHELL environment
variable doesn't affect the behavior of os.system. I would be surprised if
Popen's shell=True had been designed like that. Thankfully it's too late to
change this since it could break existing code. ;-)
The story is different on Windows. The CRT's system() prefers the shell that's
set in the ComSpec environment variable. So on Windows Popen uses
os.environ.get("COMSPEC", "cmd.exe").
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue24919>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
eryksun added the comment: The 3.5 build uses MSVC 14 (VS 2015): https://docs.python.org/3.5/using/windows.html#compiling-python-on-windows https://hg.python.org/cpython/file/3.5/PCbuild/readme.txt -- nosy: +eryksun ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
eryksun added the comment:
> It is not clear why the absence of _setmode(fd, os.O_BINARY)
> is not detected by tests.
It's only a problem when an existing text-mode file descriptor is passed in.
For example, in text mode the CRT handles b'\x1a' as an EOF marker:
Python 3.5.0b4 (v3.5.0b4:c0d641054635, Jul 26 2015, 07:11:12)
[MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, _pyio
>>> _ = open('testfile', 'wb').write(b'abc\x1adef')
>>> fd = os.open('testfile', os.O_RDONLY|os.O_TEXT)
>>> f = _pyio.open(fd, 'rb')
>>> f.read()
b'abc'
>>> f.close()
>>> f = _pyio.open('testfile', 'rb')
>>> f.read()
b'abc\x1adef'
The setmode call ensures a file descriptor is in the expected binary mode:
>>> import msvcrt
>>> fd = os.open('testfile', os.O_RDONLY|os.O_TEXT)
>>> old_mode = msvcrt.setmode(fd, os.O_BINARY)
>>> old_mode == os.O_TEXT
True
>>> f = _pyio.open(fd, 'rb')
>>> f.read()
b'abc\x1adef'
--
nosy: +eryksun
___
Python tracker
<http://bugs.python.org/issue24881>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24908] sysconfig.py and distutils.sysconfig.py disagree on directory spelling on Windows
eryksun added the comment: Within the standard library, I think only the site module uses the top-level sysconfig module, which IIRC it uses to set up sys.path. Note that WINDOWS_SCHEME in distutils.command.install uses "Include". Also for virtual environments, venv.EnvBuilder.ensure_directories hard codes "Include". -- components: +Distutils, Windows nosy: +dstufft, eric.araujo, eryksun, paul.moore, steve.dower, tim.golden, zach.ware priority: normal -> low type: -> behavior versions: +Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
