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
On 10/19/20, Grant Edwards wrote:
> On 2020-10-19, Stephen Tucker wrote:
>
>> For a neatish way to get a string to end with a single backslash, how
>> about
>>mystr = r"abc\ "[:-1]
>> (Note the space at the end of the rough-quoted string.)
>
> That's the first thing I thought of, though I
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
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
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
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
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
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
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
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
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
&
On 10/16/20, Steve wrote:
> -Original Message-
> From: Python-list On
> Behalf Of Frank Millman
> Sent: Friday, October 16, 2020 4:34 AM
> To: python-list@python.org
> Subject: Re: How do I get datetime to stop showing seconds?
>
> On 2020-10-16 9:42 AM, Steve wrote:
>> d2 =
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
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
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
On 10/13/20, Tony Flury via Python-list wrote:
> I am trying to write a simple expression to build a raw string that ends
> in a single backslash. My understanding is that a raw string should
> ignore attempts at escaping characters but I get this :
>
> >>> a = r'end\'
>File "", line
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
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
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
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.
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg378489
___
Python tracker
<https://bugs.python.org/issue42013>
___
___
Python-bugs-list mailin
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
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
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
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
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
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.
&
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
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
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
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
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
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
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
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
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
Eryk Sun added the comment:
Python supports Unicode in a Windows console session by using the console API's
wide-character functions (i.e. ReadConsoleW and WriteConsoleW) with UTF-16
encoded text. This is implemented in the io stack via io._WindowsConsoleIO, and
for PyOS_Readline (e.g
Eryk Sun added the comment:
> I wouldn't think that changing locales would have an effect on Windows
> paths being case sensitive or not, otherwise folks from other countries
> would be experiencing this error. Perhaps the mixing of locale and system
> language? I had locale
Eryk Sun added the comment:
This is already addressed in bpo-28080, which adds an `encoding` parameter --
e.g. `encoding="oem"` ("oem" is only available in Windows). Unfortunately
bpo-28080 has languished without resolution for four years.
-
Eryk Sun added the comment:
> "C:\Users\chris\code\project\myenv\Scripts\python.exe"
Have you tried different case combinations for "Users" and "Scripts"?
* C:\users\chris\code\project\myenv\scripts\python.exe
* C:\users\chris\code\project\myenv\
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg377918
___
Python tracker
<https://bugs.python.org/issue41925>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
> "C:\Users\chris\code\project\myenv\Scripts\pip.exe"
Have you tried different case combinations for "Users" and "Scripts"?
* C:\users\chris\code\project\myenv\scripts\pip.exe
* C:\users\chris\code\project\myenv\Scripts\
On 10/3/20, Gertjan Klein wrote:
>
> I tried to find out what happens, using your other code:
>
> >>> import win32con, win32api
> >>> access = win32con.PROCESS_QUERY_LIMITED_INFORMATION
> >>> hproc = win32api.OpenProcess(access, False, pid)
> >>> executable =
Eryk Sun added the comment:
> maybe we should consider moving the bitness to the folder title
> (so the folder becomes "Python 3.8 64-bit")?
Splitting up the start-menu entries into separate "Python 3.9 (32-bit)" and
"Python 3.9 (64-bit)" folders wou
On 10/2/20, Nipur Gupta wrote:
> I've downloaded python 3.6.0 64 bits but whenever I try to open idle, it
Python 3.8 supports Windows 8.1, so, unless otherwise required, you
should install the latest release of 64-bit Python 3.8, which is
currently 3.8.6:
On 10/2/20, Gertjan Klein wrote:
> Eryk Sun wrote:
>
>> If .py files are associated with py.exe or python.exe, then running a
>> .py script either inherits or allocates a console and attaches to it.
>
> Is it possible to determine, from within Python, whether Python
On 9/30/20, Mirko via Python-list wrote:
>
> I have only limited knowledge about current Windows systems. But it
> seems to me that newcomers download some setup exe/msi and then
> search the menu to run what ever is found (python.exe or even the
> setup-program.)
It might help some people who
On 9/30/20, Dennis Lee Bieber wrote:
> On Tue, 29 Sep 2020 22:31:18 + (UTC), Ron Villarreal via Python-list
> declaimed the following:
>
>>Tried to open Python 3.8. I have Windows 10. Icon won’t open.
>
> What "Icon"?
>
> Python is a language interpreter/compiler -- it runs from
Change by Eryk Sun :
--
stage: -> needs patch
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3
___
Python tracker
<https://bugs.python.org/issu
Eryk Sun added the comment:
> `data_as` method which has the desired behavior: "The returned
> pointer will keep a reference to the array."
I don't think it's the desired behavior at all. data_as() sets an _arr
attribute of which ctypes isn't aware. It should cast the addr
Eryk Sun added the comment:
I think this is a numpy issue. Its data_as() method doesn't support the ctypes
_objects protocol to keep the numpy array referenced by subsequently created
ctypes objects. For example:
import ctypes
import numpy as np
dtype = ctypes.c_double
On 9/28/20, Dennis Lee Bieber wrote:
> On Sun, 27 Sep 2020 05:33:14 +0300, "Hylton"
> declaimed the following:
>
>> "C:\Users\user\AppData\Roaming\Python\Python38\site-packages\pip\_vendor\
>> distlib\scripts.py", line 386, in _get_launcher
>
> That path seems to imply that you have a
On 9/28/20, Dennis Lee Bieber wrote:
>
> Python is not a GUI. You do not "click on the phyton.exe file" (sic).
> You open a command shell and, in a proper install which sets up the PATH
> environment variable, enter "python" as the command to execute.
You can run python.exe directly from
Eryk Sun added the comment:
> File "c:\users\chris\appdata\local\programs\python\python38-32
> \lib\runpy.py", line 194, in _run_module_as_main
You have to use 64-bit Python in order to load a 64-bit DLL from the native
"%SystemRoot%\System32" directory. The
Eryk Sun added the comment:
> We already update the current shell, so if you start a new
> terminal/Powershell/cmd/etc. instance it should have the
> updated variable.
The installer broadcasts an "Environment" message to top-level windows. In
practice, on
Eryk Sun added the comment:
> The biggest risk here is that we have to emulate GNU readline for
> compatibility, which severely limits the data that can be passed
> through, and also forces multiple encoding/decoding passes.
I'm not suggesting to disable the console's line-input
New submission from Eryk Sun :
io._WindowsConsoleIO reads from the console via ReadConsoleW in line-input
mode, which limits the line length to the maximum of 256 and the size of the
client buffer, including the trailing CRLF (or just CR if processed-input mode
is disabled). Text that's
On 9/23/20, yehudis...@gmail.com wrote:
>It’s a py file with simple python code
If .py files are associated with py.exe or python.exe, then running a
.py script either inherits or allocates a console and attaches to it.
The console closes automatically as soon as the last reference to it
Eryk Sun added the comment:
It seems to me that if `path == name`, then resetperms(path) and possibly a
recursive call are only needed on the first call. In subsequent calls, if `path
== name`, then we know that resetperms(path) was already called, so it
shouldn't handle PermissionError
Eryk Sun added the comment:
> " OSError: [WinError 126] The specified module could not be found" is
> raised when calling ctypes.CDLL(dll_path) even when this "dll_path"
> exists... because the error comes from another DLL.
That's the old error. bpo-36085 ch
Eryk Sun added the comment:
I've decided to close this issue since extending the "Using Python on Windows"
section of the docs to recommend using a TrueType font in the console would
only be generally useful for people using Python 3.8 with Windows 7. Python
3.9+ requires W
Eryk Sun added the comment:
> It is set to use an OEM raster font.
Okay, then the issue can either be closed as third-party or changed to a
documentation enhancement. It could be documented that Unicode support requires
selecting a TrueType font in the console properties. "Raster Fon
Eryk Sun added the comment:
If you've selected an OEM raster font in the console properties instead of a
TrueType font (Consolas, Lucida Console, etc), then the console implements some
magic to support the OEM character mapping in the raster font. The following
shows that encoding
Eryk Sun added the comment:
> The return code of python on linux when the program is ended with
> a KeyboardInterrupt should be -2
In general, the exit status for an unhandled KeyboardInterrupt (i.e.
_Py_UnhandledKeyboardInterrupt) should be the same as the default SIGINT
h
Eryk Sun added the comment:
> We'd CreateFile the file and then immediately pass it to
> _open_osfhandle
Unlike _wopen, _open_osfhandle doesn't truncate Ctrl+Z (0x1A) from the last
byte when the flags value contains _O_TEXT | _O_RDWR. _wopen implements this to
allow appending data i
Eryk Sun added the comment:
> we'd have to reimplement the UCRT function using the system API.
Could the implementation drop support for os.O_TEXT? I think Python 3 should
have removed both os.O_TEXT and os.O_BINARY. 3.x has no need for the C
runtime's ANSI text mode, with its Ctr
Eryk Sun added the comment:
> Nothing preventing someone from contributing the flag on open as well.
To be clear, supporting delete-access sharing would require re-implementing C
_wopen in terms of CreateFileW, _open_osfhandle, etc. It could be implemented
as _Py_wopen in Pyt
Eryk Sun added the comment:
> Why do we need to use this O_TEMPORARY flag at all?
Using the O_TEMPORARY flag isn't necessary, but it's usually preferred because
it ensures the file gets deleted even if the process is terminated abruptly.
However, it opens the file with delete acc
Eryk Sun added the comment:
The underlying subprocess.Popen class was updated in 3.8 to support path-like
objects in `args` (with shell=False) and `executable` on Windows [1]. This
change was not backported to 3.6 and 3.7.
---
[1] https://docs.python.org/3/library/subprocess.html
Eryk Sun added the comment:
> For this case, I think the best thing we can probably do is change the
> default share mode for _all_ opens to include FILE_SHARE_DELETE.
The C runtime doesn't provide a way to share delete access, except for the
O_TEMPORARY flag, so Python would have
Eryk Sun added the comment:
> Is this line needed with a repeat of 1, or should it be removed?
It's not documented what it means to write a key event with wRepeatCount set to
0. It happens to work, but I'd leave it set to 1, which means the key was
pressed once. Ideally, there should a
Eryk Sun added the comment:
> if NotADirectoryError should be raised, it should mention '/path/to/file'
> rather then '/path/to/file/somename.txt'.
POSIX specifies that C open() should set errno to ENOTDIR when an existing path
prefix component is neither a directory nor a s
Eryk Sun added the comment:
> ÄÄ^Z^Z^Z^Z^Z^Z^Z^Z^Z^Z
I don't know why Steve made write_input (PC/_testconsole.c) set wRepeatCount in
each KeyEvent record to 10. Maybe it was a typo. Previous console
implementations have ignored the repeat count, so it wasn't an issue.
test_ctr
Eryk Sun added the comment:
This behavior is due to issue 37609, i.e. ntpath.splitdrive fails for "UNC"
device paths.
>>> ntpath.splitdrive('//?/UNC/server/share')
('//?/UNC', '/server/share')
The result should be "//?/UNC/server/share". A path on the &
On 9/3/20, Greg Ewing wrote:
> On 2/09/20 6:55 am, Eryk Sun wrote:
>> According to POSIX (st_dev, st_ino), it's the same directory, yet the
>> ".." entry evaluates depending on the path parsing context:
>>
>> >>> os.lstat('test1/spam/..').s
Eryk Sun added the comment:
> Maybe in the time module?
The SIGINT event is also needed by PyOS_Readline, _io (builtin), _winapi
(builtin), and _multiprocessing (pyd). Is the time module guaranteed to be
imported in 3.x? It appears to get imported incidentally via _PyImportZip_I
Change by Eryk Sun :
--
Removed message: https://bugs.python.org/msg376231
___
Python tracker
<https://bugs.python.org/issue41686>
___
___
Python-bugs-list mailin
Eryk Sun added the comment:
> Maybe in the time module?
The SIGINT event is also needed by PyOS_Readline, _io (builtin), _winapi
(builtin), and _multiprocessing (pyd). Is the time module guaranteed to be
imported in 3.x? It appears to get imported incidentally via _PyImportZip_I
On 9/1/20, Chris Angelico wrote:
> On Wed, Sep 2, 2020 at 4:55 AM Eryk Sun wrote:
>
>> "test2/spam" is a bind mount for "test1/spam", and note that `mount
>> --bind` in Linux is a namespace operation, i.e. it's not a new device:
>>
>> >>
On 9/1/20, Chris Angelico wrote:
>
> Also, even if all that could be solved, I don't like the idea that
> reading the same directory from two different sources leads to
> different results. Is it really the same directory if reading it in
> different ways gives different results?
What's your
Eryk Sun added the comment:
The SIGINT event gets created when the _signal extension module is imported.
Until then, _PyOS_SigintEvent() returns NULL. But currently all code that calls
_PyOS_SigintEvent() assumes it returns a valid handle. This has to be fixed to
support Py_InitializeEx(0
On 8/25/20, Andrew Nelson wrote:
>
> st_ino is supposed to "uniquely identify the file for a given value of
> st_dev."
That assurance only applies to POSIX systems, not Windows.
st_ino is the file ID in Windows. Some filesystems do not support
reliable file IDs, if any at all. I would only rely
Eryk Sun added the comment:
Case-sensitive file access is potentially possible with
FILE_FLAG_POSIX_SEMANTICS (CreateFileW) and FIND_FIRST_EX_CASE_SENSITIVE
(FindFirstFileExW). These flags make the API omit the object-manager flag
OBJ_CASE_INSENSITIVE in the NtCreateFile or NtOpenFile
On 8/24/20, Rob Cliffe wrote:
>
> Are you suggesting something I could do in Python that would achieve my
> aim of *replacing* one program by another
No, it's not possible with the Windows API. Implementing POSIX exec
would require extensive use of undocumented NT runtime library
functions,
On 8/23/20, Chris Angelico wrote:
> On Mon, Aug 24, 2020 at 7:40 AM dn via Python-list
>
>> As a 'general rule', isn't exec() something to be avoided?
>
> Nope, it's a very important tool. Not for every situation, of course,
> but there are plenty of times when it's the right thing to do.
In
On 8/23/20, Rob Cliffe via Python-list wrote:
>
> Am I missing something? Is there a way in Windows for one Python
> program to "chain" to another (or indeed to any executable) without
> waiting for the latter to finish?
Windows does not implement anything equivalent to the POSIX exec
family of
Eryk Sun added the comment:
I suppose that, in addition to fixing the bug with si.dwFlags, code could be
added to use DETACHED_PROCESS if GetConsoleCP() returns 0 (i.e. the launcher
isn't attached to a console).
--
___
Python tracker
<ht
Eryk Sun added the comment:
Creating the py.exe process with creationflags=DETACHED_PROCESS sets a special
ConsoleHandle value in its ProcessParameters that makes the base API skip
allocating a console session at process startup. However, the launcher itself
spawns python.exe normally
Change by Eryk Sun :
--
status: open -> closed
type: compile error -> behavior
___
Python tracker
<https://bugs.python.org/issue41565>
___
___
Python-bugs-
Eryk Sun added the comment:
It's worth mentioning that pathlib restricts the first character of a Windows
drive name to the set of ASCII letters in
pathlib._WindowsFlavour.drive_letters. For example:
>>> Path('3') / 'C:3'
WindowsPath('C:3')
vs.
>>>
Eryk Sun added the comment:
> I mean，os.path.join('3', '{:3') return '{:3' in windows, However,
> os.path.join('3', '{:3') return '3/{:3'in linux, output result not
> '3' in windows, why?
The implementation of ntpath.join handles "{:" as a drive. Thus "{:3" i
Eryk Sun added the comment:
> I'm not sure if "}" could ever be valid drive letter
The Windows file API is designed in a way to support almost any Unicode BMP
character in a DOS drive designation. For example, the following creates "{:"
as a substit
Eryk Sun added the comment:
> I suspect the Windows version is using some API that strips whitespace
> from the filename before performing a relative path.
When normalizing a path, the Windows API strips trailing dots and spaces from
the final component. Apparently it also strips a
Eryk Sun added the comment:
> Does the same apply for time.monotonic? I would argue that the
> difference in behavior between Linux/macOS and Windows is
> unreasonable; given that time.monotonic exists for measuring time
> intervals
For time.monotonic in Windows, Python
Change by Eryk Sun :
--
components: +Installation
status: open ->
versions: +Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issu
Eryk Sun added the comment:
Managing multiple Python installations in PATH is problematic, so by default
the installer doesn't modify PATH. Instead, the "py.exe" launcher [1] is made
available, which can run any registered installation of Python.
Using a launcher fits t
On 8/1/20, MRAB wrote:
> On 2020-08-01 21:58, Barry wrote:
>> On 31-7-2020 22:10, Tanmay Shah wrote:
>>>
>>> After downloading Python 3.8.5 IDLE, an error message popped up,
>>> saying the code execution cannot proceed because python38.dll was
>>> not found. What should I do in order to use the
Change by Eryk Sun :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> pathlib.Path.resolve(strict=False) returns relative path on
Windows if the entry does not exist
___
Python tra
On 7/30/20, R Pasco wrote:
> access rights must be set to [winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_64KEY
It's a bad practice to request more access than you require, at the
very least because the request may fail with access denied for no good
reason.
KEY_ALL_ACCESS includes all applicable
Eryk Sun added the comment:
Winsock is inherently asynchronous. It implements synchronous functions by
using an alertable wait for the completion of an asynchronous I/O request.
Python doesn't implement anything for a console Ctrl+C event to alert the main
thread when it's blocked
1001 - 1100 of 2741 matches
Mail list logo
