Eryk Sun added the comment:
> Or, obviously:
>
> with open(fn, 'rb') as fd:
> with mmap.mmap(fd.fileno(), 0, access=mmap.ACCESS_READ) as mm:
> with memoryview(mm)[:2] as data:
> print(data)
Doesn't this rely on the immediate finalizati
Eryk Sun added the comment:
The os__getfinalpathname_impl handle leak and VOLUME_NAME_NT problems were
fixed in another issue. However, PR 740 also includes fixes for handle leaks in
os.stat, specifically in win32_xstat_impl and get_target_path.
--
stage: -> patch review
title:
Eryk Sun added the comment:
> (sidenote: what os.path operation does Path.resolve() match?
> Path('nonexistent').resolve() returns a relative path on Python
> 3.7.1, whereas Path().resolve() returns an absolute path.)
pathlib should resolve 'nonexistent' in Win
Eryk Sun added the comment:
> There's no reason a non-existing drive should fail differently than
> a non-existing parent directory.
The drive exists (or should) if we're getting ERROR_NOT_READY (21). It's likely
a removable media device, such as an optical disc or car
Eryk Sun added the comment:
A crash with the code STATUS_HEAP_CORRUPTION (0xC374) is due to a bug, not
memory exhaustion. The bug may not be the fault of the interpreter or standard
library if you're working with extension modules or ctypes. It's easy to
corrupt the internal
Eryk Sun added the comment:
If I'm right, we can reduce your example down as follows:
import os
import subprocess
import time
import ctypes
RtlGetLastNtStatus = ctypes.WinDLL('ntdll').RtlGetLastNtStatus
RtlGetLastNtStatus.restype = ctypes.c_
Change by Eryk Sun :
--
components: +IO, Interpreter Core, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type: -> behavior
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issu
Change by Eryk Sun :
--
resolution: fixed -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Eryk Sun :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Remove current directory from posixpath.defpath to enhance
security
___
Python tracker
<https://bugs.python
Eryk Sun added the comment:
The launchers have inheritance enabled (for the duplicated standard handles,
which should be made inheritable via SetHandleInformation instead, but that's a
separate issue). However, multiprocessing doesn't use inheritable handles.
Spawning proc
Eryk Sun added the comment:
multiprocessing could be redesigned to make the child process responsible for
duplicating all handles from its logical parent (by PID passed on the command
line -- regardless of whatever its real parent is). That avoids the problem of
the parent mistakenly
Eryk Sun added the comment:
> The current solution is the simplest one that ensures the most
> compatibility for the least amount of risk, even though that
> was not zero risk, as we've seen.
How about making the py[w].exe launcher unset __PYVENV_LAUNCHER__ whenever it
run
New submission from Eryk Sun :
In 3.7.2 on Windows, venv now uses a redirecting launcher 'script' for
python[w].exe. This replaces (on Windows only) the setup requirement to copy or
symlink the interpreter binaries (i.e. python[w].exe, python37.dll, and
vcruntime140.dll). Apparent
Eryk Sun added the comment:
It's worth noting the consequences of changing the application directory (i.e.
the "%__APPDIR__%" dynamic variable from GetEnvironmentVariableW).
This is the first directory checked in most cases when Windows searches for a
file, including the Creat
Eryk Sun added the comment:
> 1. Is there a possibility that 3rd party applications like pip
> could see bugs with Python 3.7.2?
A bug occurs when running an entry-point script, such as pip.exe, for a system-
or user-installed Python 3.7.2+ from the context of a virtual environme
Eryk Sun added the comment:
> But if I understood what Steve said, only if path\to\python.exe is
> a *relative* pathname?
I believe Steve is referring to behavior changes for applications that relied
on a virtual environment's "Scripts" directory always being in the EXE
Eryk Sun added the comment:
> Actually, it seems like venv symlinks are so far from working
> that they haven't worked (on Windows) since 3.5 or possibly
> earlier.
I use venv with --symlinks prior to 3.7.2. It works fine as far as I can tell.
Perhaps you could elaborate.
Eryk Sun added the comment:
> Okay, testing more thoroughly on 3.5, symlinks are fine from the
> console but not via Explorer.
I gave up on using EXE symlinks with Explorer and ShellExecute[Ex]. The shell
handles symlinks like shortcuts instead of leaving it up to the file syst
Eryk Sun added the comment:
> Because sometimes when a process is implicitly started by some 3rd
> party library (i.e. COM via pythonwin here) the "old", unchanged
> environment is retained as the process itself doesn't care if
> os.environ was changed or no
Eryk Sun added the comment:
The __PYVENV_LAUNCHER__ variable gets set by each launcher instance. We get one
launcher process for every level of nesting, and the last launcher to run sets
the final value that will be seen by the real python.exe. Possibly the launcher
could resolve the home
Eryk Sun added the comment:
In Unix, Python 3.6 decodes the char * command line arguments via mbstowcs. In
Linux, I see the following misbehavior of mbstowcs when decoding an overlong
UTF-8 sequence:
>>> mbstowcs = ctypes.CDLL(None, use_errno=True).mbstowcs
>>> a
Eryk Sun added the comment:
It should be fine. If the docs don't require initializing cb, we can assume
it's done for us.
For example, msvcrt.dll calls GetStartupInfo without initializing this field:
0:000> kc 3
Call Site
KERNELBASE!GetStartupInfoW
msvcrt!ioin
Eryk Sun added the comment:
Oops, I forgot the check:
0:000> ?? sizeof(test!_STARTUPINFOW)
unsigned int64 0x68
--
___
Python tracker
<https://bugs.python.org/issu
Eryk Sun added the comment:
Steve, can you review and merge PR 740? Mark updated it to fix the handle leaks
in win32_xstat_impl as mentioned in my previous message. They're unlikely but
still should be fixed. In particular, iIt's unlikely that win32_get_reparse
Eryk Sun added the comment:
> This scenario should work, as running the other venv's redirector
> will update the variable.
The order gets reversed. In the simple case where we have two launchers, the
launcher for the nested virtual environment executes the launcher for the oute
Eryk Sun added the comment:
> You can't actually nest virtual environments, at least with venv
Yes, they can't be nested in terms of inheriting site-packages. But the "home"
value in this case references the creating environment, which hasn't changed
from previou
Eryk Sun added the comment:
> Is there any reason to not resolve the base executable on creation and
> make it relative to that? So the second pyvenv.cfg would have the same
> home directory as the first?
I was trying to avoid changing the existing behavior of `home` from how it
Eryk Sun added the comment:
> Correct, though the examples I'd give are Win32 vs. WinRT vs. Cygwin,
> which are fundamentally different API surfaces for interacting with
> the operating system.
Cygwin and MSYS are presented as more than APIs; they're separate platform
Change by Eryk Sun :
--
components: -Windows
___
Python tracker
<https://bugs.python.org/issue14094>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eryk Sun :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue14
Eryk Sun added the comment:
Ping on PR 11248. It would be nice to get this into 3.8.
--
___
Python tracker
<https://bugs.python.org/issue14094>
___
___
Pytho
Eryk Sun added the comment:
Python's C signal handler sets a flag and returns, and the signal is eventually
handled in the main thread. In Windows, this means the Python SIGINT handler
won't be called so long as the main thread is blocked. (In Unix the signal is
delivered on the m
Eryk Sun added the comment:
The access violation (exception code 0xC005) occurs in
algos.cp36-win_amd64.pyd, which is a Pandas extension module, so I'm closing
this issue as third party. You can open an issue with the Pandas project at
their GitHub repo:
https://github.com/panda
Eryk Sun added the comment:
For Windows, the default console control handler calls
ExitProcess(STATUS_CONTROL_C_EXIT). If CMD is waiting on an application that
exits with STATUS_CONTROL_C_EXIT, it prints "^C" to indicate the process was
killed by Ctrl+C. F
Eryk Sun added the comment:
I had closed this issue because I thought issue 23864 would be resolved by
extending the existing behavior. Three years later, still with no resolution,
Guido commented on that issue that the current behavior shouldn't be extended
and only the document
Eryk Sun added the comment:
Gregory's last example reminded me that CMD checks for STATUS_CONTROL_C_EXIT
for more than simply printing "^C". It also breaks out of a FOR loop when
interactive and prompts to continue when executing a batch script.
Normally CMD also gets a
Change by Eryk Sun :
Added file: https://bugs.python.org/file48142/winsig.py
___
Python tracker
<https://bugs.python.org/issue1054041>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
It may suit the needs of NumPy and SciPy to use an assembly for DLL
dependencies. With an assembly it's possible for two DLLs with the same name to
load in a process and possible for a DLL to extend the assembly search path
with up to nine relative paths at
Eryk Sun added the comment:
> I didn't realize assemblyBinding was supported by the generic runtime
> framework, the documentation https://docs.microsoft.com/en-us/dotnet/
> framework/deployment/how-the-runtime-locates-assemblies seems to
> suggest it is a dotnet feature
Eryk Sun added the comment:
Here's a WebDAV example:
net use Z: \\live.sysinternals.com\tools
Both st_dev (volume serial number) and st_ino (file number) are 0 for all files
on this drive. _getfinalpathname also fails since WebDAV doesn't support the
default FILE_NAME_NORMA
Eryk Sun added the comment:
> I don't see any value in testing the drive name separately.
If the file number is non-zero, then the volume is the only question. I limited
the comparison to just the drives in case the volume supports hardlinks. We can
change the check to `s1.st_in
Eryk Sun added the comment:
> os.access(path, os.X_OK) is specific to Unix. It doesn't make sense
> on Windows.
It doesn't make sense with the current implementation of os.access, and not as
Stéphane used it. Even if we completely implemented os.access, the problem is
that
Eryk Sun added the comment:
> Windows has the GetBinaryTypeW function
ShellExecute[Ex] doesn't check for a PE image. It uses the file extension, and
a tangled web of registry settings to determine what to execute. If a file
should run directly via CreateProcess, you'll find
Eryk Sun added the comment:
In Windows, the error for a path reparse (e.g. symlink or junction) that can't
be resolved is ERROR_CANT_RESOLVE_FILENAME. Another common error is
ERROR_INVALID_REPARSE_DATA. This can occur if the reparse data is malformed or
if the target device is invali
Eryk Sun added the comment:
The subprocess Handle object is never finalized explicitly, so the Process
handle should always be valid as long as we have a reference to the Popen
instance. We can call TerminateProcess as many times as we want, and the handle
will still be valid. If it&#
Eryk Sun added the comment:
> Proposal #1: CPython calls SetDefaultDllDirectories() [2] on startup
SetDefaultDllDirectories() affects the entire process, so it would needlessly
break the world -- especially for embedding applications and ctypes users that
have relied on adding director
Eryk Sun added the comment:
> I'm very against doing magic to extract the names from the DLL, but
> but maybe we could have a search path in the parent package? Then
> add/remove it around importing the module.
That works, too. I'm happy either way.
We still can't
Eryk Sun added the comment:
When run directly from the temp directory path that's reported in the log, does
the new log say that the installer is trying to run python-3.5.3-amd64.exe from
that same path, or is it trying to run it from a new dire
Eryk Sun added the comment:
A symbolic link is typically represented the other way around, from the point
of view of the link pointing at the target. However, Python conceptualizes
linking as something like a copy or rename operation, with source and
destination filenames, and the current
Eryk Sun added the comment:
To me the error message is in the model of a source -> destination operation,
in which the arrow indicates the operation's information flow (e.g. of the
target path or inode number) from the source file to the destination file. I've
never viewed it sup
Eryk Sun added the comment:
That's not the current directory. It's the 'script' directory (i.e. the parent
of main361), as set by PySys_SetArgv when Py_IsolatedFlag isn't set.
The old behavior was for RunMainFromImporter to unconditionally replace this
directory in
Eryk Sun added the comment:
> I don't have a specific problem that it causes.
Adding an arbitrary directory ahead of the standard library in sys.path is a
problem waiting to happen. This also happens when the import source is a zip
file, e.g. a
New submission from Eryk Sun:
The implementation of nt._getfinalpathname leaks a File handle if calling
GetFinalPathNameByHandle fails. The latter function is practically guaranteed
to fail when resolving the path for a non-file-system device. It also fails
when VOLUME_NAME_DOS is requested
Eryk Sun added the comment:
> There is no similar function taking a directory handle
In 3.5+ the CRT has O_OBTAIN_DIR (0x2000) for opening a directory, i.e. to call
CreateFile with backup semantics. A directory can be read via
GetFileInformationByHandleEx [1] using the information clas
Eryk Sun added the comment:
> It's actually "adding" the current directory
It's the script directory, which gets added on all platforms when PySys_SetArgv
is called with Py_IsolatedFlag == 0. In this case we're running "__main__.py"
from a directory or
Eryk Sun added the comment:
To make it simpler to diagram the fields, I've rewritten your structure using
field names A-J:
import ctypes
class MyStructure(ctypes.Structure):
_pack_ = 1
_fields_ = (('A', ctypes.c_uint16), # 2 bytes
Changes by Eryk Sun :
--
versions: +Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue29753>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
main361 can be run as a package from the current directory via -m because an
empty string is in sys.path, i.e. the current directory. It imports the
package, executing __init__.py and then __main__.py. In this case, the main361
directory/zip import source is not
Eryk Sun added the comment:
ctypes is correct. 64-bit Linux uses an LP64 data model, and 64-bit Windows
uses LLP64.
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
--
nosy: +eryksun
resolution: -> not a bug
stage: -> resolved
status: open -&g
Eryk Sun added the comment:
> After enabling `QuickEdit Mode`, then click the console will
> suspend the program.
That's not suspending the entire process. It's blocking the thread that writes
to the console. The user-mode WriteConsole function is implemented b
Eryk Sun added the comment:
resolve() can't replace absolute(). They serve different purposes. Sometimes
one wants an absolute path, but without resolving symbolic links.
absolute() processes a path as a string, which will continue to be true if it's
updated to call nt._getfu
Eryk Sun added the comment:
What's the rationale for not calling self._flavour.pathmod.abspath() to
implement absolute()? For example:
>>> p = pathlib.Path('C:/con')
>>> p._flavour.pathmod.abspath(p)
'.\\con'
>>> p._fro
Eryk Sun added the comment:
> assignment of "__lt__" change the value of the tp_richcompare slot?
Yes. CPython doesn't implement individual dispatching of the rich-comparison
functions. There's a single tp_richcompare slot, so overriding one rich
compa
Eryk Sun added the comment:
On Windows the "QueueFeederThread" in each child process is blocked in
WaitForMultipleObjects in PipeConnection._send_bytes. The pipe buffer size is 8
KiB, and each pickled int is 5-6 bytes. With 2 processes the pipe is full after
sending (256 + 469) *
Eryk Sun added the comment:
It's the same with ntpath.abspath since the underlying GetFullPathName function
processes the path only as a string. OK, so it seems we're requiring that
p.absolute().resolve() is the same as p.resolve().
Consider the following example:
>&
Eryk Sun added the comment:
Moving a file across volumes isn't atomic. Getting an exception in this case
can be useful. There could be a "strict" keyword-only parameter that defaults
to False. If it's true, then replace() won't try to move the file.
Eryk Sun added the comment:
> -7 divided by 2 is -3, not -4
Integer division in Python is floor division, and it's self-consistent with the
implementation of the modulo operation such that the following identity is
satisfied: (a % n) == a - n * (a // n). For example:
(-7 % 2) =
Eryk Sun added the comment:
This is a bug in the C runtime's handling of "r+" mode with buffering.
The CRT FILE stream's internal _cnt field, from the POV of the write() call, is
the number of bytes that can be written to the internal buffer before it's
full. The de
Eryk Sun added the comment:
> Run "python3 -I script.py" to not insert '' (current directory)
> at the first position of sys.path.
That should be "script directory", not "current directory". We only add the
current directory to sys.path in in
Eryk Sun added the comment:
In a string literal, '\t' represents a tab character (ordinal 9). Windows
filenames cannot contain control characters [1], i.e. ordinals 1-31. For path
literals I recommend using forward slashes and normalizing via
os.path.normpath, e.g
Eryk Sun added the comment:
An exception (not a crash) is possible if a standard handle is invalid and a
Popen call tries to replace one or two of the other standard handles (e.g.
stdin is invalid and you pass the argument stdout=PIPE). Note that subprocess
uses the standard handles directly
Eryk Sun added the comment:
3.5+ doesn't install files to system directories -- except the py launcher in
%SystemRoot%. This was an intentional change, so I'm flagging this as a
documentation issue.
--
assignee: -> docs@python
components: +Documentation, Windows
keyword
Eryk Sun added the comment:
When you say "to be precise...C:/Windows/...System32", do you mean that this is
the only directory that you've tested? If so, what you're seeing may be WOW64
file-system redirection, if your 2.7 installation is 64-bit and 3.6
installation is 3
Eryk Sun added the comment:
> It's inconsistent with the Linux experience of an all-users
> installation
Yes, if you build with --enable-shared on Linux, then the shared libraries
libpython3.X.so.1.0 and libpython3.so are installed in /usr/local/lib.
Currently there's no d
New submission from Eryk Sun:
The environment variable PYTHONLEGACYWINDOWSIOENCODING is documented here:
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONLEGACYWINDOWSIOENCODING
but not actually implemented. Also, I think setting PYTHONIOENCODING to
anything except UTF-8 should
Eryk Sun added the comment:
I prefer the name PYTHONLEGACYWINDOWSIOENCODING for symmetry with both
PYTHONIOENCODING and PYTHONLEGACYWINDOWSFSENCODING, but I suppose you changed
it to make it more visually distinguished from the latter.
I discovered this issue due to the modified behavior of
Eryk Sun added the comment:
For COM[n] and LPT[n], only ASCII 1-9 and superscript 1-3 (U+00b9, U+00b2, and
U+00b3) are handled as decimal digits. For example:
>>> print(*(ascii(chr(c)) for c in range(1, 65536)
... if _getfullpathname('COM%s' % chr(c))[0] ==
Eryk Sun added the comment:
I'm closing this issue since Python's encodings in this case -- 852 (OEM) and
1250 (ANSI) -- both correctly map U+0159:
>>> u'\u0159'.encode('852')
'\xfd'
>>> u'\u0159'.encode('125
Eryk Sun added the comment:
The offset in ucrtbase.dll where it's crashing may hint at the culprit. The
following command should print the full event log for the most recent crash:
wevtutil qe application /rd:true /c:1 /format:text
/q:"*[System[Provider[@Name='Application
Erro
Eryk Sun added the comment:
Steve, I added 3.5 because the crash involved ucrtbase.dll. I'll remove it for
now since the problem is only confirmed in 3.6.
Offset 0x3bd9e in 32-bit ucrtbase.dll is in wdupenv_s [1]. It's probably from
calling new_spawnve in pydev_monkey.py, as sh
Eryk Sun added the comment:
It's simple to fix this in Python 3 on Windows. PyErr_SetInterrupt in
Modules/signalmodule.c needs the following addition:
#ifdef MS_WINDOWS
SetEvent(sigint_event);
#endif
In the main thread on Windows, time.sleep() waits on this event.
On
Eryk Sun added the comment:
I can confirm that the CRT function construct_environment_block() does cause an
access violation sometimes when no "=x:" shell variables are defined in the
current environment. These "=x:" environment variables are the way that Windows
em
Eryk Sun added the comment:
For Windows the event should be set after trip_signal(SIGINT). That way the
flag is guaranteed to be tripped when PyErr_CheckSignals is called from the
time module's pysleep() function. This in turn calls the default SIGINT handler
that raises a KeyboardInte
Eryk Sun added the comment:
Nathaniel's suggestion to update the implementation to work with raise(SIGINT)
sounds like a good idea.
Fpr Windows, GenerateConsoleCtrlEvent is definitely a non-starter.
PyErr_SetInterrupt shouldn't depend on having an attached console. IDLE
gene
Eryk Sun added the comment:
> Even is IDLE is started from a console, the user execution process
> is not attached to one.
Actually, the execution process is attached to a console, but it doesn't use it
for sys.std*. Try
open('con', 'w').write('s
Eryk Sun added the comment:
The initial release of WSL doesn't support passing non-console standard handles
from Windows to Linux, or vice versa. It will work if you switch to a Windows
Insider preview build. Otherwise you'll have to wait for the Windows 10
Creators Update.
Changes by Eryk Sun :
--
resolution: not a bug -> third party
___
Python tracker
<http://bugs.python.org/issue29938>
___
___
Python-bugs-list mailing list
Un
Eryk Sun added the comment:
> windows version run success!
Trying to decode a non-ASCII unicode string should raise an exception on any
platform:
Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40)
[MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyri
Eryk Sun added the comment:
> I've personally found this `multiprocessing` restriction (daemonic
> processes can't have children) to be nothing but a pain in the ass
To make that reliable on Windows you could create a silent-breakaway,
kill-on-close Job object in each proces
Eryk Sun added the comment:
> e.g., a Pool worker dies with an assert(!) error if it tries to create
> its own Pool for something
A daemon process could create a child daemon when the OS can ensure that no
orphans are left behind (e.g. call Linux prctl to set PR_SET_PDEATHSIG as
S
Eryk Sun added the comment:
>From the linked issue:
> proc.send_signal(CTRL_C_EVENT) raises the KeyboardInterrupt
> in both the original and subprocess on Windows
GenerateConsoleCtrlEvent takes process group IDs, so it should have been used
to implement os.killpg, not os.kill. If yo
Eryk Sun added the comment:
Alternatively we could use the SleepEx and WaitFor*Ex functions with alertable
waits (i.e. using APCs) instead of the SIGINT Event. This avoids having to
replace all single-object waits with multiple-object waits, and would even
allow calling SleepEx in pysleep
Changes by Eryk Sun :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/issue29
Eryk Sun added the comment:
> Though I don't have any idea if it works on Windows, but it seems
> properly factored.
Generally it should. However, os.get_terminal_size is unnecessarily limited to
the standard handles with a hard-coded mapping 0 => StandardInput, 1 =>
Stan
Eryk Sun added the comment:
Use %r instead of %s to show the repr. Hopefully that should clear things up
for you. int() truncates toward 0. The float in this case is slightly less than
1.
--
nosy: +eryksun
resolution: -> not a bug
stage: -> resolved
status: open -&g
Eryk Sun added the comment:
> Windows also treats full-width spaces as a delimiter when parsing
> command line arguments.
CreateProcess has to parse the beginning of the command-line string if the
lpApplicationName parameter is omitted. According to the documentation, it
treats "
Eryk Sun added the comment:
In Python 3, gzip.open(filename, "rt") returns a TextIOWrapper using the
system's default encoding. The decoded output is potentially very different
from the byte string returned by 'text mode' in Python 2, even if using "rt"
mo
Eryk Sun added the comment:
You want to hack a fake text mode, which won't do new-line translation or treat
^Z (0x1a) as EOF like a normal 2.x text mode on Windows. Can't you just use
io.TextIOWrapper(gzip.open(filename))? This rea
Eryk Sun added the comment:
In Windows IDLE 3.x, you should still be able to print a surrogate transcoding,
which sneaks the native UTF-16LE encoding around tkinter:
def transurrogate(s):
b = s.encode('utf-16le')
return ''.join(b[i:i+2].decode('
Eryk Sun added the comment:
cmd.exe enables virtual terminal mode, but only for itself. It disables VT mode
before starting other programs, and also at shutdown. It appears you've found a
bug in the case of "cmd.exe /c ...". You can get the same result via
os.system('
1301 - 1400 of 2119 matches
Mail list logo
