Eryk Sun added the comment:
>> Why are __flags__, __basicsize__, __itemsize__,
>>__dictoffset__, and __weakrefoffset__ interesting?
>
> I haven't said they are, but on the other hand I don't see
> why consistency is a bad thing.
IMO, they're not intere
Eryk Sun added the comment:
So there are a couple things to clarify here. When the documentation says "if
the optional parts are omitted, the code is executed in the current scope", I
think it should explicitly state that this is equivalent to calling
exec(object, globals(), local
Eryk Sun added the comment:
communicate() is incomplete, so decoding the output may fail. For example, say
the encoding is UTF-8, and the last multibyte character sequence (2-4 bytes) is
incomplete. Maybe communicate() should always set `stdout_bytes` and
`stderr_bytes` attributes on the
Eryk Sun added the comment:
The idea of adding some kind of clear_screen() function in the os or shutil
module was discussed extensively on python-ideas a few months ago:
https://mail.python.org/archives/list/python-id...@python.org/thread/EWQ2BOL3WVZAU2V2MT3HLXN3AEBHANNZ
https
Eryk Sun added the comment:
> I'm not sure of what you mean. The function is implemented:
My comment was limited to Windows, for which time.tzset() has never been
implemented. Since Python has its own implementation of time.tzname in Windows,
it should also implement time.tzset()
Eryk Sun added the comment:
> Eryk Sun: This issue is now closed. If you want to enhance
> the time module, please open a new issue.
I was aware of that at the time, Victor. The problem can be worked on in a new
issue, or in the older issue bpo-8304, which remains open. The two me
Eryk Sun added the comment:
venv copies the scripts in binary mode, but apparently the Unix "activate"
script already has CRLF line endings when Python is installed in Windows.
Probably the POSIX "Lib/venv/scripts/common/activate" script needs a
line-ending exceptio
Eryk Sun added the comment:
T-VEy, this is a documentation-only issue for versions of Python that are under
active development for bug fixes and enhancements -- 3.8, 3.9, and 3.10.
--
versions: +Python 3.10, Python 3.8
___
Python tracker
<ht
Eryk Sun added the comment:
>> PEP 443
>
> I guess that you mean the PEP 446 ;-)
Yes, that's why I meant :$
--
___
Python tracker
<https://bugs.p
Change by Eryk Sun :
--
components: +Library (Lib), Unicode
nosy: +ezio.melotti, vstinner
versions: +Python 3.10, Python 3.8
___
Python tracker
<https://bugs.python.org/issue42
Eryk Sun added the comment:
ntpath.normcase() needs a platform-dependent implementation that calls
LCMapStringEx() in Windows, in order to properly agree with case-insensitive
Windows filesystems. See bpo-42658.
--
nosy: +eryksun
resolution: -> duplicate
stage: -> resolved
Eryk Sun added the comment:
exec(obj, globals(), locals()) is the same as exec(obj). Also, locals in a
function scope are optimized, so the locals() dict is a snapshot. Modifying the
snapshot dict doesn't modify the optimized local variables. At most I think
this issue is a duplicate o
New submission from Eryk Sun :
pathlib._WindowsFlavour.resolve() mistakenly assume that os.getcwd() returns a
resolved path in Windows:
s = str(path)
if not s:
return os.getcwd()
I don't think this is a practical problem since `str(path)` should never be an
empty string
Change by Eryk Sun :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type: -> behavior
versions: +Python 3.10, Python 3.9 -Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issu
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
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
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 as the
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 rel
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")
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'
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,
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 b
Change by Eryk Sun :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue40863>
___
___
Python-bugs-list
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
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 :
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
Change by Eryk Sun :
--
nosy: +christian.heimes
___
Python tracker
<https://bugs.python.org/issue40882>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 coul
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 coul
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:
> 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
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
Change by Eryk Sun :
--
keywords: +easy
___
Python tracker
<https://bugs.python.org/issue40946>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 msg
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
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:
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 byte
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 is
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
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:
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.fs
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 f
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
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,
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 CreateFile
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.
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:
> 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
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 Backu
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
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
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:
> 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:
> 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, th
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:
> 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 c
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:
> "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
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
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:
> 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:
> 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 ended e
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 cre
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
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 blo
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:
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 f
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:
> 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 cou
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:
> 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 su
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
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(&#x
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:
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
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
&
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:
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:
> 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:
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/serve
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.
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 di
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, ther
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
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:
> 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 delet
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:
> 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, wi
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 append
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
handler. T
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 encodi
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:
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+ requi
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-360
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 PermissionErro
1001 - 1100 of 2119 matches
Mail list logo
