Eryk Sun added the comment:
Python supports Unicode in a Windows console session by using the console API's
wide-character functions (i.e. ReadConsoleW and WriteConsoleW) with UTF-16
encoded text. This is implemented in the io stack via io._WindowsConsoleIO, and
for PyOS_Readline (e.g
Eryk Sun added the comment:
> I wouldn't think that changing locales would have an effect on Windows
> paths being case sensitive or not, otherwise folks from other countries
> would be experiencing this error. Perhaps the mixing of locale and system
> language? I had locale
Eryk Sun added the comment:
This is already addressed in bpo-28080, which adds an `encoding` parameter --
e.g. `encoding="oem"` ("oem" is only available in Windows). Unfortunately
bpo-28080 has languished without resolution for four years.
-
Eryk Sun added the comment:
> "C:\Users\chris\code\project\myenv\Scripts\python.exe"
Have you tried different case combinations for "Users" and "Scripts"?
* C:\users\chris\code\project\myenv\scripts\python.exe
* C:\users\chris\code\project\myenv\
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg377918
___
Python tracker
<https://bugs.python.org/issue41925>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
> "C:\Users\chris\code\project\myenv\Scripts\pip.exe"
Have you tried different case combinations for "Users" and "Scripts"?
* C:\users\chris\code\project\myenv\scripts\pip.exe
* C:\users\chris\code\project\myenv\Scripts\
Eryk Sun added the comment:
> maybe we should consider moving the bitness to the folder title
> (so the folder becomes "Python 3.8 64-bit")?
Splitting up the start-menu entries into separate "Python 3.9 (32-bit)" and
"Python 3.9 (64-bit)" folders wou
Change by Eryk Sun :
--
stage: -> needs patch
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3
___
Python tracker
<https://bugs.python.org/issu
Eryk Sun added the comment:
> `data_as` method which has the desired behavior: "The returned
> pointer will keep a reference to the array."
I don't think it's the desired behavior at all. data_as() sets an _arr
attribute of which ctypes isn't aware. It should cast the addr
Eryk Sun added the comment:
I think this is a numpy issue. Its data_as() method doesn't support the ctypes
_objects protocol to keep the numpy array referenced by subsequently created
ctypes objects. For example:
import ctypes
import numpy as np
dtype = ctypes.c_double
Eryk Sun added the comment:
> File "c:\users\chris\appdata\local\programs\python\python38-32
> \lib\runpy.py", line 194, in _run_module_as_main
You have to use 64-bit Python in order to load a 64-bit DLL from the native
"%SystemRoot%\System32" directory. The
Eryk Sun added the comment:
> We already update the current shell, so if you start a new
> terminal/Powershell/cmd/etc. instance it should have the
> updated variable.
The installer broadcasts an "Environment" message to top-level windows. In
practice, on
Eryk Sun added the comment:
> The biggest risk here is that we have to emulate GNU readline for
> compatibility, which severely limits the data that can be passed
> through, and also forces multiple encoding/decoding passes.
I'm not suggesting to disable the console's line-input
New submission from Eryk Sun :
io._WindowsConsoleIO reads from the console via ReadConsoleW in line-input
mode, which limits the line length to the maximum of 256 and the size of the
client buffer, including the trailing CRLF (or just CR if processed-input mode
is disabled). Text that's
Eryk Sun added the comment:
It seems to me that if `path == name`, then resetperms(path) and possibly a
recursive call are only needed on the first call. In subsequent calls, if `path
== name`, then we know that resetperms(path) was already called, so it
shouldn't handle PermissionError
Eryk Sun added the comment:
> " OSError: [WinError 126] The specified module could not be found" is
> raised when calling ctypes.CDLL(dll_path) even when this "dll_path"
> exists... because the error comes from another DLL.
That's the old error. bpo-36085 ch
Eryk Sun added the comment:
I've decided to close this issue since extending the "Using Python on Windows"
section of the docs to recommend using a TrueType font in the console would
only be generally useful for people using Python 3.8 with Windows 7. Python
3.9+ requires W
Eryk Sun added the comment:
> It is set to use an OEM raster font.
Okay, then the issue can either be closed as third-party or changed to a
documentation enhancement. It could be documented that Unicode support requires
selecting a TrueType font in the console properties. "Raster Fon
Eryk Sun added the comment:
If you've selected an OEM raster font in the console properties instead of a
TrueType font (Consolas, Lucida Console, etc), then the console implements some
magic to support the OEM character mapping in the raster font. The following
shows that encoding
Eryk Sun added the comment:
> The return code of python on linux when the program is ended with
> a KeyboardInterrupt should be -2
In general, the exit status for an unhandled KeyboardInterrupt (i.e.
_Py_UnhandledKeyboardInterrupt) should be the same as the default SIGINT
h
Eryk Sun added the comment:
> We'd CreateFile the file and then immediately pass it to
> _open_osfhandle
Unlike _wopen, _open_osfhandle doesn't truncate Ctrl+Z (0x1A) from the last
byte when the flags value contains _O_TEXT | _O_RDWR. _wopen implements this to
allow appending data i
Eryk Sun added the comment:
> we'd have to reimplement the UCRT function using the system API.
Could the implementation drop support for os.O_TEXT? I think Python 3 should
have removed both os.O_TEXT and os.O_BINARY. 3.x has no need for the C
runtime's ANSI text mode, with its Ctr
Eryk Sun added the comment:
> Nothing preventing someone from contributing the flag on open as well.
To be clear, supporting delete-access sharing would require re-implementing C
_wopen in terms of CreateFileW, _open_osfhandle, etc. It could be implemented
as _Py_wopen in Pyt
Eryk Sun added the comment:
> Why do we need to use this O_TEMPORARY flag at all?
Using the O_TEMPORARY flag isn't necessary, but it's usually preferred because
it ensures the file gets deleted even if the process is terminated abruptly.
However, it opens the file with delete acc
Eryk Sun added the comment:
The underlying subprocess.Popen class was updated in 3.8 to support path-like
objects in `args` (with shell=False) and `executable` on Windows [1]. This
change was not backported to 3.6 and 3.7.
---
[1] https://docs.python.org/3/library/subprocess.html
Eryk Sun added the comment:
> For this case, I think the best thing we can probably do is change the
> default share mode for _all_ opens to include FILE_SHARE_DELETE.
The C runtime doesn't provide a way to share delete access, except for the
O_TEMPORARY flag, so Python would have
Eryk Sun added the comment:
> Is this line needed with a repeat of 1, or should it be removed?
It's not documented what it means to write a key event with wRepeatCount set to
0. It happens to work, but I'd leave it set to 1, which means the key was
pressed once. Ideally, there should a
Eryk Sun added the comment:
> if NotADirectoryError should be raised, it should mention '/path/to/file'
> rather then '/path/to/file/somename.txt'.
POSIX specifies that C open() should set errno to ENOTDIR when an existing path
prefix component is neither a directory nor a s
Eryk Sun added the comment:
> ÄÄ^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
I don't know why Steve made write_input (PC/_testconsole.c) set wRepeatCount in
each KeyEvent record to 10. Maybe it was a typo. Previous console
implementations have ignored the repeat count, so it wasn't an issue.
test_ctr
Eryk Sun added the comment:
This behavior is due to issue 37609, i.e. ntpath.splitdrive fails for "UNC"
device paths.
>>> ntpath.splitdrive('//?/UNC/server/share')
('//?/UNC', '/server/share')
The result should be "//?/UNC/server/share". A path on the &
Eryk Sun added the comment:
> Maybe in the time module?
The SIGINT event is also needed by PyOS_Readline, _io (builtin), _winapi
(builtin), and _multiprocessing (pyd). Is the time module guaranteed to be
imported in 3.x? It appears to get imported incidentally via _PyImportZip_I
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg376231
___
Python tracker
<https://bugs.python.org/issue41686>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
> Maybe in the time module?
The SIGINT event is also needed by PyOS_Readline, _io (builtin), _winapi
(builtin), and _multiprocessing (pyd). Is the time module guaranteed to be
imported in 3.x? It appears to get imported incidentally via _PyImportZip_I
Eryk Sun added the comment:
The SIGINT event gets created when the _signal extension module is imported.
Until then, _PyOS_SigintEvent() returns NULL. But currently all code that calls
_PyOS_SigintEvent() assumes it returns a valid handle. This has to be fixed to
support Py_InitializeEx(0
Eryk Sun added the comment:
Case-sensitive file access is potentially possible with
FILE_FLAG_POSIX_SEMANTICS (CreateFileW) and FIND_FIRST_EX_CASE_SENSITIVE
(FindFirstFileExW). These flags make the API omit the object-manager flag
OBJ_CASE_INSENSITIVE in the NtCreateFile or NtOpenFile
Eryk Sun added the comment:
I suppose that, in addition to fixing the bug with si.dwFlags, code could be
added to use DETACHED_PROCESS if GetConsoleCP() returns 0 (i.e. the launcher
isn't attached to a console).
--
___
Python tracker
<ht
Eryk Sun added the comment:
Creating the py.exe process with creationflags=DETACHED_PROCESS sets a special
ConsoleHandle value in its ProcessParameters that makes the base API skip
allocating a console session at process startup. However, the launcher itself
spawns python.exe normally
Change by Eryk Sun :
--
status: open -> closed
type: compile error -> behavior
___
Python tracker
<https://bugs.python.org/issue41565>
___
___
Python-bugs-
Eryk Sun added the comment:
It's worth mentioning that pathlib restricts the first character of a Windows
drive name to the set of ASCII letters in
pathlib._WindowsFlavour.drive_letters. For example:
>>> Path('3') / 'C:3'
WindowsPath('C:3')
vs.
>>>
Eryk Sun added the comment:
> I mean，os.path.join('3', '{:3') return '{:3' in windows, However,
> os.path.join('3', '{:3') return '3/{:3'in linux, output result not
> '3' in windows, why?
The implementation of ntpath.join handles "{:" as a drive. Thus "{:3" i
Eryk Sun added the comment:
> I'm not sure if "}" could ever be valid drive letter
The Windows file API is designed in a way to support almost any Unicode BMP
character in a DOS drive designation. For example, the following creates "{:"
as a substit
Eryk Sun added the comment:
> I suspect the Windows version is using some API that strips whitespace
> from the filename before performing a relative path.
When normalizing a path, the Windows API strips trailing dots and spaces from
the final component. Apparently it also strips a
Eryk Sun added the comment:
> Does the same apply for time.monotonic? I would argue that the
> difference in behavior between Linux/macOS and Windows is
> unreasonable; given that time.monotonic exists for measuring time
> intervals
For time.monotonic in Windows, Python
Change by Eryk Sun :
--
components: +Installation
status: open ->
versions: +Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issu
Eryk Sun added the comment:
Managing multiple Python installations in PATH is problematic, so by default
the installer doesn't modify PATH. Instead, the "py.exe" launcher [1] is made
available, which can run any registered installation of Python.
Using a launcher fits t
Change by Eryk Sun :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> pathlib.Path.resolve(strict=False) returns relative path on
Windows if the entry does not exist
___
Python tra
Eryk Sun added the comment:
Winsock is inherently asynchronous. It implements synchronous functions by
using an alertable wait for the completion of an asynchronous I/O request.
Python doesn't implement anything for a console Ctrl+C event to alert the main
thread when it's blocked
Eryk Sun added the comment:
> Isn't that a backwards-incompatible change?
So, do you think it should just be documented that follow_symlinks is
effectively ignored with os.link() on most platforms that claim to support it,
unless either src_dir_fd or dst_dir_fd is used? I'd rat
Eryk Sun added the comment:
I'm trying to give os.link() and follow_symlinks the benefit of the doubt, but
the implementation just seems buggy to me.
POSIX says that "[i]f path1 names a symbolic link, it is implementation-defined
whether link() follows the symbolic link, or creates
Eryk Sun added the comment:
> running python.exe results in an error message popup which tells me ...
> that the "api-ms-win-core-path-l1-1-0.dll" is missing on the computer.
> I googled for it and it seems that this dll is not a part of Windows 7.
Microsoft end
Eryk Sun added the comment:
> in the windows API they seam to not know whether to use a ulong or a uint
This usage requires C `long int` to be the same size as `int` in 64-bit Windows.
--
resolution: -> not a bug
___
Python tracker
Eryk Sun added the comment:
In the Windows API, errors and exit status codes are all unsigned 32-bit
integers. See SetLastError, GetLastError, ExitThread, ExitProcess,
GetExitCodeThread, and GetExitCodeProcess. Even signed NTSTATUS and HRESULT
values are commonly displayed as non-negative
Eryk Sun added the comment:
> The default association should go to pyw.exe, which is likely in
> your C:\Windows directory.
However, don't browse for pyw.exe. That will create a new progid that doesn't
support command-line arguments or a shell drop handler. You should select the
Pyth
Eryk Sun added the comment:
> "Python Launcher is sorry to say... No pyvenv.cfg file"
As already mentioned, that it fails with this error means you're running a
virtual-environment launcher instead of a base Python executable. That it
displays a message box means you ran a GU
Eryk Sun added the comment:
> This is exactly what it does. The fact that it is SUBSYSTEM:WINDOWS
Sorry, I neglected to check:
C:\>python3 script.py 2>&1 | more
Python was not found but can be installed from the Microsoft Store:
https://go.microsoft.com/fwlink?l
Eryk Sun added the comment:
> there would still be value in having a known reporting channel
Windows 10 has a "Feedback Hub" to report problems and search for existing
feedback that's similar. You could report a problem with the "AppInstaller"
app. In this case,
Eryk Sun added the comment:
> Since the need to copy file ownership is common, I think there could
> be space for a new copy3() function which copies ownership + extended
> attributes (where possible).
FYI, Windows and POSIX have significantly different concepts about file
(object)
Eryk Sun added the comment:
> I still don't understand why this is considered a Python security problem.
> If the user can put a malicious "python3.dll" at some arbitrary spot in
> the filesystem (e.g. a USB flash drive), and fool Python.exe into loading
> it, then
Eryk Sun added the comment:
> If you can put files in the root of the hard drive where Windows was
> installed, surely you have other, easier attack vectors.
A rooted path is resolved relative to the process working directory, and Python
can be started with any current working dir
Eryk Sun added the comment:
> or 500 us with the undocumented NtSetSystemTime system call
Umm... that should be NtSetTimerResolution. ;-)
--
___
Python tracker
<https://bugs.python.org/issu
Eryk Sun added the comment:
> On the smaller scale, it looks quantized to multiples of ~15ms (?),
> but then it gets more accurate as the times get larger. I don't
> think it's a measurement error since the first measurement manages
> microseconds.
NT's default system time
New submission from Eryk Sun :
A console script should be able to handle Windows console logoff and shutdown
events with relatively simple ctypes code, such as the following:
import ctypes
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
CTRL_C_EVENT = 0
Eryk Sun added the comment:
In Windows, I wouldn't expect shutil.copy2 to preserve the owner and ACLs. They
change whenever a file gets copied via CopyFileExW [1]. Keeping them exactly as
in the source file generally requires a privileged backup and restore
operation, such as via BackupRead
Eryk Sun added the comment:
> it’s probably an even bigger problem on Windows, where writes might be
> limited to 32767 bytes:
This check and workaround in _Py_write_impl doesn't affect disk files and
pipes. It only affects character devices for which isatty is true, and really
it'
Eryk Sun added the comment:
> There is one local namespace for each class and function. There is one
> nonlocal namespace for each nested function.
In the first sentence, replace "class" with "class statement" and "function"
with "function cal
Eryk Sun added the comment:
> What it really means for apps that are trying to share state across
> different Python runtimes is that they're not going to have such a
> great time.
I tried impersonating the token of Explorer in the current thread (i.e.
GetSh
Eryk Sun added the comment:
> As far as I know os.stat() resets d.stat() maybe should be added
> some option to d.stat() to force update(). d.stat(nt_force_update=True).
It depends on the filesystem. NTFS will update the directory entry as soon as
the link is accessed by Creat
Eryk Sun added the comment:
> However, the API is a bit weird. Unlike Unix, when you create a
> Windows pty, there's no way to directly get access to the "slave"
> handle. Instead, you first call CreatePseudoConsole to get a
> special "HPCON" object, which
Eryk Sun added the comment:
> What it also means is that the "file still in use by another app"
> scenario will probably have to manually use os.stat(). We can't
> detect it, and it's the same race condition as calling os.stat()
> shortly before the update flushes an
Eryk Sun added the comment:
> Does it make the most sense for us to make .flush() also do an
> implicit .fsync() (when it's actually a file object)?
Standard I/O in the Windows C runtime supports a "c" commit mode that causes
fflush to call _commit() on the underlying fd [1]
Eryk Sun added the comment:
In FSBO [1] section 6 "Time Stamps", note that the LastWriteTime value gets
updated when an IRP_MJ_FLUSH_BUFFERS is processed. In the Windows API, this is
a FlushFileBuffers [2] call. In the C runtime, it's a _commit [3] call, which
is an os.fsyn
Change by Eryk Sun :
--
nosy: +vinay.sajip
versions: +Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41021>
___
___
Python-bugs-list m
Eryk Sun added the comment:
Where the POSIX specification uses the term "symbolic link" [1], it means one
and only one type of symlink, not multiple types of symlink with divergent
behavior depending on the context. To be consistent, only one type of Windows
reparse point [2] is
Eryk Sun added the comment:
By design, appexec links (i.e. app execution aliases) cannot be followed
automatically. There is no handler for them in the kernel. WinAPI CreateFileW
fails with ERROR_CANT_ACCESS_FILE (1920), and the underlying NT status value
Eryk Sun added the comment:
I can reproduce a crash with an x86 build that uses a stdcall callback with a
32-bit argument followed by any ffi_type_sint64 argument (FILETIME, long long,
etc). Apparently this is a bug in libffi's ffi_prep_cif. Given the 2nd argument
has a size of 8 bytes
Change by Eryk Sun :
--
stage: -> test needed
title: Ctype callback with Structures crashes on python 3.8 on windows. ->
ctypes callback with structure crashes in Python 3.8 on Windows
___
Python tracker
<https://bugs.python.org/i
Eryk Sun added the comment:
Please provide complete code that can be compiled as is, and the required build
environment. I wrote a similar example in C, compiled for x64 with MSVC, and it
worked fine for me. Also, please provide more details about the error -- a
traceback in a native
Eryk Sun added the comment:
Thanks for working on a PR, Zackery. Note that we can't rely on GetLastError()
in PyErr_SetFromErrnoWithFilenameObjects. It may be called in contexts where
the thread's LastErrorValue is no longer related to the C errno value.
My suggestion in msg272427
Eryk Sun added the comment:
If WaitForSingleObjectEx fails, do you think the system error code should be
raised as an OSError? Probably an invalid-handle or access-denied error is too
cryptic here. It may be better to raise something like
RuntimeError('time.sleep(): invalid SIGINT event
Change by Eryk Sun :
--
keywords: +easy
___
Python tracker
<https://bugs.python.org/issue40946>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eryk Sun :
In test.support, suppress_msvcrt_asserts sets the process error mode to include
SEM_FAILCRITICALERRORS, SEM_NOGPFAULTERRORBOX, SEM_NOALIGNMENTFAULTEXCEPT, and
SEM_NOOPENFILEERRORBOX. In contrast, the SuppressCrashReport context manager in
the same module only
Eryk Sun added the comment:
> is there any straightforward way to cause WaitForSingleObjectEx to fail?
The wait can fail for ERROR_INVALID_HANDLE or ERROR_ACCESS_DENIED (i.e. the
handle lacks SYNCHRONIZE access). If _PyOS_SigintEvent were replaced with
get/set functions, then a non-waita
Eryk Sun added the comment:
Why doesn't SuppressCrashReport suppress the hard error dialog (i.e.
SEM_FAILCRITICALERRORS)? This dialog gets created by the NtRaiseHardError
system call. For example:
>>> NtRaiseHardError = ctypes.windll.ntdll.NtRaiseHardError
>
Eryk Sun added the comment:
For a concrete example, here's a rewrite of the Windows implementation that
incorporates the suggested changes.
#include
#ifdef MS_WINDOWS
/* a named file mapping that's open more than once can't be resized */
/* this check could be moved
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg371153
___
Python tracker
<https://bugs.python.org/issue40915>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
For a concrete example, here's a rewrite of the Windows implementation that
incorporates the suggested changes.
#include
#ifdef MS_WINDOWS
/* a named file mapping that's open more than once can't be resized */
/* this check could be moved
Change by Eryk Sun :
--
nosy: +christian.heimes
___
Python tracker
<https://bugs.python.org/issue40882>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eryk Sun :
In Windows, mmap.resize() unmaps the view of the section [1], closes the
section handle, resizes the file (without error checking), creates a new
section (without checking for ERROR_ALREADY_EXISTS), and maps a new view. This
code has several problems.
Case 1
Change by Eryk Sun :
--
title: muultiple problems with mmap.resize() in Windows -> multiple problems
with mmap.resize() in Windows
___
Python tracker
<https://bugs.python.org/issu
Eryk Sun added the comment:
Thanks for working on the PR, Zackery. Would you be interested in working on
improvements to mmap for 3.10? With support in mmap, the Windows-specific
initialization of SharedMemory could be as simple as the following:
# Windows Named Shared Memory
while
New submission from Eryk Sun :
mmap.mmap in Windows doesn't support an exist_ok parameter and doesn't
correctly handle the combination fileno=-1, length=0, and tagname with an
existing file mapping. SharedMemory has to work around these limitations.
Part of the workaround for the create
Change by Eryk Sun :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue40863>
___
___
Python-bugs-list
Eryk Sun added the comment:
> The purpose of _Py_BEGIN_SUPPRESS_IPH is to suppress such popup, no?
That macro suppresses the CRT's invalid parameter handler, which by default
terminates abnormally with a fastfail (status code 0xC409), even in a
release build.
In a debug build,
Eryk Sun added the comment:
> Perhaps the child interpreter used by test_repl doesn't inherit
> that behavior.
The OS error mode is inherited, unless the child is created with
CREATE_DEFAULT_ERROR_MODE flag. But the CRT error mode isn't inherited. (For
the spawn* family, in pri
New submission from Eryk Sun :
ntpath.realpath fails to resolve the non-strict path of a broken relative
symlink if the target is a rooted path. For example:
>>> os.readlink('symlink')
'\\broken\\link'
>>> os.path.realpath('symlink')
'\\broken\\link'
&
Eryk Sun added the comment:
I think you have the right idea for improving the behavior here. It should skip
setting wShowWindow if startupinfo already has the flag STARTF_USESHOWWINDOW.
For example:
if shell:
comspec = os.environ.get("COMSPEC", "cmd.exe")
Eryk Sun added the comment:
This is still a problem with WinAPI CreateSymbolicLinkW. It fails to replace
slashes with backslashes in the substitute path if it's a relative path, which
creates a broken link. As a workaround, os.symlink should replace slashes with
backslashes in relative
New submission from Eryk Sun :
As discussed in issue 40654, os.readlink should provide a way to get the print
name of a symlink target. This is the target path that was actually passed to
WinAPI CreateSymbolicLinkW (except for drive-relative paths) and is what a
shell would display
Eryk Sun added the comment:
Modifying readlink() to return an str subclass that preserves the print name is
an interesting idea, but not on topic here.
For the cases where os.readlink is used to manually follow links (*), such as
ntpath.realpath, using the substitute name is the most
Eryk Sun added the comment:
If .py files are associated with py.exe, handling the shebang "#!/usr/bin/env
python[3]" might spawn the python[3].exe launcher recursively if it handles
shebangs (see bpo-40687). To avoid this, process() can set a flag based on the
image name tha
901 - 1000 of 2114 matches
Mail list logo
