[issue44540] venv: activate.bat fails for venv with special characters in PATH

Change by Eryk Sun : Added file: https://bugs.python.org/file50484/deactivate.bat ___ Python tracker <https://bugs.python.org/issue44540> ___ ___ Python-bugs-list mailin

[issue23104] [Windows x86-64] ctypes: Incorrect function call

Eryk Sun added the comment: Victor's comment wasn't relevant. objid() stays referenced during the call. Anyway, I just built testlib.c and verified that this ctypes example works correctly in both 64-bit 3.4.4 and 3.10, so the issue is out of date. -- nosy: +eryksun

[issue23104] [Windows x86-64] ctypes: Incorrect function call

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

[issue12142] Reference cycle when importing ctypes

Eryk Sun added the comment: The _ctypes extension module could have a dict that maps each format code to its (size, alignment), based on `formattable`. Then direct size comparisons wouldn't be limited to types defined by the struct module, and it wouldn't be necessary to create c_

[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode

Eryk Sun added the comment: > For example, I would be shocked if it wasn't absolutely trivial > for the current implementation to add auto-indenting following > a colon. That feature alone would be a win for usability. That would be a non-trivial change in Windows. I think

[issue38822] Inconsistent os.stat behavior for directory with Access Denied

Eryk Sun added the comment: In attributes_from_dir() in Modules/posixmodule.c, a trailing backslash or slash should be stripped from the lpFileName parameter of FindFirstFileW. Otherwise the call opens the directory via NtOpenFile, instead of opening its parent directory. Even if opening

[issue38868] Shutil cannot delete a folder that contains an .ini file

Eryk Sun added the comment: What is the system error code (winerror) of the PermissionError? -- nosy: +eryksun ___ Python tracker <https://bugs.python.org/issue38

[issue38748] 32 bit ctypes stdcall callback fails to restore stack pointer

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

[issue38868] Shutil cannot delete a folder that contains an .ini file

Eryk Sun added the comment: The directory probably has the "readonly" attribute set. The documentation includes a basic remove_readonly error handler for rmtree [1]: import os, stat import shutil def remove_readonly(func, path, _): "Clear the r

[issue38906] copy2 doesn't copy metadata on Windows and MacOS

Eryk Sun added the comment: In Windows, using CopyFileExW and CreateDirectoryExW (with a template directory, for copytree) doesn't agree with how shutil implements copying with separate copyfile and copymode/copystat functions. We'd have to extend copyfile() to support alte

[issue38906] copy2 doesn't copy metadata on Windows and MacOS

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

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: > whens searching for executables, Windows gives "exes that are in the > same directory as the currently executing code" priority over PATH. That subprocess lets CreateProcessW use a platform-dependent search that prioritizes the application direc

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: > "running an unqualified python and expecting a PATH search to pick up > the same executable as the parent shell would is not supported and may > produce unexpected results" CreateProcessW finds "python.exe" in __APPDIR__ before it

[issue38890] A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning

Eryk Sun added the comment: For a console application, normally the system connects to either the console that's inherited from the parent or, if no console is inherited, a newly allocated console. The creation flag DETACHED_PROCESS sets the initial console handle in the child to a sp

[issue38890] A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning

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

[issue38890] A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning

Eryk Sun added the comment: > Didn't we clean up this warning completely on Windows recently? It > apparently matters on POSIX to join() the child process, but on > Windows you aren't going to leak any resources by just forgetting > about it, so I thought we stopped

[issue38905] venv python reports wrong sys.executable in a subprocess on Windows

Eryk Sun added the comment: > Possibly we could handle "python[.exe]" literals by substituting > sys.executable transparently? Perhaps generalize this as splitext(basename(sys.executable))[0] in order to support names other than "python" and "pythonw&quo

[issue38906] copy2 doesn't copy metadata on Windows and MacOS

Eryk Sun added the comment: > copystat() and copymode() should be able to copy the same > metadata/security-bits/etc as CopyFileExW. Regarding metadata, CopyFileExW copies the basic file info (i.e. FileAttributes, LastAccessTime, LastWriteTime, and ChangeTime). This metadata can be

[issue31842] pathlib: "Incorrect function" during resolve()

Eryk Sun added the comment: > When strict is "false", pathlib should not fail if the network > share is inaccessible. A redirected filesystem (i.e. a share, whether local or remote) that's physically inaccessible should fail with a FileNotFoundError -- due to unde

[issue38948] os.path.ismount() returns False for current working drive

Eryk Sun added the comment: > The only thing 'F:' can ever be is a mount point. "F:" is a relative path that has to be resolved via abspath() (i.e. GetFullPathNameW in Windows) before we can determine whether it's a mount point. ntpath.ismount handles this corr

[issue38948] os.path.ismount() returns False for current working drive

Eryk Sun added the comment: > So essentially, you say the check should always be "ntpath.isdir(d) I forgot that ntpath.isdir is now genericpath.isdir, so that will work. The old nt._isdir wouldn't work because it was equivalent to an lstat. Apparently a vestigial import

[issue38999] Python launcher on Windows does not detect active venv

Eryk Sun added the comment: I don't think the "/usr/bin/env" case needs to limit qualified names like "python3[.x]" to registered installations. This is a choice made to simplify the implementation. If it finds a generic "python.exe" executable in PATH

[issue38999] Python launcher on Windows does not detect active venv

Eryk Sun added the comment: > I think supporting the shebang line in py.exe is a misfeature and > would prefer we'd never done it (though it predates my involvement). Do you mean all shebangs, including those with a native file path? Or do you mean just virtual shebangs, and in

[issue39051] Python not working on Windows 10

Eryk Sun added the comment: > * PYTHONPATH = 'C:\Developing\Python;C:\Developing\Python\Scripts; > C:\Developing\Python\Lib;C:\Developing\Python\Lib\site-packages; > C:\Developing\Python\DLLs;' FYI, none of this should set here. For a standard configuration, the installati

[issue39099] scandir.dirfd() method

Eryk Sun added the comment: > I am not sure if it's possible to also support Windows. For reference, FindFirstFileW doesn't support handle-relative names, and neither does CreateFileW. At a lower level in Windows NT, NtCreateFile has always supported handle-relative names

[issue39120] pyodbc dll load failed

Eryk Sun added the comment: This may be due to changes regarding DLL dependency resolution in 3.8. If so, you can find the missing DLL using Process Monitor, configured to monitor file access in python.exe and pythonw.exe. Add the DLL's directory to the search path via os.add_dll_dire

[issue39243] CDLL __init__ no longer supports name being passed as None when the handle is not None

Eryk Sun added the comment: I'd like to match POSIX here by supporting path-like names. Also, I think it would be cleaner to split out the platform-specific work into a separate _load_library method, like how subprocess.Popen is designed, and to stop pretending that WINAPI LoadLibrary

[issue39255] Windows and Unix run-time differences

Eryk Sun added the comment: > I am not going to close it as I am unsure if it is by design that > Windows and Unix python acts differently. For compatibility, a script should support the spawn start method. Spawning child processes is the only available start method in Windows, and,

[issue39260] distutils.spawn: find_executable() Fails To Find Many Executables on Windows

Eryk Sun added the comment: > In that the best tactic would be to look in those top-level > directories for a directory with the same name as the executable. It may be a common pattern, but such a guess is not reliable. The needed executable may be in an unrelated directory at an arb

[issue39255] Windows and Unix run-time differences

Eryk Sun added the comment: > Agreed it's not a bug, but I will say it took me a while to work out > *why* it's not a bug (namely, that even though the OP is using shared > memory values, the code relies on fork semantics to share the two > Value objects that *refere

[issue39312] Expose placeholder reparse points in Windows

New submission from Eryk Sun : Windows 10 apparently defaults to disguising placeholder reparse points in python.exe processes, but exposes them to cmd.exe and powershell.exe processes. A common example is a user's OneDrive folder, which extensively uses placeholder reparse points for

[issue39319] ntpath module must not be available on POSIX platforms

Eryk Sun added the comment: No, ntpath and posixpath are cross-platform. They are tested on all platforms, and the os.path documentation lists them and notes that "you can also import and use the individual modules if you want to manipulate a path that is always in one of the diff

[issue28166] WindowsConsoleIO misbehavior when Ctrl+C is ignored

Eryk Sun added the comment: On second thought, I think the fact that the console leaves the previously entered text on the line is ugly and confusing. The text isn't in the input buffer, so it won't be read. Yet there's no way for the user to even clear it -- not by escape

[issue39318] NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws

Eryk Sun added the comment: > I afraid that removing a file while the file descriptor is open > may not work on Windows. Seems this case is not well tested. os.remove will succeed on a file that's opened with O_TEMPORARY, which shares delete access (i.e. FILE_SHARE_DELETE). W

[issue39312] Expose placeholder reparse points in Windows

Eryk Sun added the comment: Okay, a well-known third-party library will work if a script/application really needs this information. I just wanted to bring it up for consideration because I saw an issue for cross-platform PowerShell 6 [1] where it was decided to disable placeholder

[issue39295] usage of bitfields in ctypes structures changed between 3.7.5 and 3.7.6

Eryk Sun added the comment: > With Python 3.7.6 this raises an exception at the ctypes.CFUNCTYPE() > call with > ... > TypeError: item 1 in _argtypes_ passes a struct/union with a bitfield > by value, which is unsupported. I cannot reproduce the problem as stated in 3.7.6

[issue39340] shutil.rmtree and write protected files

Eryk Sun added the comment: I'm not certain exactly what you want Python to be doing here, but let's start out by clarifying some concepts. > Reproduction method linux > mkdir test; touch test/file.txt; chmod -w test/file.txt Unlinking a file requires write permissi

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

Eryk Sun added the comment: The warning would not apply to Windows. The environment block is part of the Process Environment Block (PEB) record, which is protected by a critical-section lock. The runtime library acquires the PEB lock before accessing mutable PEB values. For example

[issue39393] Misleading error message upon dependent DLL resolution failure

Eryk Sun added the comment: That clarification seems okay to me. The error message is in load_library in Modules/_ctypes/callproc.c. The underlying problem is that the directory of the DLL is only added to the search path (in CDLL.__init__ in Lib/ctypes/__init__.py) if the caller uses a

[issue39401] Unsafe dll loading in getpathp.c on Win7

Eryk Sun added the comment: > On Win7, running Python in the terminal will attempt to load the > "api-ms-win-core-path-l1-1-0.dll" from various paths outside of the > Python directory and the C:\Windows\System32 directories. "api-ms-win-core-path-l1-1-0.dll" i

[issue39406] Implement os.putenv() with setenv() if available

Eryk Sun added the comment: > Maybe use SetEnvironmentVariable() on Windows? `_wputenv` keeps Python's copy of the environment block in sync with CRT's copy, which in turn calls `SetEnvironmentVariableW` to sync with process environment block. The CRT's copy of the enviro

[issue39413] Implement os.unsetenv() on Windows

Eryk Sun added the comment: This bypasses the CRT's copy of the environment. If any C code calls [_w]getenv, it will still see the variable defined. The only way it won't is if setting the value also bypassed the CRT environment by directly calling SetEnvironmentVariableW. -

[issue39412] Install launcher for all users

Eryk Sun added the comment: The py launcher is separate from individual installations of Python. However many versions of Python are installed at the system level and for however many users, the system needs only one installation of the launcher. That's why it's recommended to i

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

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

[issue39406] Implement os.putenv() with setenv() if available

Eryk Sun added the comment: > Python can safely removes the string to _putenv() just after the call? Windows ucrt copies the buffer that's passed to _[w]putenv. This makes it non-compliant with POSIX but easier to use in this case. Here's an example using ctypes:

[issue39375] Document os.environ[x] = y and os.putenv() as thread unsafe

Eryk Sun added the comment: > no need to remove that message. I was discussing the wrong API. It's not directly relevant that Windows API functions that access the process environment are protected by the PEB lock. Python primarily uses [_w]environ, a copy of the process env

[issue39420] Windows: convertenviron() doesn't parse environment variables properly

Eryk Sun added the comment: > The problem is that the _wputenv() function allows to insert variable > names containing the "=" character No, it does not. Your experiments uncovered bugs elsewhere with the implementations of _wgetenv and WINAPI GetEnvironmentVariableW, but

[issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is incorrect

Eryk Sun added the comment: This is a duplicate of issue 38092. The required change to fix this is very simple, if you want to work on a PR. -- nosy: +eryksun resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> environment variable

[issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is incorrect

Eryk Sun added the comment: > can you confirm that the fix is to just change spawn.get_executable() > to return sys.executable, like it was prior to the PR mentioned in > the other ticket? Yes, in spawn.py, change `_python_exe = sys._base_executable` to `_python_exe = sys.executab

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Eryk Sun added the comment: Supporting __fspath__ for os.environ[b] makes it consistent with POSIX os.putenv, which already supports it via PyUnicode_FSConverter. For example: os.putenv(Path('spam'), Path('eggs')) getenv = ctypes.CDLL('libc.so.6&#x

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Eryk Sun added the comment: > I honestly would have disagreed with the Popen change for its 'env' > argument or any other place that is dealing with environment > variables os.spawnve (Windows) and os.execve support __fspath__ for the env dict partially due to me (bpo-

[issue39401] Unsafe dll loading in getpathp.c on Win7

Eryk Sun added the comment: > For clarity, I'm removing 3.9 from the affected versions. This version > does not support Windows 7, and only Windows 7 is vulnerable to this > DLL hijack. I added 3.9 for the related issue to switch to using a static import, since Windows 7 isn&

[issue39468] .python_history write permission improvements

Eryk Sun added the comment: This issue is due to a bug in GNU Readline (actually GNU History). It's documented that write_history [1] returns an errno value. But the internal history_do_write [2] function in this case returns the value from a rename() system call, via the value

[issue39461] [RFE] os.environ should support Path-like values, like subprocess(..., env=...)

Eryk Sun added the comment: > as long as the behavior is *consistent* with the env kwarg to > subprocess.run() subprocess isn't consistent with itself across platforms. The env parameter in Windows is strictly an str->str mapping, like os.environ. This is coded in get

[issue39469] Support for relative home path in pyvenv.cfg

Eryk Sun added the comment: > Suffice to say, is there a significant reason to not allow it? It's poorly supported by packaging. In particular, relocating an environment isn't supported with entry-point scripts, which pip installs with a fully-qualified shebang. Moreover

[issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7

Eryk Sun added the comment: > this PR has caused failures of 2 buildbots The master branch should no longer get built on Windows 7 machines. The initial build succeeds, but running "_freeze_importlib[_d].exe" fails with STATUS_DLL_NOT_FOUND (0xC135, i.e. -1073741515) since

[issue33339] Using default encoding with `subprocess.run()` is not obvious

Eryk Sun added the comment: This issue was already addressed for 3.x in bpo-31756, which added the a `text` parameter and updated the documentation. As to 2.7, it was officially retired as of the first of this month. Anyway, I don't think there was a pressing need to clarif

[issue39515] pathlib won't strip "\n" in path

Eryk Sun added the comment: A Windows path reserves the following characters: * null, as the string terminator * slash and backslash, as path separators * colon as the second character in the first component of a non-UNC path, since it's a drive path Additionally, a normalized

[issue39515] pathlib won't strip "\n" in path

Change by Eryk Sun : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue39

[issue39544] Pathlib PureWindowsPath sorting incorrect (is not natural sort)

Change by Eryk Sun : -- components: +Library (Lib), Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <https://bugs.python.org/issue39

[issue39544] Pathlib PureWindowsPath sorting incorrect (is not natural sort)

Eryk Sun added the comment: > Right now PureWindowsPath does probably something like NTFS sorting, > but NTFS is not Windows and from a function called 'WindowsPath' I > expect a path that would be given in Windows Explorer. NTFS stores the names in a directory as a

[issue36792] [Windows] time: crash on formatting time with de_DE locale

Eryk Sun added the comment: > Perhaps it would be easy to do the replacement of underscores with > hyphens on Windows in this function? I think that's safe enough, yes? Recent releases of ucrt implement this translation from underscore to hyphen for us, so this suggestion i

[issue36792] [Windows] time: crash on formatting time with de_DE locale

Eryk Sun added the comment: > Even some well known locale names still use the utf-8 code page. Most > seem to uncommon, but at least es-BR (Brazil) does and would still > fall victim to these UCRT bugs. es-BR is a custom locale for the Spanish language in Brazil, as opposed to th

[issue36792] [Windows] time: crash on formatting time with de_DE locale

Eryk Sun added the comment: That the CRT caches the tzname strings as ANSI multibyte strings is frustrating -- whether or not it's buggy. I would expect there to be a _wtzname cache of the native OS strings that wcsftime uses directly, with no potential for failed encodings (e.g.

[issue39484] time_ns() and time() cannot be compared on windows

Eryk Sun added the comment: A binary float has the form (-1)**sign * (1 + frac) * 2**exp, where sign is 0 or 1, frac is a rational value in the range [0, 1), and exp is a signed integer (but stored in non-negative, biased form). The smallest value of frac is epsilon, and the smallest

[issue39484] time_ns() and time() cannot be compared on windows

Eryk Sun added the comment: > I'm not sure what you're suggesting here. I shouldn't try to understand > how floating-point numbers are stored? No, that's the furthest thought from my mind. I meant only that I would not recommend using one's own understa

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

Eryk Sun added the comment: > On Windows 10 (version 1903), ANSI code page 1252, OEM code page 437, > LC_CTYPE locale "French_France.1252" The CRT default locale (i.e. the empty locale "") uses the user locale, which is the "Format" value on the Regi

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

Eryk Sun added the comment: It is not a duplicate of bpo-37945. The tests in test/test__locale.py need to be fixed to work with Windows. In msg354021, I discussed the problem reported with test_lc_numeric_localeconv. The "ps_AF" (Pashto, Afghanistan) item in known_numerics

[issue39633] venv does not include python. symlink by default

Eryk Sun added the comment: > That means that libraries should assume they are being installed into > venvs. Therefore makefiles should be invoking plain "python" rather > than "pythonX.Y" In Unix, 3.x virtual environments include a "python3" symlink o

[issue39655] Shared_Memory attaching to incorrect Address in Windows 10

Eryk Sun added the comment: shared_memory is not the problem here. Your example assumes that a.dtype is int64, but a numpy array defaults to "the minimum type required to hold the objects in the sequence", and the actual minimum depends on the size of the platform `long`. In

[issue38263] [Windows] multiprocessing: DupHandle.detach() race condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)

Eryk Sun added the comment: > I seem to be consistingly hitting this issue. It will help with test development if you can provide a minimal example that reliably reproduces the problem. In msg353064 I see DuplicateHandle calls failing with ERROR_ACCESS_DENIED (5). Assuming the proc

[issue39746] Inappropriate short circuit relating to inequality comparison and membership test

Eryk Sun added the comment: For reference see the section on comparisons in the language reference: https://docs.python.org/3/reference/expressions.html#comparisons -- nosy: +eryksun resolution: -> not a bug ___ Python tracker <

[issue39920] os.lstat() does not work with Window Dos devices

Eryk Sun added the comment: > This is an os.lstat() limitation, nothing to do with pathlib. In 3.8+, stat() and lstat() work with a broader rang of device paths, at least for st_mode checks. For example: >>> s = os.stat('//./PhysicalDrive0') >>> stat.S

[issue39920] os.stat() and os.lstat() fail with Windows device paths

Eryk Sun added the comment: The particular error reported here is due to pathlib, which is a duplicate of issue 33898. That said, since the OP is using 3.7, I've left this issue open in case someone wants to backport the win32_xstat_impl changes that enable stat() (and in particular se

[issue39962] Wrong file.tell() function results (Windows 10/Python 64 3.8.2/3.7 - no bug in PyPy3.6/Python2.7)

Eryk Sun added the comment: > Sorry, but there is no documented relationship between byte > offsets and tell() results for text-mode files in Windows: The I/O stack in Python 3 does not use C FILE streams, and this issue is not related to Windows. TextIOWrapper.tell returns a "co

[issue39845] Argparse on Python 3.7.1 (Windows) appends double quotes to string if it ends with backward slash

Eryk Sun added the comment: PowerShell translates single quotes to double quotes when they're used to delimit a string in the command line, which complies with VC++ command-line parsing and CommandLineToArgvW [1]. But PowerShell 5 has a bug here. It translates 'C:\unu doi\' i

[issue17023] Subprocess does not find executable on Windows if it is PATH with quotes

Eryk Sun added the comment: Why are new versions getting added to an issue that was closed 5 years ago? That said, I'd like to clarify that this was not and is not a bug. It happens that the CMD shell strips quotes out, but that doesn't make it valid. PATH in Windows is de

[issue40095] Incorrect st_ino returned for ReFS on Windows 10

Change by Eryk Sun : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue40

[issue40095] Incorrect st_ino returned for ReFS on Windows 10

Eryk Sun added the comment: > C:\Users>fsutil file queryfileid u:\test\test.jpg > File ID is 0x29d504ae ReFS uses a 128-bit file ID, which I gather consists of a 64-bit directory ID and a 64-bit relative ID. (Take this with a grain of salt. AFAIK, Microsof

[issue40094] Add os.waitstatus_to_exitcode() function

Eryk Sun added the comment: > On Windows, os.waitpid() status also requires an operation (shif > right by 8 bits) to get an exitcode from the waitpid status. FWIW, I wouldn't recommend relying on os.waitpid to get the correct process exit status in Windows. Status codes are

[issue40094] Add os.waitstatus_to_exitcode() function

Eryk Sun added the comment: > It's more the opposite, if tomorrow we want to encode the status > of a terminated process differently, it will be easier if > os.waitstatus_to_exitcode() is available, no? This new status-to-exitcode function applies to Windows waitpid() only du

[issue40143] shutil.rmtree will frequently fail on Windows under heavy load due to racy deletion

Eryk Sun added the comment: > It's inherently racy, since deleting a file on Windows *doesn't > actually delete it*, instead it marks the file for deletion. The > system will eventually get around to deleting it, but under heavy > load, this might be sometime after

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

Eryk Sun added the comment: > Maybe something else was installed that put an incompatible > _sqlite3.dll on PATH? Thereby proving the inherent risk of > using unsafe DLL load settings should_pass() sets the working directory of the test process to the `tmp` directory. The loader

[issue40238] os.stat() on Windows succeeds for nonexistent paths with trailing spaces

Eryk Sun added the comment: > os.stat() seems to be striping significant trailing spaces off > the path argument The Windows file API normalizes paths to replace forward slashes with backslashes; resolve relative paths and "." and ".." components; strip trailing

[issue40238] os.stat() on Windows succeeds for nonexistent paths with trailing spaces

Eryk Sun added the comment: > While I agree that Windows is safe to transform paths as he wishes to, > the bug reported here is that os.stat/os.path.isdir behaves > differently than os.scandir. Can we make them behave the same? os.listdir and os.scandir can be modified to be

[issue40238] os.stat() on Windows succeeds for nonexistent paths with trailing spaces

Eryk Sun added the comment: > I'd say os.path.normpath() should perform the same (GetFullPathNameW?) > normalization as os.stat() and friends do. ntpath.abspath calls GetFullPathNameW (i.e. nt._getfullpathname) in Windows, but ntpath.normpath is pure Python. I agree that norm

[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

Eryk Sun added the comment: An "Applications\python.exe" progid gets created by browsing for "python.exe" when configuring the file association. For example, it gets created by the Windows shell (Explorer) via "open with" -> "choose another app"

[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

Eryk Sun added the comment: > How do I get to the "rocket" launcher? The py.exe launcher is installed by default with the Python 3 distribution from python.org. Did you install that, or did you install the app distribution from the Mi

[issue40253] Fix .py(w) file association with Pyhon 3 Windows installer

Eryk Sun added the comment: > I understand that py.exe is at least in part used to make handling > multiple python versions easier. On the command line the launcher supports multiple installed versions via the "-X[.Y][-32|-64]" option. In scripts it supports multiple vers

[issue11395] print(s) fails on Windows with long strings

Eryk Sun added the comment: > the problem (or at least with these numbers) occurs only when > the code is saved in a script, and this is run by double- > clicking the file The .py file association is probably using a different version of Python, or it's associated with the p

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

Eryk Sun added the comment: > But I'm not sure why that is getting loaded earlier than the > current directory. Is that the behaviour we went for here? I don't understand what's going on here if %PATH% is interfering. The current directory (%__CD__%) should be checked b

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

Eryk Sun added the comment: > it seems the search order we're getting for _sqlite3.dll (.pyd) is: > > * app directory > * SQL server install directory (?) > * Windows/System32 > * Windows > * %PATH% (which is truncated at 2190 chars) Thank you. It finally makes se

[issue40214] test_ctypes.test_load_dll_with_flags Windows failure

Eryk Sun added the comment: > You mean the CI agent is doing it? Because there's nowhere in > Python that should be doing it. The ProcessParameters->DllPath value is inherited until a process in the tree reverts to the original search path via SetDllDirectoryW(NULL), so

[issue37339] os.path.ismount returns true on nested btrfs subvolumes

Eryk Sun added the comment: > What do you mean by "portable version of mountpoint"? posixpath.ismount is based on a portable method to detect a mountpoint in Unix systems, since POSIX lacks a portable function for this. The implementation is simple. A symlink is never

[issue40358] pathlib's relative_to should behave like os.path.relpath

Eryk Sun added the comment: Note that the implementation of relpath is pure and thus assumes it's working with existing, resolved paths (i.e. "the filesystem is not accessed to confirm the existence or nature of path or start"). For example: >>> os.path.relpath(

[issue40368] os.path.realpath uppercases Windows drive letter on Python 3.8

Eryk Sun added the comment: > This behavior is inconsistent with `os.path.abspath` where it always > returns lowercased drive letter, ntpath.abspath calls GetFullPathNameW, which generally preserves the input case of the device/drive component. But it doesn't always preserve d

[issue40368] os.path.realpath uppercases Windows drive letter on Python 3.8

Eryk Sun added the comment: > `os.path.abspath(".")` returned > `'c:\\Users\\Kagami\\Documents\\GitHub\\gecko-dev'`. > Should `ntpath.normpaoh` make the drive letter uppercase? ntpath.abspath and ntpath.normpath should preserve the input case for all components

[issue40542] path environment variable not created correctly

Eryk Sun added the comment: Prepending directories ahead of system directories in PATH affects programs that implement their own search, which includes shells such as cmd.exe that do so in order to support PATHEXT efficiently. That said, note that temporarily prepending to PATH in a

[issue40610] ctypes on Windows: error message on DLL load failure is misleading

Eryk Sun added the comment: bpo-39393 improved the error message to mention "(or one of its dependencies)". That's the best we can reasonably do. A developer can monitor "loader snaps" messages in a debugger in order to discover the missing DLL and the directories

[issue36264] os.path.expanduser should not use HOME on windows

Eryk Sun added the comment: > set "HOME" to override a location derived from ~ Using HOME in Windows is not reliable because it is not a system environment variable. That makes it fair game for administrators, users, and applications to use however they like. Platform diffe

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