[issue42902] a python embedded program may load "C:\Lib\os.py" on windows system

Eryk Sun added the comment: > I still don't understand if the issue involves Py_SetPath() or not. It seems to me that this issue is concerned with the default behavior that looks for the "lib/os.py" landmark via search_for_prefix() in PC/getpathp.c. Starting at the image path

[issue42876] '''"""''' != '""""'

Eryk Sun added the comment: > assert '''"""''' == '""""' # Fails The left-hand side is a triple-quote string literal [1][2] that contains 3 double-quote characters. The right-hand side is a single-quote string literal that contains 4 double-quote

[issue42872] Inconsistent exceptions thrown by pathlib.Path.mkdir on different OSes

Eryk Sun added the comment: NT filesystems are specified to fail with STATUS_OBJECT_PATH_NOT_FOUND (0xC03A) if a parent component in a path either does not exist or is not a directory. In the Windows API, this translates to ERROR_PATH_NOT_FOUND (3), which in the C runtime translates

[issue42855] pathlib.exists on Windows raises an exception on URL like/bad input

Eryk Sun added the comment: An alternative would be to add a "strict" parameter that defaults to False. In non-strict mode, map all OSError exceptions to a False return value. In strict mode, use _ignore_error(e) to determine whether to return False or propagate the exception. Th

[issue42855] pathlib.exists on Windows raises an exception on URL like/bad input

Eryk Sun added the comment: > "http:" isn't a valid drive letter, I'd imagine. It's not a valid DOS drive, but that's not the problem. "http://w.org; is parsed as a relative path. The double slashes are replaced by a single backslash, and the Windows API tries to open

[issue30044] shutil.copystat should (allow to) copy ownership, and other attributes

Eryk Sun added the comment: > For Windows though, I'm unsure. If copystat() gains the ability to copy the file's owner and group in POSIX, it is not a priority to mirror this capability in Windows, which doesn't implement anything like the Unix owner-group-other permission model. The o

[issue42796] tempfile doesn't seem to play nicely with os.chdir on Windows

Eryk Sun added the comment: > def test_chdir(): > with tempfile.TemporaryDirectory() as tempdir: > old = os.getcwd() > os.chdir(tempdir) > with open(os.path.join(tempdir, "delme")) as fout: > fout.write("Hello") &g

[issue42796] tempfile doesn't seem to play nicely with os.chdir on Windows

Eryk Sun added the comment: > Windows doesn't let you remove files and directories that are used > by a process. Windows does allow deleting open files/directories, but read/execute, write/append, and delete/rename access have to be explicitly shared when opening a file or dir

[issue42658] os.path.normcase() is inconsistent with Windows file system

Eryk Sun added the comment: > "lowercase two strings by means of LCMapStringEx() and then wcscmp > the two" always gives the same result as "compare the two strings > with CompareStringOrdinal()" For checking case-insensitive equality, it shouldn't matter

[issue42771] Implement interactive hotkey, Ctrl+L to clear the console in Windows.

Eryk Sun added the comment: > As the legacy cmd.exe can be easily replaced, that leaves python.exe. python.exe is a console application, which attaches to a console session. Since Windows 7, each console session is hosted by an instance of conhost.exe. The CMD shell (cmd.exe) is a cons

[issue42738] subprocess: don't close all file descriptors by default (close_fds=False)

Eryk Sun added the comment: > Python 3.7 added the support for the PROC_THREAD_ATTRIBUTE_HANDLE_LIST > in subprocess.STARTUPINFO: lpAttributeList['handle_list'] parameter. The motivating reason to add support for the WinAPI handle list was to allow changing the default to close_fd

[issue42730] TypeError/hang inside of Time.Sleep() when _thread.interrupt_main()

Eryk Sun added the comment: When a process executes in the background from a non-interactive bash script, the initial handler for SIGINT is SIG_IGN (ignore). Prior to 3.7, _thread.interrupt_main() tries to trip SIGINT even when the C handler is set to SIG_IGN. But Python uses an integer

[issue42707] Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP

Eryk Sun added the comment: > When there is no console, stdio should use the default textio > encoding that is ANSI for now. stdin, stdout, and stderr are special and can be special cased because they're used implicitly for IPC. They've always been acknowledged as special by the exi

[issue42707] Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP

Eryk Sun added the comment: > How about treating only UTF-8 and leave legacy environment as-is? > * When GetConsoleCP() returns CP_UTF8, use UTF-8 for stdin. > Otherwise, use ANSI. Okay, and also when GetConsoleCP() fails because there's no console (e.g. python.exe w/ DETACHE

[issue42707] Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP

Eryk Sun added the comment: > I understand Python should be using reading the current CP (from > GetConsoleOutputCP > or using the default OEM CP, and not assuming ANSI CP for stdio A while ago I analyzed text encodings used by many of the legacy CLI programs in Windows. Some prog

[issue42529] CPython DLL initialization routine failed from PYC cache file

Eryk Sun added the comment: I built JPype normally in release mode and was able to analyze the problem using the platform debugger (cdb or WinDbg). I think the issue is pretty straight forward. The static initializer for classMagic in "native\python\pyjp_class.cpp" is calling

[issue42529] CPython DLL initialization routine failed from PYC cache file

Eryk Sun added the comment: > ImportError: DLL load failed while importing _jpype: > A dynamic link library (DLL) initialization routine failed. With loader snaps enabled for python[_d].exe (i.e. loader debug messages), you can attach a debugger to discover which DLL's init r

[issue42648] subprocess: add a helper/parameter to catch exec() OSError exception

Eryk Sun added the comment: I suggesting changing the name to indicate that only OSError exceptions are suppressed, not SubprocessError exceptions. Maybe call it no_oserror. As to the status code to use, if you want a a common code that can't interfere, it has to be either a negative value

[issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks

Eryk Sun added the comment: > To implement PEP 446: create non-inheritable file descriptors. Side note. That aspect is still wonky in Windows, for which set_inheritable() cannot be implemented reliably since there's no way to change whether an existing CRT file descriptor is inherita

[issue42568] Python can't run .pyc files with non-ASCII path on Windows

Change by Eryk Sun : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Python 3.6 cannot reopen .pyc file with non-ASCII path ___ Python tracker <https://bugs.python

[issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path

Change by Eryk Sun : -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue32381> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23946] Invalid timestamps reported by os.stat() when Windows FILETIME structures are mistakenly reset.

Eryk Sun added the comment: > The code of posixmodule.c looks very different now. The conversion code was moved to FILE_TIME_to_time_t_nsec() in Python/fileutils.c. time_t is a signed 64-bit integer type, so there's no immediate problem storing 1601-01-01 as the negative (pre-epoch) U

[issue42518] Error Message

Change by Eryk Sun : -- components: -Windows ___ Python tracker <https://bugs.python.org/issue42518> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42518] Error Message

Change by Eryk Sun : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue42518> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue42481] Add to pathlib function to check permission similar to os.access

Eryk Sun added the comment: > takes extended file attributes like immutable bit Just to clarify, immutable isn't an extended attribute. It's one of the flag values in a Linux inode, which is supported by some filesystems such as ext4. It's in the API as STATX_ATTR_IMMUTABLE from the st

[issue42497] New pathlib.Path attribute

Change by Eryk Sun : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Add to pathlib function to check permission similar to os.access ___ Python tracker <https://bugs.python

[issue42499] python not correctly processing double quotes in command line args in windows

Eryk Sun added the comment: Python uses the Windows C runtime to parse the command line into an argument array. By the CRT rules [1], you need to escape the embedded double quotes using backslashes. For example: PS C:\> python -c 's = \"fn main() {\"; s += \"\n\

[issue42493] pathlib.Path.__eq__ should test normalized path

Change by Eryk Sun : -- resolution: -> rejected type: behavior -> enhancement ___ Python tracker <https://bugs.python.org/issue42493> ___ ___ Python-bugs-

[issue42493] pathlib.Path.__eq__ should test normalized path

Eryk Sun added the comment: The __eq__ method would have to do a full resolve(), which is expensive and may fail. One can't simply resolve "/foo/symlink/.." as "/foo", where "symlink" is a filesystem symlink. The target has to be resolved before "

[issue42481] Add to pathlib function to check permission similar to os.access

Eryk Sun added the comment: > os.access() is not a good and sufficient permission check. It > only checks DAC (discrete access control) permissions That's interesting. In Linux, for example, I would expect the access() and faccessat() system calls to also check mandatory permissi

[issue42441] UnicodeEncodeError

Eryk Sun added the comment: The default encoding for files in Windows is the process active code page, which defaults to the system code page, e.g. code page 1252 if the system locale is "en-IN". You need to explicitly use a Unicode encoding such as UTF-8 when opening the file,

[issue42438] Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding

Change by Eryk Sun : -- stage: backport needed -> resolved ___ Python tracker <https://bugs.python.org/issue42438> ___ ___ Python-bugs-list mailing list Un

[issue42438] Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding

Eryk Sun added the comment: > I reinstalled python from 3.8.2 to 3.9 Going from 3.8 to 3.9 is not an in-place upgrade. You need to create a new virtual environment that references the base 3.9 installation. -- nosy: +eryksun resolution: -> not a bug stage: -> backpo

[issue42421] Native open failed to create a file on windows10 when colon exists in the name

Eryk Sun added the comment: > 'FocalMix: Semi-Supervised Learning for 3D Medical Image Detection.pdf' In a filesystem that supports file streams [1], such as NTFS or ReFS, the above name refers to a $DATA stream named " Semi-Supervised Learning for 3D Medical Image Detection.pdf&qu

[issue42397] lstrip 处理出现bug

Eryk Sun added the comment: Python 3.9 added str.removeprefix() and str.removesuffix() [1]: >>> "data_prj_t_suffix".removeprefix('data_prj_').removesuffix('_suffix') 't' [1] https://docs.python.org/3/library/stdtypes.html#str.removeprefix --

[issue15263] Guard against invalid file handles in os functions

Eryk Sun added the comment: > I don't see any _Py_VerifyFd in the code, is this out of date? Yes, this issue is out of date. The underlying issue is that the C runtime in Windows automatically checks various parameters and calls a registered handler for invalid parameters, for wh

[issue10854] Output .pyd name in error message of ImportError when DLL load fails

Eryk Sun added the comment: > The patch adding 'name' and 'path' to the ImportError str/repr > was not merged yet. It's up to whatever code raises an ImportError to determine how the name and path should be included in the error message. In Windows, the DLL name was added to the exc

[issue12726] explain that locale.getlocale() does not read system's locales

Eryk Sun added the comment: > I tried "import locale; locale.getlocale()" on macOS and > windows (3.10) and linux (3.7) and in all cases I got > non-None values. In Windows, starting with Python 3.8, Python sets the LC_CTYPE locale to the user (not system) def

[issue42178] failed pickle hangs python on exit in CMD.exe only

Eryk Sun added the comment: Steve or Zach, please review PR 23290, submitted by Teugea Ioan-Teodor. It modifies the startup sequence for worker processes by creating the child process with a suspended thread and pickling process_obj to a BytesIO instance before resuming the thread

[issue42178] failed pickle hangs python on exit in CMD.exe only

Change by Eryk Sun : -- nosy: +davin, pitrou ___ Python tracker <https://bugs.python.org/issue42178> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42339] official embedded Python fails to import certain modules

Eryk Sun added the comment: > maybe there's a list of updates (or FAQ) to which you > want to add KB3063858? The documentation of the embeddable package [1] could highlight the need for KB2533623. Currently it's directly mentioned only in "What's New in Python 3.8" [2]. &g

[issue37205] time.perf_counter() is not system-wide on Windows, in disagreement with documentation

Eryk Sun added the comment: > QPC typically has a frequency of 1e7, Never mind. Apparently with some combinations of chipset, processor, and Windows version, the QPC frequency runs far beyond the 1-10 MHz range. I thought Windows divided by 1024 instead of letting it run in the GHz ra

[issue37205] time.perf_counter() is not system-wide on Windows, in disagreement with documentation

Eryk Sun added the comment: > suggest to use time.perf_counter_ns() instead of time.perf_counter() > for best precision. QPC typically has a frequency of 1e7, which requires 24 bits for the fraction of a second. So a system can be up for years before the 53-bit precision of a

[issue42296] Infinite loop uninterruptable on Windows in 3.10

Change by Eryk Sun : -- priority: release blocker -> stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42296> ___ ___

[issue42296] Infinite loop uninterruptable on Windows in 3.10

Eryk Sun added the comment: > That sounds like a micro-optimization which is not worth it. In the back of my mind I was also thinking to generalize the behavior at runtime whenever a signal is tripped by a non-Python thread (e.g. a thread created by an extension module or ctypes), inst

[issue42296] Infinite loop uninterruptable on Windows in 3.10

Eryk Sun added the comment: > always interrupt and let the thread decide if it has something to do. SIGNAL_PENDING_CALLS() is called on a Python thread via signal.raise_signal() or _thread.interrupt_main() / PyErr_SetInterrupt(). If you'd rather keep the COMPUTE_EVAL_BREAKER() c

[issue42296] Infinite loop uninterruptable on Windows in 3.10

Eryk Sun added the comment: Note that this issue only applies to a process that has a single Python thread. With multiple Python threads, the signal handler gets called when the main thread acquires the GIL. As far as Windows console-driven SIGINT and SIGBREAK are concerned, C

[issue42311] It seems like ctypes code makes truncated pointer values in x64(access violations)

Eryk Sun added the comment: A function that returns a pointer needs an explicit `restype` set. A function parameter that's a pointer generally requires `argtypes` to be set. For example: _testdll.GetPointer.restype = ctypes.c_void_p _testdll.SetPointer.argtypes = (ctypes.c_void_p

[issue42296] Infinite loop uninterruptable on Windows in 3.10

Eryk Sun added the comment: Yes, if I force the return value of _Py_ThreadCanHandleSignals to 1, the loop is broken by a KeyboardInterrupt. -- ___ Python tracker <https://bugs.python.org/issue42

[issue42296] Infinite loop uninterruptable on Windows in 3.10

Eryk Sun added the comment: See bpo-40010. COMPUTE_EVAL_BREAKER() in Python/ceval.c -- or _Py_ThreadCanHandleSignals in Include/internal/pycore_pystate.h -- needs to take into account that SIGNAL_PENDING_SIGNALS() gets called on a completely new thread in Windows

[issue42296] Infinite loop uninterruptable on Windows in 3.10

Change by Eryk Sun : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue42296> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42296] Infinite loop uninterruptable on Windows in 3.10

Eryk Sun added the comment: It also cannot be interrupted in 3.9. But 3.8 and earlier work correctly. -- nosy: +eryksun type: -> behavior versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issu

[issue42293] Installation of pyinstaller in Windows fails with utf8 error

Eryk Sun added the comment: This looks to be a bug in the constructor of pip's BuildEnvironment class: https://github.com/pypa/pip/blob/a4f4bfbf8ba7fd1e60884a439907e3f2a32e117a/src/pip/_internal/build_env.py#L82 Python 3 source files are UTF-8 by default, but text files default

[issue42261] Windows legacy I/O mode mistakenly ignores the device encoding

Eryk Sun added the comment: > It would be nice to get an unit test for this case. The process code page from GetACP() is either an ANSI code page or CP_UTF8 (65001). It should never be a Western OEM code page such as 850. In that case, a reliable unit test would check that the configu

[issue42261] Windows legacy I/O mode mistakenly ignores the device encoding

Eryk Sun added the comment: > The solution here is to fix config_init_stdio_encoding() to use > GetConsoleCP() and GetConsoleOutputCP() to build a "cpXXX" string. But, as I mentioned, that's only possible by replacing config->stdio_encoding with three separa

[issue42261] Windows legacy I/O mode mistakenly ignores the device encoding

Eryk Sun added the comment: There's a related issue that affects opening duplicated file descriptors and opening "CON", "CONIN$", and "CONOUT$" in legacy I/O mode, but this case has always been broken. For Windows, _Py_device_encoding needs to be gene

[issue42261] Windows legacy I/O mode mistakenly ignores the device encoding

New submission from Eryk Sun : In Python 3.8+, legacy standard I/O mode uses the process code page from GetACP instead of the correct device encoding from GetConsoleCP and GetConsoleOutputCP. For example: C:\>chcp 850 Active code page: 850 C:\>set PYTHONLEGACYWINDOWSS

[issue42252] Embeddable Python indicates that it uses PYTHONPATH

Eryk Sun added the comment: The embeddable distribution isn't intended for end users to run Python scripts from the command line, so I don't think the CLI help needs to be special cased. The documentation you quoted should be clarified as something like "isolated from user and system P

[issue42196] Python Windows Installation Error 0x800705aa

Eryk Sun added the comment: 0x8007_05AA is ERROR_NO_SYSTEM_RESOURCES (1450, 0x05AA) returned as an HRESULT value. This error is usually due to a system call failing with the status code STATUS_INSUFFICIENT_RESOURCES. From "Pyhon39InstallLog.txt", apparently the installer failed

[issue42178] failed pickle hangs python on exit in CMD.exe only

Eryk Sun added the comment: Due to the exception raised when trying to pickle main..dummy in popen_spawn_win32.Popen(), the main process may have already exited by the time the spawned worker calls WinAPI OpenProcess in spawn.spawn_main(). I suppose the reduction of prep_data

[issue42175] long lines from interactive stdin are truncated

Eryk Sun added the comment: For Windows see issue 41849. The legacy limit (i.e. PYTHONLEGACYWINDOWSSTDIO) for reading input via io.FileIO is 8K characters in Windows, but with io._WindowsConsoleIO, it's only 512 characters, which is far too small in general. The legacy implementation

[issue37609] support "UNC" device paths in ntpath.splitdrive

Eryk Sun added the comment: I'm attaching a rewrite of splitdrive() from msg352355. This version uses an internal _next() function to get the indices of the next path component, ignoring repeated separators. It also flattens the nested structure of the previous implementation by adding

[issue42170] splitdrive fails for UNC path with the "\\?\UNC\" prefix.

Change by Eryk Sun : -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> support "UNC" device paths in ntpath.splitdrive ___ Python tracker <https://b

[issue38233] datetime.datetime.fromtimestamp have different behaviour on windows and mac

Change by Eryk Sun : -- resolution: -> duplicate status: open -> closed ___ Python tracker <https://bugs.python.org/issue38233> ___ ___ Python-bugs-list

[issue11646] 2to3: msvcrt.(get|put)ch -> (get|put)wch

Eryk Sun added the comment: The bytes type has supported string methods for a long time now. I don't think there's anything else to do here. msvcrt.getch() is a low-level I/O function like os.read(). It should not be automatically converted to msvcrt.getwch(). Unfortunately the function

[issue25655] Python errors related to failures loading DLL's lack information

Eryk Sun added the comment: Steve, the PR that you pushed has the wrong error and error message. I told Philippe in msg377335 that ctypes raises FileNotFoundError with no error code. For example: >>> try: ctypes.CDLL('spam') ... except OSError as e: err = e ...

[issue41737] Improper NotADirectoryError when opening a file in a fake directory

Eryk Sun added the comment: Regarding documentation, builtin open() and the io and os modules generally do not provide information about platform-specific errors. But documenting the behavior for the NotADirectoryError exception itself may be useful considering it applies to many POSIX

[issue38324] [Windows] test_locale and test__locale failures on Windows

Eryk Sun added the comment: PR 20529 looks good to me. Thank you, Tiago. -- ___ Python tracker <https://bugs.python.org/issue38324> ___ ___ Python-bugs-list m

[issue42041] venv subprocess call to python resolves to wrong interpreter

Eryk Sun added the comment: > My biggest concern with the suggested wording ... is that it > reintroduces the issue with the redirector. I thought I addressed that in second paragraph by recommending sys.executable. It could be emphasized that running "python[x][.y]" is unr

[issue42041] venv subprocess call to python resolves to wrong interpreter

Eryk Sun added the comment: > I'd read it because I'm interested, but that is probably too much detail > for someone who is trying to get something done quickly. I did say that I don't know how much should be documented. I tend to dump a lot of information in issues so that people ca

[issue42041] venv subprocess call to python resolves to wrong interpreter

Eryk Sun added the comment: > For platform semantics, I'd prefer a link to the CreateProcessW docs, > with advice to read about the lpApplicationName parameter with > respect to `executable` and lpCommandLine with respect to `args` > and the platform search semantics. For ex

[issue42041] venv subprocess call to python resolves to wrong interpreter

Eryk Sun added the comment: > You can build a cross-platform wrapper on top of native behaviour > (witness `shutil.which`) but you can't do the opposite. Nothing would prevent adding a parameter to use the platform semantics, if that had been in the design from the outset. Bu

[issue42041] venv subprocess call to python resolves to wrong interpreter

Eryk Sun added the comment: > Also, why would we document the Windows rules, but not the POSIX > rules? They are arguably just as strange to someone who doesn't > know them. POSIX rules are simply to search PATH for the filename as passed, and if it has a slash in it, the path is

[issue42041] venv subprocess call to python resolves to wrong interpreter

Eryk Sun added the comment: > I don't think we should document this level of detail But a lot of it -- most of it -- is also strange behavior that no one would expect without reading about it somewhere. Most users of subprocess.Popen() will never wade through the documentat

[issue42041] venv subprocess call to python resolves to wrong interpreter

Eryk Sun added the comment: I don't know how much should be documented for subprocess.Popen, but here are the details for how searching works with shell=False (default) and shell=True. For shell=False, the search path used by WinAPI CreateProcessW checks %__APPDIR__%; %__CD__% (unless

[issue42046] Unable to write to file without elevated privileges

Eryk Sun added the comment: > processtoken = win32security.OpenProcessToken(process, > win32con.MAXIMUM_ALLOWED) > win32security.GetTokenInformation(processtoken, > win32security.TokenMandatoryPolicy) FYI, starting with Windows 8, the system supports pseudo-handles for the a

[issue42046] Unable to write to file without elevated privileges

Eryk Sun added the comment: > icacls.exe C:\Python38-32\python.exe lists Mandatory Label\ > Low Mandatory Level:(I)(NW) ** This might be the problem. Removing "L" > with icacls might work. > > **When a user attempts to launch an executable file, the new process is &

[issue42041] venv subprocess call to python resolves to wrong interpreter

Eryk Sun added the comment: PR 22715 is accurate for the current implementation of subprocess. There has been discussion in past issues about implementing a PATH search that's similar to what the CMD shell does -- as in calling os.system() or Popen() with shell=True -- instead of relying

[issue42044] Running Python in unbuffered mode may not write all contents to the console

Eryk Sun added the comment: Text mode without a buffer isn't reliable. That said, Python 3.9 no longer supports Windows 7, so it can remove the 32 KiB limit on console I/O files. The size limit in Windows 7 and earlier is due to the LPC-based pseudo-files that it uses for I/O. Under

[issue42046] Unable to write to file without elevated privileges

Eryk Sun added the comment: > Desktop rwx, > Username-directory rwx, POSIX permissions are not meaningful in Windows. Please run the following two commands in a Python script in order to show the current user and the access-control list on the directory: import subp

[issue42013] venv on Windows with symlinks is broken if invoked with -I

Eryk Sun added the comment: > So I'm +1 on fixing this by calling realpath. In POSIX, calculate_path() in Modules/getpath.c calls calculate_argv0_path() before it calls calculate_read_pyenv(), and calculate_argv0_path() in turn calls resolve_symlinks(>argv0_path). Thus "pyvenv

[issue42020] interpreter hangs forever on invalid input

Eryk Sun added the comment: In Windows 10 2004, CSI is currently supported by the console host (conhost.exe) if virtual-terminal mode is enabled. Windows Terminal Preview supports many more C1 control codes, as will conhost.exe in the next release of Windows 10. This should be 'fun

[issue42020] interpreter hangs forever on invalid input

Eryk Sun added the comment: The terminal you're using apparently implements C1 controls [1]. U+009B is the Control Sequence Introducer (CSI) for ANSI escape sequences. U+0090 starts a Device Control String (DCS), and it gets terminated by U+009C, a String Terminator (ST). For example

[issue42013] venv on Windows with symlinks is broken if invoked with -I

Eryk Sun added the comment: This issue is partly due to bpo-8901, which changed the behavior of the -E and -I command-line options to make them ignore the default PythonPath value in the registry key "Software\Python\PythonCore\X.Y\PythonPath". The change itself is not wrong.

[issue42013] venv on Windows with symlinks is broken if invoked with -I

Change by Eryk Sun : -- Removed message: https://bugs.python.org/msg378489 ___ Python tracker <https://bugs.python.org/issue42013> ___ ___ Python-bugs-list mailin

[issue42013] venv on Windows with symlinks is broken if invoked with -I

Eryk Sun added the comment: > Well, actually the environment variables /should/ not matter as -I > implies -E. The operative word there is "should". I was grasping for anything that might explain why I couldn't reproduce the issue. > Ok, the missing link is that

[issue42013] venv on Windows with symlinks is broken if invoked with -I

Eryk Sun added the comment: What about the PYTHONHOME and PYTHONPATH environment variables? >>> 'PYTHONHOME' in os.environ False >>> 'PYTHONPATH' in os.environ False PYTHONHOME should not be set all. PYTHONPATH needs to be set carefully. It should neve

[issue42013] venv on Windows with symlinks is broken if invoked with -I

Eryk Sun added the comment: I can't reproduce the issue with the normal 3.9.0 distribution from python.org. For example: >>> venv.EnvBuilder(with_pip=False, symlinks=True).create("venv") >>> subprocess.check_call(["venv\\Scripts\\python.exe", &qu

[issue21927] BOM appears in stdin when using Powershell

Eryk Sun added the comment: I'm closing this as a third-party issue with older versions of PowerShell. Newer versions of PowerShell set the output encoding to UTF-8 without a BOM preamble. For example: PS C:\> $PSVersionTable.PSVersion Major Minor Patch PreReleaseLabel BuildLa

[issue26332] OSError: exception: access violation writing <...> (Windows 10 x64, Python 3.5.1)

Eryk Sun added the comment: I see nothing to act on in this issue. A common cause of access violations with ctypes is truncated pointer values. There's a lot of sloppy ctypes code from the 32-bit era that assumes a C int can store a pointer. -- nosy: +eryksun resolution

[issue41961] Windows install failure "could not set file security"

Eryk Sun added the comment: > It might be that Python is the first/only MSI that the user > has tried though? It's likely the first per-user MSI install attempted since the security of the "Installer" directory was modified. There's no problem with a per-machine install. &

[issue36534] tarfile: handling Windows (path) illegal characters in archive member names

Eryk Sun added the comment: > extract the sanitizing function into a common module > (could be *pathlib*?) to avoid duplicates I would prefer something common, cross-platform, and function-based such as os.path.isreservedname and os.path.sanitizename. In posixpath, it would just

[issue41965] distutils.spawn.find_executable() fails to find .py files on Windows

Eryk Sun added the comment: The existing behavior of find_executable() is unusual compared to a native Windows file search via CreateProcessW or SearchPathW, for which a default ".exe" extension is appended only if the executable name doesn't already have an extension. (Crea

[issue41965] distutils.spawn.find_executable() fails to find .py files on Windows

Eryk Sun added the comment: The linked code runs subprocess.check_output([rstbin, path]), which won't work with "rst2man.py" in Windows. Reliably running a .py script in Windows requires running it explicitly via py[w].exe or python[w].exe, or via sys.executable from an exist

[issue41961] Windows install failure "could not set file security"

Eryk Sun added the comment: > Anyone else know of any possible causes for this? The installer service runs as SYSTEM, with an access token at system integrity level that has full privileges and the administrators group enabled. Nothing in the file security should prevent the service f

[issue36534] tarfile: handling Windows (path) illegal characters in archive member names

Eryk Sun added the comment: > This issue is about tarfile. Maybe create another issue to enhance > the pathlib module? IIRC there's already an open issue for that. But in case anyone were to look to pathlib as an example of what should be reserved, I wanted to highlight here h

[issue36534] tarfile: handling Windows (path) illegal characters in archive member names

Eryk Sun added the comment: > The pathlib module has _WindowsFlavour.reserved_names list of > Windows reserved names: pathlib._WindowsFlavour.reserved_names is missing "CONIN$" and "CONOUT$". Prior to Windows 8 these two are reserved as relative names. In Windows

[issue41941] Py_Initialize affects the console

Eryk Sun added the comment: > config_init_stdio() is not called in an isolated configuration: config_init_stdio wasn't being called anyway since Py_Initialize uses _PyConfig_InitCompatConfig. The issue was primarily due to the LC_CTYPE locale being set to the default user locale, a

[issue41941] Py_Initialize affects the console

Eryk Sun added the comment: Having looked at the screenshots, it seems that your issue is in part due to non-legacy mode not setting the standard I/O files to binary mode (_O_BINARY) from their default ANSI text mode (_O_TEXT). This is not a problem on its own. The real issue

[issue41941] Py_Initialize affects the console

Change by Eryk Sun : -- components: +IO, Unicode, Windows nosy: +ezio.melotti, paul.moore, steve.dower, tim.golden, vstinner, zach.ware ___ Python tracker <https://bugs.python.org/issue41

<    4   5   6   7   8   9   10   11   12   13   >