Eryk Sun added the comment:
> There are a few ways to get multiple Python installs that
> could lead to launching the wrong one through PATH.
> --user is one of the least likely.
As far as I was aware, a --user installation prior to Python 3.10 would be the
common way to have
Eryk Sun added the comment:
> The recommendation not to use absolute paths in CDLL is still
> not mentioned in the docs:
It's not generally the case. Load just a base filename only if the shared
library is in the loader's search path. Otherwise use a qualified path that
c
Eryk Sun added the comment:
There's a formatting problem in Doc/library/multiprocessing.rst due to
consumption of the backslashes in multiple steps. The following keeps all of
the required backslashes in the HTML output:
* An ``'AF_PIPE'`` address is a string of the form
Eryk Sun added the comment:
Michael, thank you for the PR, but please associate it with the existing issue
bpo-24505.
--
nosy: +eryksun
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder: -> shutil.which wrong result on Wind
Eryk Sun added the comment:
> PS> [System.Console]::OutputEncoding
The console's current output encoding is irrelevant to this problem.
In Windows, pydoc uses the old "more.com" pager with a temporary file that's
encoded with the default encoding, which is the pr
Eryk Sun added the comment:
> PS > [System.Console]::InputEncoding = $OutputEncoding
If changing the console input codepage to UTF-8 fixes the mojibake problem,
then probably you're running Python in UTF-8 mode. pydoc.tempfilepager()
encodes the temporary file with the preferr
Eryk Sun added the comment:
> I was one of the people who mistakenly thought that Python 3 operating
> in the new Windows Terminal was going to magically leave us sitting
> happily in completely UTF-8 compatible territory on Windows, not
> realizing the complex long-term depe
Eryk Sun added the comment:
> Now many people want to use Python with UTF-8 mode in PowerShell
> in Windows Terminal. And they don't want to care about legacy
> encoding at all.
Windows Terminal isn't relevant to the encoding issue. Applications interact
with the conso
Eryk Sun added the comment:
You resolved bpo-41299 using QueryPerformanceCounter(), so we're already a step
toward making it the default monotonic clock. Personally, I've only relied on
QPC for short intervals, but, as you've highlighted above, other language
runtimes u
Eryk Sun added the comment:
> 2. Execute 'set TZ=Europe/Moscow'
The Windows C runtime supports a simple format for the TZ environment variable,
which is detailed in the documentation of _tzset() [1]. For example, it's
"MSK-3" for Moscow Standard Time. It
Eryk Sun added the comment:
Note that this explanation in your commit is wrong and unhelpful: "likely
because datetime.datetime.now in the native Windows Python takes into account
both system timezone data and the TZ environment variable". When TZ is set,
localtime() is based only
Eryk Sun added the comment:
> single dots are collapsed
For pathlib, I've previously discussed a desire to retain a leading dot
component from the initializing path. This could be implemented in strict mode
for normpath().
A leading dot is significant in the path of an executa
Eryk Sun added the comment:
> What are the expected benefits from changing? Just a higher
> resolution? I'm not sure that's worth anything if it's inaccurate.
GetSystemTimePreciseAsFileTime() returns an accurate timestamp, which is the
current system time plus the d
Eryk Sun added the comment:
On second thought, starting with Windows 8, WaitForSingleObject() and
WaitForMultipleObjects() exclude time when the system is suspended. For
consistency, an external deadline (e.g. for SIGINT support) should work the
same way. The monotonic clock should thus be
Eryk Sun added the comment:
I think separate keep_curdir and keep_pardir options is over-complicating the
signature. Also, I'd prefer to remove a dot component if it's not the first
component since there's no reason to keep it.
If you plan to use normpath() in pathlib, th
Eryk Sun added the comment:
> Seems like Windows 7 may need to be considered as well, as
> per vstinner's bpo-32592 mention?
Python 3.9 doesn't support Windows 7. Moreover, the interpreter DLL in 3.9
implicitly imports PathCchCanonicalizeEx, PathCchCombineEx, and
PathCc
Eryk Sun added the comment:
>> Try changing EnterNonRecursiveMutex() to break out of the loop in
>> this case
>
> This does work, but unfortunately a little too well - in a single
> test I saw several instances where that approach returned
> _earlier_ than the timeou
Eryk Sun added the comment:
> Would it be safe to close the handle just after PyThread_start_new_thread()
> success?
We already close the handle in PyThread_start_new_thread() in
Python/thread_nt.h:
if (hThread == 0) {
// ...
}
else {
dprintf
Eryk Sun added the comment:
Yes, this issue is out of date. shutil._rmtree_isdir() and
shutil._rmtree_islink() were added to handle mount points (i.e. junctions) as
if they're symlinks.
More generally, junctions and symlinks are what the platform refers to as
name-surrogate reparse p
Eryk Sun added the comment:
> On Windows we currently still default to your console encoding
In Windows, the default encoding for open() is the ANSI code page of the
current process [1], from GetACP(), which is based on the system locale, unless
it's overridden to UTF-8 in the app
Eryk Sun added the comment:
> I was thinking about about a case where paths are resolved relative
> to a container root in a filesystem.
I can see the need for generalized 'drive' support that sets an arbitrary path
prefix as the 'drive'. For example, if "
Change by Eryk Sun :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> subprocess.run() sometimes ignores timeout in Windows
___
Python tracker
<https://bugs.python
Eryk Sun added the comment:
The secure CRT string functions such as wcscpy_s() and wcscat_s() invoke the
invalid parameter handler if the destination string is too small. This defaults
to a fastfail that terminates with the status code 0xC409, subcode 5
(FAST_FAIL_INVALID_ARG).
We&#x
Eryk Sun added the comment:
> In Windows there is an fast API to copy file in kernel mode: CopyFile
The possibility of calling CopyFileEx() for shutil.copy2() is discussed in
issue 30044. Note that CopyFileEx() is a high-level Windows API function, not a
"kernel mode" copy.
Change by Eryk Sun :
--
components: +Windows -Library (Lib)
___
Python tracker
<https://bugs.python.org/issue44579>
___
___
Python-bugs-list mailing list
Unsub
Eryk Sun added the comment:
By default, reading input from the console uses the console's built-in
command-line editor. You can clear the console input history with Alt+F7;
display the history list with F7; navigate in the history list with the up and
down arrow keys, even when the
Eryk Sun added the comment:
The implementation of time.sleep() uses WaitForSingleObjectEx() on the main
thread. It waits for an event object that gets signaled by Ctrl+C. On other
threads it simply calls Sleep().
Thread wait functions such as WaitForSingleObjectEx() and Sleep() are based
Eryk Sun added the comment:
Currently you can use os.open() if you need platform-specific open flags such
as Windows O_RANDOM, O_SEQUENTIAL, O_SHORT_LIVED, and O_TEMPORARY. The file
descriptor can be passed to builtin open() to get a file object that owns the
fd.
It might be more
Eryk Sun added the comment:
> It certainly wouldn't be worth the power and CPU usage
> impact that people would inevitable get tricked into
> causing
To clarify, only short waits such as time.sleep(0.001) would busy loop. Waits
longer than say 50 ms would call WaitForSingl
Eryk Sun added the comment:
> When the check incorrectly infers that it can use `msvcrt` while
> its stdin is a pipe, the calls to `putwch` and `getwch` are going
> into the void and the program effectively freezes waiting for
> input that never comes.
The C runtime's ge
Eryk Sun added the comment:
It should be noted that changing win_getpass() to check sys.stdin.isatty()
makes it inconsistent with unix_getpass(). The latter tries to open "/dev/tty"
regardless of sys.stdin. To be consistent, win_getpass() would be implemented
to call fallback_getp
Eryk Sun added the comment:
> We could also provide a better check in WindowsConsoleIO.isatty,
For isatty(), my concern is a false positive if the file is the "NUL" device,
which should be an io.FileIO object. I suppose checking the file type in
io._WindowsConsoleIO.isat
Eryk Sun added the comment:
> WindowsConsoleIO doesn't actually use the standard file descriptors
> for stdin/out/err
To resolve bpo-30555, _WindowsConsoleIO was changed to eliminate self->handle
and get the underlying handle dynamically via _get_osfhandle(). It's thus
s
Eryk Sun added the comment:
MinGW Python sets os.sep to "/" and os.altsep to "\\". It also swaps
_WindowsFlavour.sep and _WindowsFlavour.altsep in pathlib. This seems dubious
to me. Technically the Windows API supports both backslash and slash as path
separators, but
Eryk Sun added the comment:
I'd prefer a generic wording regarding the platform, and overall simpler
phrasing without examples: "On some platforms, it may also be raised if an
operation attempts to open or traverse a non-directory file as if it were a
directory."
The latte
Eryk Sun added the comment:
> It should be emphasized that it may happen on a **file operation**
I think it's adequately covered by "attempts to open or traverse a
non-directory file". The reader should know that opening
"/path/to/file/somename.txt" requires trav
Eryk Sun added the comment:
> On MacOS, I get Not a directory error on all 3
Confirmation on Linux and macOS suffices for "most POSIX systems", based on
market share for desktops and servers. It would be nice to also confirm this
for FreeBSD, AIX, HP-UX, and Solaris, but I sup
Change by Eryk Sun :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type: -> behavior
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issu
Eryk Sun added the comment:
It should also ignore ERROR_BAD_NETPATH (53).
--
nosy: +eryksun
___
Python tracker
<https://bugs.python.org/issue44817>
___
___
Pytho
Eryk Sun added the comment:
In zoneinfo._tzpath, _validate_tzfile_path() depends on os.path.normpath(). I
think the Windows implementation of normpath() in the ntpath module should be
extended to normalize reserved names in the final path component in the same
manner as WinAPI
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg398916
___
Python tracker
<https://bugs.python.org/issue44829>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
ERROR_NETWORK_ACCESS_DENIED (65) should probably be added to the ignore list. I
don't know whether it occurs in practice, but we have it mapped to EACCES in
PC/errmap.h. The common access error is ERROR_ACCESS_DENIED (5), even on a UNC
share with restr
Eryk Sun added the comment:
The `sys.stdin is not sys.__stdin__` check is not relevant information. We need
to know whether msvcrt.getwch() works and that the user should be able to type
the password in the console window. sys.__stdin__ could be a file object for
the NUL device, a pipe, or
Eryk Sun added the comment:
In 3.2, the default program name on non-Windows systems was changed to
"python3" (see bpo-15020). In 3.5, the code was moved into Python/pylifecycle.c
(see bpo-22869). Between 3.7 and 3.8, the initialization code was rewritten
(see PEP 587). Currently i
Eryk Sun added the comment:
> I don't understand the wording proposed (that seem backwards to me?)
Thanks. Looks like I inverted the logic of the quoted paragraph. It should have
been a "relative path with a slash in it" is resolved against the current
working directo
Eryk Sun added the comment:
> creating a Windows `os.set_owner` function that uses the
> appropriate Windows API calls to change owner/group settings,
> and then using that for Windows in the `shutil.chown` function?
I'd gladly help with implementing os.set_owner(), as a separ
Eryk Sun added the comment:
> It's doing this now, so seems like it has been fixed
Yes. In POSIX systems since Python 3.7, if the LC_CTYPE locale is the legacy
"C" or "POSIX" locale, by default it tries to coerce LC_CTYPE to "C.UTF-8",
"C.utf8&quo
Eryk Sun added the comment:
The legacy maximum buffer size is 260 characters, but remember that strings in
C are terminated by a null character (i.e. "\0"). So the maximum path length is
actually 259 characters when opening files.
In Windows 10 with Python 3.6+, you can
Eryk Sun added the comment:
The supported range depends on the platform. The C runtime library in Windows
can handle dates through the year 3000 [1]:
>>> datetime.fromtimestamp(3253679)
datetime.datetime(3001, 1, 19, 7, 59, 59)
>>> datetime.fromtim
Eryk Sun added the comment:
The documentation states that "[i]f capture_output is true, stdout and stderr
will be captured". This implies a container of some kind. So look to what
subprocess.run() returns: "[w]ait for command to complete, then return a
CompletedProcess
Eryk Sun added the comment:
> It may be a bug in the constructor of SharedMemory. It ignores
> the size argument on Windows.
The `size` argument is always ignored when `create` is false, on all platforms,
not that I understand the reason for it. The difference compared to POSIX is
th
Eryk Sun added the comment:
I can't directly reproduce the problem. Does it reproduce reliably for you? My
guess would be that there's a file open in "cpython-source-deps-zlib-1.2.11"
when get_external.py tries to rename it to "zlib-1.2.11". Maybe an anti-malwa
Eryk Sun added the comment:
A literal backlash has to be escaped by doubling it if it precedes a double
quote, else it escapes the double quote character. This is how typical
command-line argument parsing handles backslash in Windows [1]:
* 2n backslashes followed by a quotation mark
Eryk Sun added the comment:
See bpo-26903 for a similar problem in concurrent.futures.ProcessPoolExecutor.
It was resolved by adding a limit constant, _MAX_WINDOWS_WORKERS == 61.
WaitForMultipleObjects() can wait on up to 64 object handles, but in this case
3 slots are already taken. The
Eryk Sun added the comment:
AFAICT, there is no bug here. It's just confusing how Unicode right-to-left
characters in the repr() can modify how it's displayed in the console/terminal.
Use the ascii() representation to avoid the problem.
> The same behavior does not occur when d
Eryk Sun added the comment:
> I think you may be mistaken. In Max's original post, he has
> s = '000X'
It displays that way for me under Firefox in Linux, but what's really there
when I copy it from Firefox is '0\U000109', which matches the r
Eryk Sun added the comment:
In Windows, the standard I/O encoding of the spawn_python() child defaults to
the process active code page, i.e. GetACP(). In Windows 10, the active code
page can be set to UTF-8 at the system or application level, but most systems
and applications still use a
Eryk Sun added the comment:
> FWIW, I did test with "-X utf8" option
I was suggesting to modify the tests to use the UTF-8 mode option in the
spawn_python() command line. It doesn't help to run the parent process in UTF-8
mode since it isn't inherited. It could be i
Eryk Sun added the comment:
> in CP1252, bytes \x81 \x8d \x8f \x90 \x9d map to "UNDEFINED",
> whereas in bestfit1252, they map to \u0081 \u008d \u008f
> \u0090 \u009d respectively
This is the normal mapping in Windows, not a best-fit encoding. Within Windows,
you ca
Eryk Sun added the comment:
> From Eryk's description it sounds like we should always add
> WC_NO_BEST_FIT_CHARS as an option to MultiByteToWideChar()
> in order to make sure it doesn't use best fit variants
> unless explicitly requested.
The concept of a "best fi
Eryk Sun added the comment:
Python 3.7+ doesn't need to explicitly enable UTF-8 mode in this case on POSIX
systems. If the locale encoding is the "POSIX" or "C" locale, and "C" locale
coercion is not disabled via LC_ALL or PYTHONCOERCECLOCALE=0, the interp
Eryk Sun added the comment:
Rafael, I was discussing code_page_decode() and code_page_encode() both as an
alternative for compatibility with other programs and also to explore how
MultiByteToWideChar() and WideCharToMultiByte() work -- particularly to explain
best-fit mappings, which do not
Eryk Sun added the comment:
In Windows, the C runtime's append mode doesn't use the native file append
mode. The CRT just opens the file in read-write mode and seeks to the end,
initially and before each write.
subprocess.Popen() doesn't implement inheritance of file desc
Change by Eryk Sun :
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue45234>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eryk Sun added the comment:
There's nothing we could easily change to use the native OS append mode or
support inheritance of file descriptors in subprocess. A general solution would
be to give up on C file descriptors and CRT functions such as _wopen(), read(),
etc, and instead impl
Eryk Sun added the comment:
I see no problem with changing a test -- such as
test_consistent_sys_path_for_direct_execution() -- to spawn the child
interpreter with `-X utf8` when the I/O encoding itself is irrelevant to the
test -- except for forcing a common Unicode encoding to ensure the
Eryk Sun added the comment:
See bpo-21822 from 2014, which I think was the first report of this issue.
--
nosy: +eryksun
___
Python tracker
<https://bugs.python.org/issue45
Change by Eryk Sun :
--
nosy: +eryksun
___
Python tracker
<https://bugs.python.org/issue45274>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eryk Sun added the comment:
A simple ctypes type implements a get function that's called when its value is
returned as an attribute of struct/union, index of an array/pointer, or result
of a function pointer. For example:
>>> a = (ctypes.c_char * 1)(97)
>>> a
Eryk Sun added the comment:
Running the REPL with -S is unusual, so having to use sys.exit() or `raise
SystemExit` in that case shouldn't be an issue.
A user who wants custom behavior for `exit` could override sys.displayhook() in
the PYTHONSTARTUP file. For example:
impor
Eryk Sun added the comment:
This is the same as bpo-21822, so I suppose it should be closed as well with a
reference to this issue.
--
___
Python tracker
<https://bugs.python.org/issue45
Eryk Sun added the comment:
> IMO it's time to remove _PY_EMULATED_WIN_CV code path from
> pycore_condvar.h.
SleepConditionVariableSRW() can't be interrupted in PyCOND_WAIT() and
PyCOND_TIMEDWAIT(). Maybe a hybrid solution could be adopted. Use native
condition varia
Eryk Sun added the comment:
FYI, waiting for a condition variable can cause a thread to enter a wait state
that's interruptible, in theory, but the mechanism is different since condition
variables and SRW locks are pointer-sized values in user space, instead of NT
objects in kernel
Eryk Sun added the comment:
> This will be the change to make "special" filenames only be
> special when used on their own, and not as part of a path
For some reason, Windows 11 still reserves case-insensitive "nul" in qualified
paths, but none of the other DOS dev
Eryk Sun added the comment:
The _WIN32_CLIENT_RELEASES table based on major.minor version number isn't
helpful since Windows 10 and 11 have the same version number. win32_ver() needs
a workaround to return release "11" if the build number is 22000 or greater. Is
there any
Eryk Sun added the comment:
I left a message on the PR a day ago about a one-off error in the allocation of
`buff`. The size should be `MAXPATHLEN + 1`. That's what's used everywhere else
in PC/getpathp.c and what gets passed in the PathCchCombineEx(buff, MAXPATHLEN
+ 1,
Eryk Sun added the comment:
> use the build number as reference instead of the major.minor
It could check the (major, minor, build) tuple, which allows reporting 10.1+ as
"post11" and minimizes hard coding of build numbers. For example, given
win32_ver() iterates by (major,
Eryk Sun added the comment:
> In Python 3.11, time.sleep() is now always implemented with a
> waitable timer.
A regular waitable timer in Windows becomes signaled with the same resolution
as Sleep(). It's based on the current interrupt timer period, which can be
lowered
Eryk Sun added the comment:
> Is there any benefit of calling SetWaitableTimer() with an
> absolute timeout
No, the due time of a timer object is stored in absolute interrupt time, not
absolute system time. This has to be calculated either way, and it's actually
more work for th
Eryk Sun added the comment:
> Absolute timeout using can reduce the overhead time of any variable
> and object intialization cost before the WaitForMultipleObjects()
Again, timer objects store the due time in interrupt time, not system time
(i.e. InterruptTime vs SystemTime
Eryk Sun added the comment:
It's up to the core devs whether or not Python should try to use a
high-resolution timer, which is currently undocumented in the Windows API and
implemented only in recent releases of Windows 10 and 11. But if this does get
supported, the code should fall ba
Eryk Sun added the comment:
This tracker is for issues with the Python language and standard library. You
can ask for help with configuration problems on the Users discussion forum:
https://discuss.python.org/c/users/7
--
nosy: +eryksun
resolution: -> not a bug
stage: -> re
Eryk Sun added the comment:
The force_hide option could also force the use of a new hidden window, even if
the current process has a console. That way the output is always hidden. For
example:
if force_hide or shell:
if force_hide and not (creationflags
Eryk Sun added the comment:
I was intending force_no_window as an alternative to adding force_hide, since
CREATE_NO_WINDOW only affects console applications. Maybe a better name is
force_hide_console.
--
___
Python tracker
<ht
Eryk Sun added the comment:
> IMO, this makes it the 'system' Python.
"App Paths" entries can be used like versioned symlinks in POSIX. For example,
an "App Paths" entry for "python3.exe" can refer to a particular installation's
"python.e
Eryk Sun added the comment:
> # I thought this would have to be 16, i.e. a path length over 4096, PATH_MAX
> # but seemingly just crossing 1050 is enough to fail
If os.pathconf() and PC_PATH_MAX are supported, the maximum allowed length of
an absolute path is os.pa
Eryk Sun added the comment:
Sorry, I seem to have missed your post last month when I scanned over the
thread on python-ideas [1].
In POSIX, it could try to handle ENAMETOOLONG by walking the path forward with
a relative chdir(). This could try to consume as many components as possible in
Eryk Sun added the comment:
This is from checking whether the \\?\ prefix can be stripped. The
_getfinalpathname() call that it makes fails with the initial winerror
(ERROR_PATH_NOT_FOUND), since nt._getfinalpathname() still lacks support for
volume GUID paths. In this case, it assumes the
Eryk Sun added the comment:
The os.environ description appears to be worded as the "string environment" in
contrast to the os.environb "environment as byte strings". I like the emphasis
on the "process environment". How about "A mapping object of key an
Eryk Sun added the comment:
The pip package installer is not part of Python's standard library. Issues with
pip should be reported at the following site:
https://github.com/pypa/pip/issues
Note that pip 20.0+ automatically switches to a --user installation if the user
lacks the req
Eryk Sun added the comment:
> but I'm interrested in knowing more about the issue/original cause.
When the readline module is imported in interactive mode, the
PyOS_ReadlineFunctionPointer function pointer is set to call_readline(), which
uses GNU Readline. Otherwise PyOS_Readline
Eryk Sun added the comment:
> Alternatively, can't we just os.chdir(self._old_cwd) in __enter__ and
> preemptively fail?
If the context manager isn't going to address the long-path case reliably using
either a file-descriptor approach or repeated relative chdir() call
Eryk Sun added the comment:
> '\r' is not handled, though it is documented that it
> should be supported.
Where is it documented that sys.stdin uses universal newlines mode? The newline
behavior isn't documented in the sys module [1], though it should be. It's h
Eryk Sun added the comment:
> like those returned by the open() function. Their parameters are
> chosen as follows..."
The `newline` argument for sys.std* isn't documented, but it should be. It
happens to be newline='\n' on every platform except Windows.
> its
Eryk Sun added the comment:
> What is the most trivial way to test it's behaviour?
With CREATE_NO_WINDOW, the child process is attached to a console that has no
window. Thus calling GetConsoleWindow() in the child returns NULL without an
error. OTOH, if the child has no cons
Eryk Sun added the comment:
> is it feasible to just have one option that handles all cases?
I'm in favor of whatever has broad support and is least surprising for users. I
like CREATE_NO_WINDOW, which is restricted to console applications. The
alternative is hiding the window, like
Eryk Sun added the comment:
If only force_hide is implemented, based on `wShowWindow=SW_HIDE`, please
ensure that it's clearly documented that this option hides the main window
(i.e. first top-level window) of any application that doesn't bypass the
default behavior of the wind
Eryk Sun added the comment:
> There's nothing gained by complicating this API with more options.
Yes, both options is too much. I suggested force_hide_console as an alternative
to force_hide, not for both to be implemented. It would be the same as
CreateNoWindow in .NET ProcessStar
Eryk Sun added the comment:
In theory, a crash could be prevented in most cases by setting a larger stack
guarantee (i.e. region of guard pages) via SetThreadStackGuarantee() [1] and
using a vectored exception handler [2]. The exception handler can set a flag in
the thread state that
Eryk Sun added the comment:
Here's an example test that calls WinAPI GetConsoleWindow() and
IsWindowVisble() in a child process.
if mswindows:
try:
import ctypes
except ImportError:
ctypes = None
# added in Win32ProcessTestCase
501 - 600 of 2119 matches
Mail list logo
