[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
William Woodruff added the comment: Nosying myself; this affects 3.9 and 3.10 as well. -- nosy: +yossarian versions: +Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue14156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46900] marshal.dumps represents the same list object differently
Change by William Dreese : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46900] marshal.dumps represents the same list object differently
William Dreese added the comment: You two are both correct, this is not a bug and is the intended functionality. > The difference between 41 and 169 is 128: This realization helps a ton. Thanks. -- ___ Python tracker <https://bugs.python.org/issue46900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46900] marshal.dumps represents the same list object differently
William Dreese added the comment: I've made a very bad copy & paste error with the terminal output below, I apologize. The corrected output is >>> pp(var_marshaled) 91 2 0 0 0 41 3 233 1 0 0 0 233 2 0 0 0 233 3 0 0 0 41 3 233 4 0 0 0 233 5 0 0 0 233 6 0 0 0 >>> pp(raw_marshaled) 91 2 0 0 0 169 3 233 1 0 0 0 233 2 0 0 0 233 3 0 0 0 169 3 233 4 0 0 0 233 5 0 0 0 233 6 0 0 0 -- ___ Python tracker <https://bugs.python.org/issue46900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46900] marshal.dumps represents the same list object differently
New submission from William Dreese : Hello, I've been working with the marshal package and came across this issue (I think) - Python 3.9.10 Interpreter (Same output in 3.11.0a5+ (heads/master:b6b711a1aa) on darwin) >>> import marshal >>> var_example = [(1,2,3),(4,5,6)] >>> var_marshaled = marshal.dumps(var_example) >>> raw_marshaled = marshal.dumps([(1,2,3),(4,5,6)]) >>> def pp(to_print): >>> [print(byt) for byt in to_print] >>> pp(var_marshaled) 219 2 0 0 0 41 3 233 1 0 0 0 233 2 0 0 0 233 3 0 0 0 169 3 233 4 0 0 0 233 5 0 0 0 233 6 0 0 0 91 2 0 0 0 41 3 233 1 0 0 0 233 2 0 0 0 233 3 0 0 0 169 3 233 4 0 0 0 233 5 0 0 0 233 6 0 0 0 >>> pp(raw_marshaled) 219 2 0 0 0 169 3 233 1 0 0 0 233 2 0 0 0 233 3 0 0 0 169 3 233 4 0 0 0 233 5 0 0 0 233 6 0 0 0 91 2 0 0 0 169 3 233 1 0 0 0 233 2 0 0 0 233 3 0 0 0 169 3 233 4 0 0 0 233 5 0 0 0 233 6 0 0 0 The difference above lies in the byte representation of the tuple type (41 in the variable version and 169 in the raw version). Is this intended behavior? -- components: C API messages: 414362 nosy: Dreeseaw priority: normal severity: normal status: open title: marshal.dumps represents the same list object differently type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46275] caret location for syntax error pointing with f-strings
William Navaraj added the comment:
The variation in the caret position was also due to the trailing spaces. This
is now sorted in this solution with a factored out function to find out the
correct offset.
https://github.com/python/cpython/compare/main...williamnavaraj:fix-issue-46275?expand=1
Tested against all of the following cases and it works great:
temp=f"blank ({foo()}"+f"blank ({foo(}"+f"blank ({foo()}"
temp=f"blank*{foo(*blank*foo()*blank*foo()}"+f"({foo(}"+f"blank ({foo(}"
a=foo)+foo()+foo()
f"blank ({foo(blank ({foo()}) blank foo()})"
temp=f"blank ({foo)foo2"
temp=f"blank {foo)"
temp=f"blank {foo)"
temp=f"blank ({foo)blank ({foo()}) blank foo()})" yetAnotherBlah
temp=f"blank ({foo)blank ({foo()}) blank foo()})"
yetAnotherBlahWithFurtherSpacesAfter
--
___
Python tracker
<https://bugs.python.org/issue46275>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45723] Improve and simplify configure.ac checks
William Fisher added the comment: In the conversion to PY_CHECK_FUNC, there's a mistake in HAVE_EPOLL. Python 3.10.1 defines HAVE_EPOLL by checking for the `epoll_create` function. Python 3.11.0a3 checks for the `epoll` function instead. There is no epoll() function so this always fails. The effect is that `epoll` doesn't exist in the `select` module on Python 3.11.0a3. Most code that uses epoll falls back when it is not available, so this may not be failing any tests. -- nosy: +byllyfish ___ Python tracker <https://bugs.python.org/issue45723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26571] turtle regression in 3.5
William Navaraj added the comment: Hi all, Sorry. I seem to have stepped on someone's toes or no one likes turtle any more (as this is active since 2016). As you can see, I am new here and still getting a feel for these procedures. I was preparing a Jupyter notebook for my students. I planned some exercises with turtle at start before we jump into real robots. I noticed this annoying Terminator error, digged deeper into the code to find about the _RUNNING class variable. The PR from Furkan suggest to remove the Raise Terminator. May be we could amend that and I will close my PR, if you prefer. Thanks, -- ___ Python tracker <https://bugs.python.org/issue26571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46275] caret location for syntax error pointing with f-strings
William Navaraj added the comment:
A potential solution or in that direction
https://github.com/williamnavaraj/cpython/tree/fix-issue-46275
Example 1:
```
temp=f"blank {foo)"
```
temp=f"blank {foo)"
^
SyntaxError: f-string: unmatched ')'
Example 2:
```
temp=f"blank ({foo)foo2"
```
temp=f"blank ({foo)foo2"
^
SyntaxError: f-string: unmatched ')'
Example 3:
```
temp=f"blank ({foo)blank ({foo()}) blank foo()})"
```
temp=f"blank ({foo)blank ({foo()}) blank foo()})"
^
SyntaxError: f-string: unmatched ')'
--
___
Python tracker
<https://bugs.python.org/issue46275>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46275] caret location for syntax error pointing with f-strings
New submission from William Navaraj :
Currently for non-f-string syntax errors,
the caret points to the correct location of the syntax errors
Example 1:
```
a=foo)+foo()+foo()
```
a=foo)+foo()+foo()
^
SyntaxError: unmatched ')'
For f-string syntax errors,
the caret points two locations after the f-string (almost correct location of
the f-strings as a whole but will be more helpful as much as possible to point
where exactly the syntax error is)
Example 2:
```
temp=f"blank ({foo(}"
```
temp=f"blank ({foo(}"
^
SyntaxError: f-string: closing parenthesis '}' does not match opening
parenthesis '('
Example 3:
```
temp=f"blank ({foo)blank ({foo()}) blank foo()})"
```
temp=f"blank ({foo)blank ({foo()}) blank foo()})"
^
SyntaxError: f-string: unmatched ')'
--
components: Parser
messages: 409813
nosy: lys.nikolaou, pablogsal, williamnavaraj
priority: normal
severity: normal
status: open
title: caret location for syntax error pointing with f-strings
versions: Python 3.11, Python 3.8
___
Python tracker
<https://bugs.python.org/issue46275>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46260] Misleading SyntaxError on f-string
William Navaraj added the comment:
@Eric Smith,Thanks for explaining the intuition behind this statement. I agree.
Just to avoid ambiguity we could add
"f-string: unmatched '%c' - no matching open parenthesis or missing '}'"
The only possibility at nested_depth==0 line 665 is either of those because of
the check in line 559 i.e. assert(**str == '{')
https://github.com/python/cpython/blob/cae55542d23e606dde9819d5dadd7430085fcc77/Parser/string_parser.c#L559
Will help folks to look backwards (close to open as well) than forwards (open
to close) as in Matt's case which is also a valid interpretation where there is
an opening paren outside the f-string.
or simply
"f-string: unmatched '%c' or missing '}'" will also do.
--
nosy: +williamnavaraj
___
Python tracker
<https://bugs.python.org/issue46260>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26571] turtle regression in 3.5
Change by William Navaraj : -- nosy: +williamnavaraj nosy_count: 6.0 -> 7.0 pull_requests: +28569 pull_request: https://github.com/python/cpython/pull/30355 ___ Python tracker <https://bugs.python.org/issue26571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45900] Type annotations needed for convenience functions in ipaddress module
Change by William George : -- keywords: +patch pull_requests: +28015 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29778 ___ Python tracker <https://bugs.python.org/issue45900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45900] Type annotations needed for convenience functions in ipaddress module
New submission from William George : The convenience factory functions in the ipaddress module each return one of two types (IPv4Network vs IPv6Network, etc). Modern code wants to be friendly to either stack, and these functions are great at enabling that, but current implementation blocks type inference for most (all?) IDEs. Proposal is easy enough, specifying return type of e.g. `Union[IPv4Network, IPv6Network]` for these factory functions. I believe the rest of the public interface for this module is unambiguous enough that annotations aren't needed, but if others see value they could be added easily enough. For some of these there exists a version-independent base class that could be referenced instead of a union, but it's not clear to me how well IDEs will actually honor such an annotation referencing an internal class (single-underscore). My limited testing of that didn't work well and there's no such base class for the Interface classes anyway. PR for this incomming. -- components: Library (Lib) messages: 407005 nosy: pmoody, wrgeorge1983 priority: normal severity: normal status: open title: Type annotations needed for convenience functions in ipaddress module type: enhancement versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
William Fisher added the comment: asyncio.MultiLoopChildWatcher has two problems that create a race condition. 1. The SIGCHLD signal handler does not guard against interruption/re-entry. 2. The SIGCHLD signal handler can interrupt add_child_handler's `self._do_waitpid(pid)`. Symptoms: Log messages that look like this: 1634935451.761 WARNING Unknown child process pid 8747, will report returncode 255 ... 1634935451.762 WARNING Child watcher got an unexpected pid: 8747 Traceback (most recent call last): File "/Users/runner/hostedtoolcache/Python/3.9.7/x64/lib/python3.9/asyncio/unix_events.py", line 1306, in _do_waitpid loop, callback, args = self._callbacks.pop(pid) KeyError: 8747 Background: I've been working on a library to make calling asyncio subprocesses more convenient. As part of my testing, I've been stress testing asyncio using different child watcher policies. My CI build runs more than 200 tests each on macOS, Linux and FreeBSD. I've noticed a small percentage of sporadic failures using MultiLoopChildWatcher. My understanding of Python signal functions is that: 1. Upon receipt of a signal, the native "C" signal handler sets a flag that indicates the signal arrived. 2. The main thread checks the signal flags after each bytecode instruction. If a signal flag is set, Python saves the call stack, runs the signal handler on the main thread immediately, then pops the stack when it returns (assuming no exception raised by signal handler). 3. If you are in the middle of a signal handler running on the main thread and Python detects another signal flag, your signal handler can be interrupted. 4. Stacked signal handlers run in LIFO order. The last one that enters will run to completion without interruption. Explanation: I wrapped MultiLoopChildWatcher's sig_chld function in a decorator that logs when it is entered and exited. This clearly shows that _sig_chld is being re-entered. In the following log snippet, I'm running two commands in a pipeline "tr | cat". 1634935451.743 DEBUG process '/usr/bin/tr' created: pid 8747 ... 1634935451.746 DEBUG process '/bin/cat' created: pid 8748 ... 1634935451.761 DEBUG enter '_sig_chld' 20 1634935451.761 DEBUG enter '_sig_chld' 20 1634935451.761 WARNING Unknown child process pid 8747, will report returncode 255 1634935451.762 DEBUG process 8748 exited with returncode 0 1634935451.762 DEBUG exit '_sig_chld' 20 1634935451.762 WARNING Child watcher got an unexpected pid: 8747 Traceback (most recent call last): File "/Users/runner/hostedtoolcache/Python/3.9.7/x64/lib/python3.9/asyncio/unix_events.py", line 1306, in _do_waitpid loop, callback, args = self._callbacks.pop(pid) KeyError: 8747 1634935451.763 WARNING Unknown child process pid 8748, will report returncode 255 1634935451.763 WARNING Child watcher got an unexpected pid: 8748 Traceback (most recent call last): File "/Users/runner/hostedtoolcache/Python/3.9.7/x64/lib/python3.9/asyncio/unix_events.py", line 1306, in _do_waitpid loop, callback, args = self._callbacks.pop(pid) KeyError: 8748 1634935451.763 DEBUG exit '_sig_chld' 20 Here is the breakdown of what happens: 1. Pid 8747 exits and we enter _sig_chld #1. 2. sig_chld #1 calls os.waitpid which gives (pid, status) = (8747, 0). 3. Before sig_chld #1 has a chance to call `self._callbacks.pop(pid)`, it is interrupted. 4. sig_chld #2 calls os.waitpid for pid 8747. We get a ChildProcessError and then "Unknown child process pid 8747, will report returncode 255" 5. sig_chld #2 invokes the callback for pid 8747 saying the returncode=255. 6. sig_chld #2 continues to completion. It reaps pid 8748 normally. 7. sig_chld #1 picks up where it left off. We get an error when we try to pop the callback for 8747. 8. sig_chld #1 calls os.waitpid for pid 8748. This gives us failure messages because it was done by sig_chld #2. The issue of interruption can also happen in the case of running a single process. If the _sig_chld interrupts the call to `self._do_waitpid(pid)` in add_child_watcher, a similar interleaving can occur. Work-Around: In my tests, I patched MultiLoopChildWatcher and so far, it appears to be more reliable. In add_child_handler, I call raise_signal(SIGCHLD) so that all the work is done in the signal handler. class PatchedMultiLoopChildWatcher(asyncio.MultiLoopChildWatcher): "Test race condition fixes in MultiLoopChildWatcher." def add_child_handler(self, pid, callback, *args): loop = asyncio.get_running_loop() self._callbacks[pid] = (loop, callback, args) # Prevent a race condition in case signal was delivered before # callback added. signal.raise_signal(signal.SIGCHLD) @_serialize def _sig_chld(self, signum, frame): super()._sig_chld(signum, frame) _serialize is a decorator that looks like this: def _serialize(func): """Decorator to se
[issue45718] asyncio: MultiLoopWatcher has a race condition (Proposed work-around)
William Fisher added the comment: Thanks, I will comment on bpo-38323 directly. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45718] asyncio: MultiLoopWatcher has a race condition (Proposed work-around)
New submission from William Fisher : Summary: asyncio.MultiLoopChildWatcher has two problems that create a race condition. 1. The SIGCHLD signal handler does not guard against interruption/re-entry. 2. The SIGCHLD signal handler can interrupt add_child_handler's `self._do_waitpid(pid)`. This is a continuation of bpo-38323. That issue discussed two bugs. This issue proposes a work-around for one of them that may be useful in making build tests more reliable. I'm reserving discussion to the case of a single asyncio event loop on the main thread. (MultiLoopChildWatcher has a separate "signal-delivery-blocked" problem when used in an event loop that is not in the main thread as mentioned in bpo-38323.) Symptoms: Log messages that look like this: 1634935451.761 WARNING Unknown child process pid 8747, will report returncode 255 ... 1634935451.762 WARNING Child watcher got an unexpected pid: 8747 Traceback (most recent call last): File "/Users/runner/hostedtoolcache/Python/3.9.7/x64/lib/python3.9/asyncio/unix_events.py", line 1306, in _do_waitpid loop, callback, args = self._callbacks.pop(pid) KeyError: 8747 Background: I've been working on a library to make calling asyncio subprocesses more convenient. As part of my testing, I've been stress testing asyncio using different child watcher policies. My CI build runs more than 200 tests each on macOS, Linux and FreeBSD. I've noticed a small percentage of sporadic failures using MultiLoopChildWatcher. My understanding of Python signal functions is that: 1. Upon receipt of a signal, the native "C" signal handler sets a flag that indicates the signal arrived. 2. The main thread checks the signal flags after each bytecode instruction. If a signal flag is set, Python saves the call stack, runs the signal handler on the main thread immediately, then pops the stack when it returns (assuming no exception raised by signal handler). 3. If you are in the middle of a signal handler running on the main thread and Python detects another signal flag, your signal handler can be interrupted. 4. Stacked signal handlers run in LIFO order. The last one that enters will run to completion without interruption. Explanation: I wrapped MultiLoopChildWatcher's sig_chld function in a decorator that logs when it is entered and exited. This clearly shows that _sig_chld is being re-entered. In the following log snippet, I'm running two commands in a pipeline "tr | cat". 1634935451.743 DEBUG process '/usr/bin/tr' created: pid 8747 ... 1634935451.746 DEBUG process '/bin/cat' created: pid 8748 ... 1634935451.761 DEBUG enter '_sig_chld' 20 1634935451.761 DEBUG enter '_sig_chld' 20 1634935451.761 WARNING Unknown child process pid 8747, will report returncode 255 1634935451.762 DEBUG process 8748 exited with returncode 0 1634935451.762 DEBUG exit '_sig_chld' 20 1634935451.762 WARNING Child watcher got an unexpected pid: 8747 Traceback (most recent call last): File "/Users/runner/hostedtoolcache/Python/3.9.7/x64/lib/python3.9/asyncio/unix_events.py", line 1306, in _do_waitpid loop, callback, args = self._callbacks.pop(pid) KeyError: 8747 1634935451.763 WARNING Unknown child process pid 8748, will report returncode 255 1634935451.763 WARNING Child watcher got an unexpected pid: 8748 Traceback (most recent call last): File "/Users/runner/hostedtoolcache/Python/3.9.7/x64/lib/python3.9/asyncio/unix_events.py", line 1306, in _do_waitpid loop, callback, args = self._callbacks.pop(pid) KeyError: 8748 1634935451.763 DEBUG exit '_sig_chld' 20 Here is the breakdown of what happens: 1. Pid 8747 exits and we enter _sig_chld #1. 2. sig_chld #1 calls os.waitpid which gives (pid, status) = (8747, 0). 3. Before sig_chld #1 has a chance to call `self._callbacks.pop(pid)`, it is interrupted. 4. sig_chld #2 calls os.waitpid for pid 8747. We get a ChildProcessError and then "Unknown child process pid 8747, will report returncode 255" 5. sig_chld #2 invokes the callback for pid 8747 saying the returncode=255. 6. sig_chld #2 continues to completion. It reaps pid 8748 normally. 7. sig_chld #1 picks up where it left off. We get an error when we try to pop the callback for 8747. 8. sig_chld #1 calls os.waitpid for pid 8748. This gives us failure messages because it was done by sig_chld #2. The issue of interruption can also happen in the case of running a single process. If the _sig_chld interrupts the call to `self._do_waitpid(pid)` in add_child_watcher, a similar interleaving can occur. Work-Around: In my tests, I patched MultiLoopChildWatcher and so far, it appears to be more reliable. In add_child_handler, I call raise_signal(SIGCHLD) so that all the work is done in the signal handler. class PatchedMultiLoopChildWatcher(asyncio.MultiLoopChildWatcher): "Test race condition fixes in MultiLoopChildWatcher." def add_child_handler(self, pid, callback, *args)
[issue45257] Compiling 3.8 branch on Windows attempts to use incompatible libffi version
William Proffitt added the comment: Ah yes, thank you Steve. I see the commit you're referencing is the cherry pick from upstream onto the 3.8 branch, but it's newer than the tag 3.8.12 I was using. Looks like I won't have to do anything if I wait until 3.8.13 before doing this again. This is good. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45257] Compiling 3.8 branch on Windows attempts to use incompatible libffi version
New submission from William Proffitt : Wasn't sure where to file this. I built Python 3.8.12 for Windows recently from the latest bugfix source release in the cpython repository. One tricky thing came up I wanted to write-up in case it matters to someone else. The version of libffi in the cpython-bin-deps repository seems to be too new for Python 3.8.12 now. The script for fetching the external dependencies (PCBuild\get_externals.bat) on the 3.8 branch fetches whatever is newest on the libffi branch, and this led to it downloading files starting with "libffi-8" and the build complaining about being unable to locate "libffi-7". I managed to resolve this by manually replacing the fetched libffi in the externals directory with the one from this commit, the latest commit I could find where the filenames started with "libffi-7": https://github.com/python/cpython-bin-deps/commit/1cf06233e3ceb49dc0a73c55e04b1174b436b632 After that, I was able to successfully run "build.bat -e -p x64" in PCBuild and "build.bat -x64" in "Tools\msi\" and end up with a working build and a working installer. (Side note that isn't that important for me but maybe worth mentioning while I'm here: the uninstaller on my newly minted installer didn't seem to work at all and I had to manually resort to deleting registry keys to overwrite my previous attempted install.) -- components: Build, Installation, Windows, ctypes messages: 402318 nosy: paul.moore, proffitt, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Compiling 3.8 branch on Windows attempts to use incompatible libffi version type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue45257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45074] asyncio hang in subprocess wait_closed() on Windows, BrokenPipeError
New submission from William Fisher : I have a reproducible case where stdin.wait_closed() is hanging on Windows. This happens in response to a BrokenPipeError. The same code works fine on Linux and MacOS. Please see the attached code for the demo. I believe the hang is related to this debug message from the logs: DEBUG <_ProactorWritePipeTransport closing fd=632>: Fatal write error on pipe transport Traceback (most recent call last): File "C:\hostedtoolcache\windows\Python\3.9.6\x64\lib\asyncio\proactor_events.py", line 379, in _loop_writing f.result() File "C:\hostedtoolcache\windows\Python\3.9.6\x64\lib\asyncio\windows_events.py", line 812, in _poll value = callback(transferred, key, ov) File "C:\hostedtoolcache\windows\Python\3.9.6\x64\lib\asyncio\windows_events.py", line 538, in finish_send return ov.getresult() BrokenPipeError: [WinError 109] The pipe has been ended It appears that the function that logs "Fatal write error on pipe transport" also calls _abort on the stream. If _abort is called before stdin.close(), everything is okay. If _abort is called after stdin.close(), stdin.wait_closed() will hang. Please see issue #44428 for another instance of a similar hang in wait_closed(). -- components: asyncio files: wait_closed.py messages: 400810 nosy: asvetlov, byllyfish, yselivanov priority: normal severity: normal status: open title: asyncio hang in subprocess wait_closed() on Windows, BrokenPipeError type: behavior versions: Python 3.10, Python 3.9 Added file: https://bugs.python.org/file50250/wait_closed.py ___ Python tracker <https://bugs.python.org/issue45074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45008] asyncio.gather should not "dedup" awaitables
New submission from William Fisher : asyncio.gather uses a dictionary to de-duplicate futures and coros. However, this can lead to problems when you pass an awaitable object (implements __await__ but isn't a future or coro). 1. Two or more awaitables may compare for equality/hash, but still expect to produce different results (See the RandBits class in gather_test.py) 2. If an awaitable doesn't support hashing, asyncio.gather doesn't work. Would it be possible for non-future, non-coro awaitables to opt out of the dedup logic? The attached file shows an awaitable RandBits class. Each time you await it, you should get a different result. Using gather, you will always get the same result. -- components: asyncio files: gather_test.py messages: 400309 nosy: asvetlov, byllyfish, yselivanov priority: normal severity: normal status: open title: asyncio.gather should not "dedup" awaitables type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file50236/gather_test.py ___ Python tracker <https://bugs.python.org/issue45008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13788] os.closerange optimization
William Manley added the comment: Linux has a close_range syscall since v5.9 (Oct 2020): https://man7.org/linux/man-pages/man2/close_range.2.html -- nosy: +wmanley ___ Python tracker <https://bugs.python.org/issue13788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] [C API] Make PyObject an opaque structure in the limited C API
William Pickard added the comment: MSVC by default disables method inlining (/Ob0) when '/Od' is specified on the command line while the optimization options specify '/Ob2'. -- ___ Python tracker <https://bugs.python.org/issue39573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44216] Bug in class method with optional parameter
William Pickard added the comment:
This is not a bug but a side-affect at how defaulted parameters are stored. The
rule of thumb is to never use mutable values as default values for parameters.
When a method is created in the Python runtime, it checks if the signature has
defaulted keyword arguments. If it does, it executes the expression to retrieve
the value for the arguments and stores the results internally.
When you go and execute the method with these arguments missing, Python
retrieves a reference the the generated value and provides your method with
that. This is your issue as you're modifying the same object with every call to
the method.
The proper way to do this is this:
def do_something(self, a, b=None):
b = b if b is not None else []
b.append(a)
print('b contains', b)
--
nosy: +WildCard65
___
Python tracker
<https://bugs.python.org/issue44216>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44208] argparse: Accept option without needing to distinguish "-" from "_" in arg_string
William Barnhart added the comment:
I'm glad someone else thinks it's a good idea. If you have some ideas for
tests, I'd be happy to help write them in order to spare the inconvenience
(unless the tests are that easy to write then by all means please do).
I can appreciate why the core developers could be polarized. One side could say
it's safer to just take better care of our Python scripts and have them in
wrapper functions. But people don't always do this.
In favor of the idea: This method can be used to spare developers from agony
when a "_" is changed to a "-" when they aren't informed of the change. As a
result, this can allow for code to remain usable since most developers are more
interested in the letters of arguments and not so much special characters. But
then again, a --help option could be all that's needed to fix this issue.
I think a solution that satisfies both parties would be creating some safe
guard for adding arguments that are named identically, containing "_" or "-" in
the middle, and raising an exception when the regexes of the arguments are
conflicting. Such as if I wrote:
```
parser.add_argument('--please_work')
parser.add_argument('--please-work')
```
then an exception should be raised with an error for conflicting argument names.
--
___
Python tracker
<https://bugs.python.org/issue44208>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44208] argparse: Accept option without needing to distinguish "-" from "_" in arg_string
Change by William Barnhart : -- keywords: +patch pull_requests: +24899 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26295 ___ Python tracker <https://bugs.python.org/issue44208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44208] argparse: Accept option without needing to distinguish "-" from "_" in arg_string
New submission from William Barnhart :
An issue I encountered recently with argparse was when I tried running a script
with its argument changed from something like:
```
parser.add_argument('--please_work')
```
and was replaced with:
```
parser.add_argument('--please-work')
```
I have not ever seen anyone add an argument where a function has two arguments
existing in a function, such as please_work and please-work. I think this is a
pretty safe feature to implement, plus it enforces good practices. So if I
wrote something such as:
```
parser = argparse.ArgumentParser(description="check this out")
parser.add_argument('--please-work')
```
Then I could call the program using:
```
python3 test.py --please_work True
```
or:
```
python3 test.py --please-work True
```
--
components: Library (Lib)
messages: 394135
nosy: wbarnha
priority: normal
severity: normal
status: open
title: argparse: Accept option without needing to distinguish "-" from "_" in
arg_string
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue44208>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44185] mock_open file handle __exit__ does not call close
New submission from William Sjoblom : A common testing scenario is assuring that opened files are closed. Since unittest.mock.mock_open() can be used as a context manager, it would be reasonable to expect its __exit__ to invoke close so that one can easily assert that the file was closed, regardless of if the file was opened with a plain call to open or with a context manager. -- components: Library (Lib) messages: 394005 nosy: williamsjoblom priority: normal severity: normal status: open title: mock_open file handle __exit__ does not call close type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38552] Colored Prompt broken in REPL in Windows in 3.8
William Minchin added the comment: I can't reproduce this today: Python 3.8.6 (or 3.9.5) with PowerShell 7.1.3 on Windows 10 with Windows Terminal. Maybe it got fixed by a bugfix release of Python 3.8? I'll close it for now. c.f. https://github.com/tartley/colorama/issues/233 -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] "Building C and C++ Extensions on Windows" docs are very out-of-date
William Pickard added the comment: Correction: You can use either VsDevCmd.bat/Enter-VsDevShell on VS versions that provide them (2017 and 2019 are known to include it), but to get the x64 tools you need to pass command line arguments (They default to x86 native tools). Otherwise you must use either vcvarsall.cmd and pass the appropriate command line arguments or vcvarsx86_amd64.bat/vcvars64.bat -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] "Building C and C++ Extensions on Windows" docs are very out-of-date
William Pickard added the comment: Then it appears you're using a version of the compiler that is built for building 32-bit exes/dlls, you need to use the x64 version. For this you need to start either the x86 Cross Tools console or the x64 native console (VS 2019) or use vcvarsall.cmd/Enter-VsDevShell (PowerShell) -- ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43804] "Building C and C++ Extensions on Windows" docs are very out-of-date
William Pickard added the comment: I'm quite familiar with MSVC's command line and I'm quite confused on what you mean "the above commands are specific to 32-bit Python" "/LD" is available for both 32-bit and 64-bit compilations, it implies "/MT" to the compiler and "/DLL" to the linker. "/I" is available for both 32-bit and 64-bit compilations. Python's lib files are named exactly the same between 32-bit and 64-bit versions. The only thing platform specific in MSVC is the compiler. Visual Studio's C/C++ build tools ships with 4 variants of MSVC: 2 32-bit versions, 1 for targeting 32-bit and the other for targeting 64-bit (32-bit native, 32-bit cross compile to 64-bit) The same is true for the 64-bit versions (64-bit native and 64-bit cross compile to 32-bit) Internally, these are known as: x86, x86_x64, x64, x64_x86 -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue43804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44046] When writing to the Registry using winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.
William Pickard added the comment: Here's something you should know about Windows, even if a local account is in the Administrators group, it still has restrictions on what it can do, it just has the power to elevate itself without requiring login credentials (VIA UAC prompts). This group functions very similar to the sudoers group in Linux. I expect that disabling UAC only causes Windows to automatically approve them on Administrator accounts and deny on non-Administrator accounts for applications that explicitly require the prompt (Run as Administrator special flag). There exists a hidden deactivated account called Administrator in Windows that functions very similar to root in Linux. UAC prompts are to allow an application to run under a temporary Windows Logon session as this hidden account while using your logon session, aka elevation. -- ___ Python tracker <https://bugs.python.org/issue44046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44046] When writing to the Registry using winreg, it currently allows you to write ONLY to HKEY_CURRENT_USERS.
William Pickard added the comment: Do you mind ticking the box, "Run as Administrator" in the Compatibility tab for python.exe and try winreg again? -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue44046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43866] Installation files of the Python
William Pickard added the comment: Python, when installed for all users, installs to %ProgramFiles% (or %ProgramFiles(x86)% for 32-bit version on 64-bit Windows). The %LocalAppData% install is just for you... you didn't install it for everyone or you didn't provide Python with the Administrator privileges it needs for %ProgramFiles% (IE: No process elevation) -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue43866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15795] Zipfile.extractall does not preserve file permissions
Change by William Woodruff : -- nosy: +yossarian ___ Python tracker <https://bugs.python.org/issue15795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43776] Popen with shell=True yield mangled repr output
William Pickard added the comment: Actually, the problem is independent of the value of "shell", the __repr__ function from the initial PR that introduced it expects "args" to be a sequence and converts it to a list. -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue43776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38794] Setup: support linking openssl statically
William Woodruff added the comment: I don't think this is a productive or polite response. If you read the issue linked, you'll note that the other flag added (--with-openssl-rpath) is in furtherance of any *already* supported linking scenario (dynamic, with a non-system-default OpenSSL). The proposed change here is for an *new* linking scenario, i.e. statically linking OpenSSL. I don't blame the maintainers for not wanting to add another build configuration to their plate, especially for something like OpenSSL. It's up to us as end users to make those accommodations on our own, knowing that what we're doing isn't tested or directly supported. The resolution above is, in my book, the ideal one. Best, William On Sat, Apr 03, 2021 at 04:45:34PM +, Lukas Vacek wrote: > > Lukas Vacek added the comment: > > For the record, this would have been solved more than a year ago already. > > When this change was proposed more than a year ago it was rejected with > "There is no need to add more configure flags to build Python with a custom > OpenSSL installation. " yet now it's ok to add a new option > --with-openssl-rpath https://bugs.python.org/issue43466 ? > > And the first comment there, from python core dev nonetheless, is suggesting > static linking as well. Emm... this would have been solved year and half ago. > I would be happy to completely drop my proposed (and approved on gihub) > changes and implement it in a different way. > > The maintainer's attitude as demonstrated here can be really harmful in > open-source projects (many of us still remember eglibc fork back in the day) > but fortunately this is the first time I noticed such attitude among python > developers. > > Importantly the issue is resolved now (did it take a request from IBM's > customer to get this implemented ;-) ?) and hopefully a lesson learnt and > Christian will be more welcoming and less judgemental of outsiders' > contributions. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue38794> > ___ -- ___ Python tracker <https://bugs.python.org/issue38794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43685] __call__ not being called on metaclass
William Pickard added the comment: This line is the cause of your issue: "new_cls: SingletonMeta = cast(SingletonMeta, type(name, bases, namespace))" More specifically, your call to type() actually erases all information about your meta class. If you did "type(S)", you would've seen "type" returned. Replace it with: "new_cls: SingletonMeta = super().__new__(name, bases, namespace)" -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue43685> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43673] Missing stub for logging attribute manager
Change by William (David) Wilcox : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Ann: New Python curses book
I’ve ordered the book (physical volume). It will fulfill a need I’ve had for some time. Unfortunately, it is only available in the UK store, so the shipping cost by far outweighs the book’s cost. Hope for other’s sake, it migrates to the other Amazon stores fairly quickly. Thanks, Bill > On Mar 30, 2021, at 7:12 AM, Alan Gauld via Python-list > wrote: > > I've just published, in Kindle and paperback formats, > my book on "Programming curses with Python". > > https://www.amazon.co.uk/dp/B091B85B77/ > > (It should be available in most other Amazon stores too) -- https://mail.python.org/mailman/listinfo/python-list
[issue43673] Missing stub for logging attribute manager
Change by William (David) Wilcox : -- components: Library (Lib) nosy: wdwilcox priority: normal severity: normal status: open title: Missing stub for logging attribute manager type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43661] api-ms-win-core-path-l1-1.0.dll, redux of 40740 (which has since been closed)
William Pickard added the comment: Python 3.9 does not support Windows 7, it's explicitly stated in the release notes of 3.9.0 -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue43661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38794] Setup: support linking openssl statically
William Woodruff added the comment: Cheers! No promises about not using the hack, but I *will* promise not to complain if it doesn't work for me :-) -- ___ Python tracker <https://bugs.python.org/issue38794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38794] Setup: support linking openssl statically
William Woodruff added the comment: Not to butt in too much, but I have a related use case that would benefit from being able to statically link to OpenSSL: I have an environment in which dynamic modules are acceptable, but where the entire Python install benefits from being relocatable and used on different hosts with the same *basic* state (same glibc, etc). OpenSSL isn't one of those pieces of basic state (for bad reasons, but ones that I can't control), so having a Python distribution that links it statically would save me some amount of complexity. I realize this introduces a significant support burden, and that dealing with myraid OpenSSL configurations is already a pain. So I'm content to shoulder this as my own local build patch -- I'm only following up to note another use case that might benefit from a full-fledged `configure` option, should this ever get re-visited. -- nosy: +yossarian ___ Python tracker <https://bugs.python.org/issue38794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43181] Python macros don’t shield arguments
William Pickard added the comment: This feels like it's more of an issue with the C++ compiler you're using. (I can tell it's C++ because of template syntax) -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue43181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43122] Python Launcher doesn't open a terminal window
William Pickard added the comment: That quick flash would be your terminal window if I have to guess (based on no Mac experience, but Windows). -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue43122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How do you debug in Python? Coming from a Matlab and R user. I'm already aware of pdb.
> On Jan 26, 2021, at 2:00 PM, C W wrote: > > Hello everyone, > > I'm a long time Matlab and R user working on data science. How do you > troubleshooting/debugging in Python? > Another approach is to run the code in an IDE. I happen to use Wing, but that is a coincidence. But almost ANY IDE will let you set a break point, then single-step through your code starting at the break point and examine the values of your variables at each step. Sometimes this is an awfully big hammer for what is a head-slapping mistake. But it has never failed me. Good luck, Bill -- https://mail.python.org/mailman/listinfo/python-list
[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
William Schwartz added the comment: >For a new process group, the cancel event is initially ignored, but the break >event is always handled. To enable the cancel event, the process must call >SetConsoleCtrlHandler(NULL, FALSE), such as via ctypes with >kernel32.SetConsoleCtrlHandler(None, False). I think the signal module should >provide a function to enable/disable Ctrl+C handling without ctypes, and >implicitly enable it when setting a new SIGINT handler. That's what Lib/test/win_console_handler.py:39 does. What I don't understand is why that's necessary. Isn't that what PyConfig.install_signal_handlers is supposed to do? Which brings me to how I ended up here in the first place: I wanted to write a test that PyConfig.install_signal_handlers is set in an embedded instance of Python I'm working with. In outline, the following test works on both Windows and macOS *except on Windows running under Tox*. @unittest.removeHandler def test_signal_handlers_installed(self): SIG = signal.SIGINT if sys.platform == 'win32': SIG = signal.CTRL_C_EVENT with self.assertRaises(KeyboardInterrupt): os.kill(os.getpid(), SIG) if sys.platform == 'win32': time.sleep(.1) # Give handler's thread time to join Using SetConsoleCtrlHandler if I detect that I'm running on Windows under Tox would, if I understand correctly, hide whether PyConfig.install_signal_handlers was set before the Python I'm running in started, right? (I know this isn't the right venue for discussing my embedding/testing problem. But maybe the use case informs the pending discussion of what to do about os.kill's semantics.) -- ___ Python tracker <https://bugs.python.org/issue42962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
William Schwartz added the comment: > Fixing the SystemError should be simple. Just clear an existing error if > TerminateProcess() succeeds. Should there be a `return NULL;` between these two lines? https://github.com/python/cpython/blob/e485be5b6bd5fde97d78f09e2e4cca7f363763c3/Modules/posixmodule.c#L7854-L7855 I'm not the best person to work on a patch for this. -- ___ Python tracker <https://bugs.python.org/issue42962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
William Schwartz added the comment: > In Windows, os.kill() is a rather confused function. I know how it feels. To be honest, I don't have an opinion about whether the steps I laid out ought to work. I just reported it because the SystemError indicates that a C-API function was returning non-NULL even after PyErr_Occurred() returns true. I think that's what you're referring to here... > it doesn't clear the error that was set as a result of the > GenerateConsoleCtrlEvent() call, which causes SystemError to be raised. ...but I lost you on where that's happening and why. Frankly, Windows IPC is not in my wheelhouse. >> Oddly, `echo %errorlevel%` will print `0` rather than `-1073741510` > > There's nothing odd about that. Here's why I thought it was odd. The following session is from the Windows Command shell inside *Command Prompt* (not Windows Terminal): C:\Users\wksch>python --version Python 3.9.1 C:\Users\wksch>python -c"import os, signal, time; os.kill(os.getpid(), signal.CTRL_C_EVENT); time.sleep(1)" Traceback (most recent call last): File "", line 1, in KeyboardInterrupt ^C C:\Users\wksch>echo %errorlevel% -1073741510 In the Windows Command shell inside *Windows Terminal* (not Command Prompt): C:\Users\wksch>python -c"import os, signal, time; os.kill(os.getpid(), signal.CTRL_C_EVENT); time.sleep(1)" C:\Users\wksch>echo %errorlevel% 0 C:\Users\wksch>python -c"raise KeyboardInterrupt" Traceback (most recent call last): File "", line 1, in KeyboardInterrupt ^C C:\Users\wksch>echo %errorlevel% -1073741510 -- ___ Python tracker <https://bugs.python.org/issue42962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
New submission from William Schwartz :
I don't have an automated test at this time, but here's how to get os.kill to
raise SystemError. I did this on Windows 10 version 20H2 (build 19042.746) with
Pythons 3.7.7, 3.8.5, and 3.9.1. os_kill_impl at Modules/posixmodule.c:7833
does not appear to have been modified recently (but I haven't checked its
transitive callees), so I imagine you can get the same behavior from os.kill on
Python 3.10.
1. Open two consoles, A and B. (I'm using tabs in Windows Terminal, if that
matters.)
2. In console A, type but DO NOT EXECUTE the following command:
python -c"import os, signal; os.kill(, signal.CTRL_C_EVENT)"
Move your cursor back before the comma.
3. In console B, create a process that does nothing but print its process
identifier and wait long enough for you to type it in console A:
python -c"import os, time; print(os.getpid()); time.sleep(60); print('exiting
cleanly')"
Copy or remember the printed PID. Hurry to step 4 before your 60 seconds
expires!
4. In console A, type the PID from console B and execute the command.
5. In console B, confirm that the Python exited without printing "exiting
cleanly". Oddly, `echo %errorlevel%` will print `0` rather than `-1073741510`
(which is `2**32 - 0xc13a`, the CTRL_C_EVENT exit code), which is what it
prints after `python -c"raise KeyboardInturrupt"`.
6. In console A, you should see the following traceback.
OSError: [WinError 87] The parameter is incorrect
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "", line 1, in
SystemError: returned a result with an error set
--
components: Extension Modules, Windows
messages: 385235
nosy: William.Schwartz, ncoghlan, paul.moore, petr.viktorin, steve.dower,
tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42962>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42887] 100000 assignments of .__sizeof__ cause a segfault on del
William Pickard added the comment:
Jumping in here to explain why '__class' doesn't crash when '__sizeof__' does:
When '__class__' is fetched, it returns a new reference to the object's type.
When '__sizeof__' is fetched on the otherhand, a new object is allocated on the
heap ('types.MethodType') and is returned to the caller.
This object also has a '__sizeof__' that does the same (as it's implemented on
'object'.
So yes, you are exhausting the C runtime stack by de-allocating over a THOUSAND
objects.
You can see this happen by watching the memory usage of Python steadily climb.
--
nosy: +WildCard65
___
Python tracker
<https://bugs.python.org/issue42887>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
William Schwartz added the comment: > For that, please submit a PR to importlib_resources and it will get synced to > CPython later. Will do once PR 23611 gets in shape. > Can you tell me more about the use-case that exhibited this undesirable > behavior? Using the [PyOxidizer] "freezer". It compiles Python together with frozen Python code or byte code. > That is, what loader is it that supports `open_binary` but not `is_resource` > and doesn't have a `__origin__`? PyOxidizer's [OxidizedImporter] importer. It [does not set `__file__`] (i.e., `__spec__.origin__ is None`). Its maintainer has resolved some ambiguities in the resources API contract (#36128) [differently from CPython], but I don't think that's related to the issue I ran into. The resource-related functionality of the importer is implemented here (extension module written in Rust): https://github.com/indygreg/PyOxidizer/blob/e86b2f46ed6b449bdb912900b0ac83576ad5ebe9/pyembed/src/importer.rs#L1078-L1269 [PyOxidizer]: https://pyoxidizer.readthedocs.io [OxidizedImporter]: https://pyoxidizer.readthedocs.io/en/v0.10.3/oxidized_importer.html [does not set `__file__`]: https://pyoxidizer.readthedocs.io/en/v0.10.3/oxidized_importer_behavior_and_compliance.html#file-and-cached-module-attributes [unsure about `ResourceReader` semantics]: https://pyoxidizer.readthedocs.io/en/v0.10.3/oxidized_importer_resource_files.html#resource-reader-support -- ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
William Schwartz added the comment: @jaraco Did you have any other questions after my comments in msg382423? Do you think you or someone else could review PR 23611? Thanks! -- ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42529] CPython DLL initialization routine failed from PYC cache file
William Pickard added the comment: I recommend first doing a capture of these functions first, incase Windows is routing some through them: LoadLibrary(Ex)(W|A) W is the Unicode variant while A is the Ascii variant. -- ___ Python tracker <https://bugs.python.org/issue42529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42529] CPython DLL initialization routine failed from PYC cache file
William Pickard added the comment: Msvcp140.dll from what I can find is part of the VS 2015 Redstributable package. -- ___ Python tracker <https://bugs.python.org/issue42529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42529] CPython DLL initialization routine failed from PYC cache file
William Pickard added the comment: I was just expecting only detours for LoadLibraryExW (and variants) to find out which dll failed. -- ___ Python tracker <https://bugs.python.org/issue42529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42529] CPython DLL initialization routine failed from PYC cache file
William Pickard added the comment: https://www.microsoft.com/en-us/research/project/detours/ -- ___ Python tracker <https://bugs.python.org/issue42529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42529] CPython DLL initialization routine failed from PYC cache file
William Pickard added the comment: You may need to inject a LoadLibraryExW detour into your python runtime before _jpype is loaded and output all the library names its requesting. You may need to detour all Load Library functions for maximum coverage. -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue42529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
William Schwartz added the comment: > If the issue has been fixed on Python 3.9 but not on 3.8, then it was likely > a redesign that enabled the improved behavior That appears to be the case: path() shares code with files(). > a redesign that won't be ported back to Python 3.8 and earlier. Nor should it. > In these situations, the best recommendation is often to just rely on > importlib_resources (the backport) for those older Python versions. I do not need the files() API or anything else added in 3.9 at this time. I just need the existing 3.7/3.8 functionality to work as documented. > have you considered using importlib_resources for Python 3.8 and earlier? > That would likely also address the issue and you could adopt it sooner. My application is sensitive to the size of the installed site-packages both in bytes and in just the number of packages. Yes, importlib_resources would very likely solve the problem reported in the OP. However I don't need the files() API, so adding an extra requirement feels like a heavy solution. > To some extent, the behavior you've described could be considered a bug or > could be considered a feature request (add support for path on packages that > have no __spec__.origin). I am not aware whether this limitation was by > design or incidental. I agree there should be a high bar for patching old versions, but I posit that the behavior is an unintentional bug. In particular, I believe the behavior contradicts the documentation. Below I link and quote relevant documentation. The function in question: > importlib.resources.path(package, resource)¶ > ...package is either a name or a module object which conforms to the > Package requirements. https://docs.python.org/3.8/library/importlib.html#importlib.resources.path So we jump to Package: > importlib.resources.Package > The Package type is defined as Union[str, ModuleType]. This means that > where the function describes accepting a Package, you can pass in either a > string or a module. Module objects must have a resolvable > __spec__.submodule_search_locations that is not None. https://docs.python.org/3.8/library/importlib.html#importlib.resources.Package The Package type restricts the types of modules based on __spec__.submodule_search_locations. This suggests to me that the original author thought about which __spec__s to accept and which to reject but chose not to say anything about __spec__.origin, which is documented as possibly being None: > class importlib.machinery.ModuleSpec(...) > ...module.__spec__.origin == module.__file__ Normally “origin” should > be set, but it may be None (the default) which indicates it is unspecified > (e.g. for namespace packages). https://docs.python.org/3.8/library/importlib.html#importlib.machinery.ModuleSpec.origin In particular, __spec__.origin *should* be None in certain situations: > __file__ > __file__ is optional The import system may opt to leave __file__ unset > if it has no semantic meaning (e.g. a module loaded from a database). https://docs.python.org/3.8/reference/import.html#__file__ Taken together, the foregoing passages describe an `import` API in which path() works for all modules that are packages (i.e., __spec__.submodule_search_locations is not None), and in which some packages' __spec__.origin is None. That path() fails in practice to support some packages is therefore a bug not a the absence of a feature. Regardless of whether PR 23611 is accepted, the test that it adds should be added to Python master to guard against regressions. I can submit that as a separate PR. Before I do that, do I need to create a new bpo ticket, or can I just reference this one? -- ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
Change by William Schwartz : -- keywords: +patch pull_requests: +22477 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23611 ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42531] importlib.resources.path() raises TypeError for packages without __file__
New submission from William Schwartz : Suppose pkg is a package, it contains a resource r, pkg.__spec__.origin is None, and p = importlib.resources.path(pkg, r). Then p.__enter__() raises a TypeError in Python 3.7 and 3.8. (The problem has been fixed in 3.9). The error can be demonstrated by running the attached path-test.py. The tracebacks in 3.7 and 3.8 are nearly identical, so I'll just show the 3.8 traceback. 3.8.6 (default, Nov 20 2020, 18:29:40) [Clang 12.0.0 (clang-1200.0.32.27)] Traceback (most recent call last): File "path-test.py", line 19, in p.__enter__() # Kaboom File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/contextlib.py", line 113, in __enter__ return next(self.gen) File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/importlib/resources.py", line 196, in path package_directory = Path(package.__spec__.origin).parent File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 1041, in __new__ self = cls._from_parts(args, init=False) File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 682, in _from_parts drv, root, parts = self._parse_args(args) File "/usr/local/Cellar/python@3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 666, in _parse_args a = os.fspath(a) TypeError: expected str, bytes or os.PathLike object, not NoneType The fix is super simple, as shown below. I'll submit this as a PR as well. diff --git a/Lib/importlib/resources.py b/Lib/importlib/resources.py index fc3a1c9cab..8d37d52cb8 100644 --- a/Lib/importlib/resources.py +++ b/Lib/importlib/resources.py @@ -193,9 +193,11 @@ def path(package: Package, resource: Resource) -> Iterator[Path]: _check_location(package) # Fall-through for both the lack of resource_path() *and* if # resource_path() raises FileNotFoundError. -package_directory = Path(package.__spec__.origin).parent -file_path = package_directory / resource -if file_path.exists(): +file_path = None +if package.__spec__.origin is not None: +package_directory = Path(package.__spec__.origin).parent +file_path = package_directory / resource +if file_path is not None and file_path.exists(): yield file_path else: with open_binary(package, resource) as fp: -- components: Library (Lib) files: path-test.py messages: 382297 nosy: William.Schwartz, brett.cannon priority: normal severity: normal status: open title: importlib.resources.path() raises TypeError for packages without __file__ type: behavior versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file49643/path-test.py ___ Python tracker <https://bugs.python.org/issue42531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42390] Other Python implementations may not expose the module name in datetime type names
William Meehan added the comment: For Python implementations that change the underlying object structure, it's not necessarily possible to recreate the `tp_name` that would be exposed in CPython. The `datetime` ends up in `__module__`, while only the type name ends up in `__name__`. There's no way to tell that the value in `__module__` actually came from `tp_name` in the first place. -- ___ Python tracker <https://bugs.python.org/issue42390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42390] Other Python implementations may not expose the module name in datetime type names
Change by William Meehan : -- keywords: +patch pull_requests: +22237 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23345 ___ Python tracker <https://bugs.python.org/issue42390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42390] Other Python implementations may not expose the module name in datetime type names
New submission from William Meehan : This just requires some changes to test_datetime and test_hash -- ___ Python tracker <https://bugs.python.org/issue42390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42390] Other Python implementations may not expose the module name in datetime type names
Change by William Meehan : -- components: Tests nosy: wmeehan priority: normal severity: normal status: open title: Other Python implementations may not expose the module name in datetime type names versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42315] `python -m` semantics conflict with `__file__`'s being optional
New submission from William Schwartz : `python -m mod` sets `sys.argv[0]` to the `mod.__file__` according to https://docs.python.org/3.9/using/cmdline.html#cmdoption-m > If ["-m"] is given, the first element of sys.argv will be the full path to > the module file (while the module file is being located, the first element > will be set to "-m"). But `__file__` may not exist according to https://docs.python.org/3.9/reference/import.html#__file__ > __file__ is optional. If set, this attribute’s value must be a string. The > import system may opt to leave __file__ unset if it has no semantic meaning > (e.g. a module loaded from a database). More technically, `__spec__.origin` is the source of `__file__`, and the former may be `None`, according to https://docs.python.org/3.9/library/importlib.html#importlib.machinery.ModuleSpec.origin > (__file__) > > Name of the place from which the module is loaded, e.g. “builtin” for > built-in modules and the filename for modules loaded from source. Normally > “origin” should be set, but it may be None (the default) which indicates it > is unspecified (e.g. for namespace packages). `python -m mod` sets sys.argv[0] to `mod.__spec__.origin` at 3.9/Lib/runpy.py:196 It seems clear to me that the code is doing the right thing relative to the documentation for `-m`. But as #26388 and https://github.com/indygreg/PyOxidizer/issues/307 show, embedded Python runs into the semantic conflict with the documented behavior of `__spec__.origin` and `__file__`. My proposed resolution of this contradiction is to set `sys.argv[0] = sys.orig_argv[0]` or, even better, `sys.argv[0] = sys.executable` when `PyConfig.run_module` is set but the named module's `__spec__.origin` is `None`. -- components: Interpreter Core, Library (Lib) messages: 380689 nosy: William.Schwartz, brett.cannon, eric.snow, ncoghlan priority: normal severity: normal status: open title: `python -m` semantics conflict with `__file__`'s being optional type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26388] Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True)
Change by William Schwartz : -- nosy: +William.Schwartz ___ Python tracker <https://bugs.python.org/issue26388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41889] enum: Mixin and int base class regression in 3.8.6
William Pickard added the comment:
Actually, this is an issue with native types in general that define a 'tp_new'
slot value ('!= NULL').
--
nosy: +WildCard65
___
Python tracker
<https://bugs.python.org/issue41889>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24427] subclass of multiprocessing Connection segfault upon attribute acces
William Pickard added the comment: You did just necro a 5 year old bug report... -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue24427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24427] subclass of multiprocessing Connection segfault upon attribute acces
Change by William Pickard : -- nosy: -WildCard65 ___ Python tracker <https://bugs.python.org/issue24427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Puzzling difference between lists and tuples
I am puzzled by the reason for this difference between lists and tuples.
A list of with multiple strings can be reduced to a list with one string with
the expected results:
for n in ['first','second']:
print n
for n in ['first']:
print n
The first loop prints "first", "second", and the second prints "first".
This is not true for a tuple:
for n in ('first','second'):
print n
for n in ('first'):
print n
prints "first", "second" in the first case, but "f","i","r","s","t" in the
second.
Where is this inconsistency explained?
--
https://mail.python.org/mailman/listinfo/python-list
[issue41525] Python '--help' has corrupted text.
Change by William Pickard : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41706] docs: operator dunder (`__add__`, et al.) invocations described incorrectly
Change by William Chargin : -- keywords: +patch pull_requests: +21170 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22084 ___ Python tracker <https://bugs.python.org/issue41706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41706] docs: operator dunder (`__add__`, et al.) invocations described incorrectly
New submission from William Chargin : The operator override dunder methods, like `__add__`, are described in the “Data model” docs here: <https://docs.python.org/3.10/reference/datamodel.html#object.__add__> Those docs say: > For instance, to evaluate the expression `x + y`, where `x` is an > instance of a class that has an `__add__()` method, `x.__add__(y)` is > called. But this is not correct: `x + y` always uses `type(x).__add__`, which may be different from `x.__add__` if `__add__` has been set directly on the instance. Demonstration: ``` class C: def __add__(self, other): return "from class" c = C() print(c + c) # prints "from class" c.__add__ = lambda other: "from instance" print(c.__add__(c)) # prints "from instance" print(type(c).__add__(c, c)) # prints "from class" print(c + c) # prints "from class"! ``` The same issue appears in the reversed operator dunder (`__radd__`, et al.) docs below. I have a patch that I can submit as a PR; just need a bpo number. -- assignee: docs@python components: Documentation messages: 376316 nosy: docs@python, wchargin priority: normal severity: normal status: open title: docs: operator dunder (`__add__`, et al.) invocations described incorrectly type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41523] functools.cached_property does not satisfy the property check
William Pickard added the comment: Another thing to note Raymond, as I stated before, example C is, from an external context, is a plain property object who's "fget" attribute is an instance of whatever "lru_cache" returns. isinstance won't be able to differentiate between example "a" and "c" without checking "fget" -- ___ Python tracker <https://bugs.python.org/issue41523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41524] PyOS_mystricmp advances pointers too far
Change by William Meehan : -- keywords: +patch pull_requests: +20972 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/21845 ___ Python tracker <https://bugs.python.org/issue41524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41525] Python '--help' has corrupted text.
New submission from William Pickard : Running Python's '--help' argument yields some corrupted text: "-X dev: enable CPythonâ?Ts â?odevelopment modeâ??, introducing additional runtime" -- components: Interpreter Core messages: 375204 nosy: WildCard65 priority: normal severity: normal status: open title: Python '--help' has corrupted text. type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41524] PyOS_mystricmp advances pointers too far
New submission from William Meehan :
The existing implementation of PyOS_mystricmp increments both pointers as long
as the first string hasn't reached the end yet. If the second string ends
first, then we increment past the null byte. If there is a difference in the
middle of the two strings, then the result actually compares the following pair
of letters.
e.g.
PyOS_mystricmp("a", "\0") => 0 (should be positive)
PyOS_mystricmp("foo", "fro") => 0 (should be negative)
Similarly, PyOS_mystrnicmp increments the pointers in a condition before
breaking out of the loop. It's possible to increment the first pointer without
incrementing the second, and the result is the character past the null byte.
e.g.
PyOS_mystrnicmp("\0a", "\0b", 2) => 97 (should be negative)
--
components: C API
messages: 375203
nosy: wmeehan
priority: normal
severity: normal
status: open
title: PyOS_mystricmp advances pointers too far
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue41524>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41523] functools.cached_property does not satisfy the property check
William Pickard added the comment: In the lru_cache example, I think property is using the result of 'lru_cache(c)', which in turns returns a property instance, not a subtype instance. -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue41523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41501] 0x80070643, can't install any version
William Pickard added the comment: Try what's explained here: https://support.microsoft.com/en-us/help/2438651/how-to-troubleshoot-windows-installer-errors -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue41501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: questions re: calendar module
> On Aug 1, 2020, at 10:35 AM, o1bigtenor wrote:
>
> On Sat, Aug 1, 2020 at 9:29 AM o1bigtenor wrote:
>>
>>> On Sat, Aug 1, 2020 at 6:58 AM Peter Otten <__pete...@web.de> wrote:
>>>
>>> o1bigtenor wrote:
>>>
>>> import calendar
>>> print (calendar.calendar(2024,1,1,2,8))
>>>
I would like to show something like 2024 through the end of 2028.
>>>
>>> print("\n".join(cd.calendar(year) for year in range(2024, 2029)))
>>
>>
>> Sorry - - - - 1st response was to only Mr Peter - - - hopefully this is
>> useful to more than I so here is that to all.
>>>
>>>
>>
> print("\n".join(cd.calendar(year) for year in range(2024, 2029)))
>> Traceback (most recent call last):
>> File "", line 1, in
>> File "", line 1, in
>> NameError: name 'cd' is not defined
>>
>> so 'cd' seems to be a problem.
>>
>> Tried changing 'cd' to calendar and that gives the desired response.
>>
>> Except its a neat 3 months wide very very very many rows of calendar.
>>
>> I'm trying to figure out how to do something like this:
>>
>>November 2022 December 2022
>>January 2023February 2023
>> March 2023April 2023
>> May 2023
>> Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu
>> We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
>> Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
>> 1231 2 3 4 5 127 1 2 3
>>132 1 2 3 4 5 6 7 136 1 2 3 4 140
>> 1 2 3 4 1441 149 1 2 3 4 5 6
>> 124 6 7 8 9 10 11 12 128 4 5 6 7 8 9 10 133 8 9 10 11 12
>> 13 14 137 5 6 7 8 9 10 11 141 5 6 7 8 9 10 11 145 2 3
>> 4 5 6 7 8 150 7 8 9 10 11 12 13
>> 125 13 14 15 16 17 18 19 129 11 12 13 14 15 16 17 134 15 16 17 18 19
>> 20 21 138 12 13 14 15 16 17 18 142 12 13 14 15 16 17 18 146 9 10
>> 11 12 13 14 15 151 14 15 16 17 18 19 20
>> 126 20 21 22 23 24 25 26 130 18 19 20 21 22 23 24 135 22 23 24 25 26
>> 27 28 139 19 20 21 22 23 24 25 143 19 20 21 22 23 24 25 147 16 17
>> 18 19 20 21 22 152 21 22 23 24 25 26 27
>> 127 27 28 29 30 131 25 26 27 28 29 30 31 136 29 30 31
>> 140 26 27 28 144 26 27 28 29 30 31 148 23 24
>> 25 26 27 28 29 153 28 29 30 31
>>
>> 149 30
>>
>> June 2023 July 2023August 2023
>> September 2023 October 2023
>> November 2023 December 2023
>>Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th
>> Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo
>> Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
>> 153 1 2 3 1571 1621 2 3
>> 4 5 166 1 2 171 1 2 3 4 5 6 7 175
>> 1 2 3 4 179 1 2
>>
>> The formatting here is a mess.
>
> (Its an even bigger mess now when its truncated to 80 columns. Can't change
> the mess but I can tell you that it doesn't 'look that way'! Don't know how to
> include an example in the body and have it be even a bit accurate - - - please
> advise if there is a way.)
>
If you want us to see it in its exact form, print to PDF, post/share It on
Dropbox.
>> The months are centered. The week numbers are consecutive from the
>> starting date.
>> The dates are centered under the weekday name. If you've ever used
>> ncal its like that except
>> that I can now have up to 7 months wide if the terminal is wide enough
>> (>180 columns IIRC).
>> A mentor was working on this in Perl but as he died some couple months
>> ago its up to me
>> to make what I want.
>> Because it seems like there are a lot of disparate things happening
>> its not very straight
>> forward trying to replicate and extend my friend's efforts except in
>> Python. (My friend
>> preferred to work in Perl rather than Python and I'm wanting to learn
>> Python. I understand
>> that this is not perhaps the easiest way to learn something but it
>> sure is interesting!)
>>
>> TIA
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
[issue41358] Unable to uninstall Python launcher using command line
William Pickard added the comment: I think on Windows, the Python Launcher is a separate install entity. You can verify this under Control Panel -> Uninstall Program and Features. -- nosy: +WildCard65 ___ Python tracker <https://bugs.python.org/issue41358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41368] Allow compiling Python with llvm-clang on Windows.
William Pickard added the comment: Note: Apparently Google-OpenID login button created a seperate account... instead of finding this one. -- nosy: +WildCard65 -William Pickard ___ Python tracker <https://bugs.python.org/issue41368> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41368] Allow compiling Python with llvm-clang on Windows.
New submission from William Pickard : Since Visual Studio 2017, Microsoft has an optional C++ Desktop Development option for compiling C/C++ code with LLVM's Clang compiler. It's called: Clang with Microsoft CodeGen. While the code is parsed with LLVM's Clang parser, the code is generated with a MSVC compatible code generator (hence the "with Microsoft CodeGen" name suffix) Currently, Python 3.10 is uncompilable with Clang, but I would appreciate it if it can be supported. I have attached a build log from MSBuild, below is the commandline I used to run the build. Start-Process -FilePath $(Join-Path $PCBUILD -ChildPath 'build.bat' -Resolve) -WorkingDirectory $PCBuild -NoNewWindow -RedirectStandardOut $BUILD_LOG -RedirectStandardError $BUILDERROR_LOG -ArgumentList '-m', '-v', '-c', 'Debug', '-p', 'x64', '-t', 'Build', '"/p:PlatformToolset=ClangCL"' PS L:\GIT\cpython> Start-Process -FilePath $(Join-Path $PCBUILD -ChildPath 'build.bat' -Resolve) -WorkingDirectory $PCBuild -NoNewWindow -RedirectStandardOut $BUILD_LOG -RedirectStandardError $BUILDERROR_LOG -ArgumentList '-m', '-v', '-c', 'Debug', '-p', 'x64', '-t', 'Build', '"/p:PlatformToolset=ClangCL"' -- components: Cross-Build, Windows files: build.log messages: 374099 nosy: Alex.Willmer, William Pickard, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Allow compiling Python with llvm-clang on Windows. type: compile error versions: Python 3.10 Added file: https://bugs.python.org/file49331/build.log ___ Python tracker <https://bugs.python.org/issue41368> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41294] Allow '__qualname__' to be an instance of 'DynamicClassAttribute'
New submission from William Pickard : Currently within Python, the attribute '__qualname__' is restricted to only be a string valued attribute. This makes is rather cumbersome for anyone who wants to implement '__qualname__' as a property, instead of a plain attribute (especially if '__slots__' are used) Python also has the type 'DynamicClassAttribute' who's only first party user is the 'enum' module, BUT it only supports shadow get requests. Therefore, I'm requesting both changing DynamicClassAttribute to supoort __set__ and __del__ to function like __get__ AND to allow __qualname__ to be an instance of DynamicClassAttribute. -- messages: 373621 nosy: WildCard65 priority: normal severity: normal status: open title: Allow '__qualname__' to be an instance of 'DynamicClassAttribute' type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41294> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41188] Prepare CPython for opaque PyObject structure.
Change by William Pickard : -- keywords: +patch pull_requests: +20415 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21262 ___ Python tracker <https://bugs.python.org/issue41188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41188] Prepare CPython for opaque PyObject structure.
New submission from William Pickard : The goal of issue 39573 is to make "PyObject" and opaque structure in the limited API. To do that, a few mandatory changes will be required to CPython in order to allow for seamless implementation. Namely: 1) User types need to get away from directly referencing PyObject. - This can be done by adding a new variable to "PyTypeObject" who's value is an offset into the object's pointer to the type's internal structure. -- Example: 'PyType_Type.tp_obj_offset' would be the value of "sizeof(PyVarObject)". -- For custom types with another base: The value would be calculated from the base's "tp_obj_offset" + "tp_basicsize" 2) Create a linkable static library to facility method calls requiring internal implementation. - This static library will be implementation defined, IE: using internal methods specific to the runtime that created it. - Public facing methods will use generic names for example, "PyObject_GetType" will get the object's ob_type (or whatever the target runtime calls it). -- components: C API, Interpreter Core messages: 372775 nosy: WildCard65, vstinner priority: normal severity: normal status: open title: Prepare CPython for opaque PyObject structure. type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] [C API] Make PyObject an opaque structure in the limited C API
Change by William Pickard : -- nosy: +WildCard65 nosy_count: 9.0 -> 10.0 pull_requests: +20410 pull_request: https://github.com/python/cpython/pull/21262 ___ Python tracker <https://bugs.python.org/issue39573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41153] [easy Doc] "PyPreConfig_InitIsolatedConfig" and "PyPreConfig_InitPythonConfig" are given the opposite's documentation.
Change by William Pickard : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41171] Create companion methods of "PyType_FromSpec*" to allow setting metaclass.
Change by William Pickard : -- keywords: +patch pull_requests: +20390 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21238 ___ Python tracker <https://bugs.python.org/issue41171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41171] Create companion methods of "PyType_FromSpec*" to allow setting metaclass.
William Pickard added the comment: Another thing I thought of, if this is accepted, we can turn the "PyType" methods into header static inline methods. -- ___ Python tracker <https://bugs.python.org/issue41171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41171] Create companion methods of "PyType_FromSpec*" to allow setting metaclass.
New submission from William Pickard : The current goal from what I can tell for Python is to have all C based modules move away from static types and instead use "PyType_FromSpec" and the variant that specifies base classes. The only problem is, PyType_FromSpec and it's variant makes the assumption the caller wants "PyType_Type" as the type's metaclass. Why not add companion methods to them prefixed with "PyMetaType" and have the "PyType" ones internally invoke these new methods with "PyType_Type" as the metaclass (to keep existing behavior and backwards compatibility) -- components: C API messages: 372696 nosy: WildCard65 priority: normal severity: normal status: open title: Create companion methods of "PyType_FromSpec*" to allow setting metaclass. type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41153] [easy Doc] "PyPreConfig_InitIsolatedConfig" and "PyPreConfig_InitPythonConfig" are given the opposite's documentation.
Change by William Pickard : -- title: [easy Doc] "PyPreConfig_InitIsolatedConfig" and "PyPreConfig_InitPythonConfig" are given opposite documentation. -> [easy Doc] "PyPreConfig_InitIsolatedConfig" and "PyPreConfig_InitPythonConfig" are given the opposite's documentation. ___ Python tracker <https://bugs.python.org/issue41153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41153] [easy Doc] "PyPreConfig_InitIsolatedConfig" and "PyPreConfig_InitPythonConfig" are given opposite documentation.
New submission from William Pickard : The initconfig API functions "PyPreConfig_InitPythonConfig" and "PyPreConfig_InitIsolatedConfig" are mistakenly documented for the other method. -- assignee: docs@python components: Documentation messages: 372531 nosy: WildCard65, docs@python priority: normal pull_requests: 20358 severity: normal status: open title: [easy Doc] "PyPreConfig_InitIsolatedConfig" and "PyPreConfig_InitPythonConfig" are given opposite documentation. type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41117] [easy C] GC: Use local variable 'op' when invoking 'traverse' in 'subtract_refs'
New submission from William Pickard : When the GC module goes to collect objects (most notably, during Python shutdown), it makes a call to subtract_refs on the GC container. During this invocation, it creates a local variable "op" who's value is the result of 'FROM_GC(gc)', but when it goes to use the obtained 'traverse' method, it calls FROM_GC(gc) instead of using 'op'. This, unfortunately, makes it rather difficult to debug "Access Violations" for extension modules for when 'traverse' is 'NULL' as inspecting the variable 'op' in the chosen debugger (for my case: Visual Studio on Windows) is impossible. This can potentially introduce a micro optimization in the overall runtime of the GC module as it no longer has to invoke the addition instruction (if it does) to construct the first parameter of the 'traverse' call. -- components: C API, Interpreter Core files: cpython.patch keywords: patch messages: 372380 nosy: WildCard65 priority: normal severity: normal status: open title: [easy C] GC: Use local variable 'op' when invoking 'traverse' in 'subtract_refs' type: enhancement versions: Python 3.10 Added file: https://bugs.python.org/file49261/cpython.patch ___ Python tracker <https://bugs.python.org/issue41117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41085] [easy C] array.array.index() method downcasts Py_ssize_t to long
Change by William Pickard : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41085] [easy C] array.array.index() method downcasts Py_ssize_t to long
Change by William Pickard : -- keywords: +patch pull_requests: +20240 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21071 ___ Python tracker <https://bugs.python.org/issue41085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41085] Array regression test fails
William Pickard added the comment: The only modification I made was to "rt.bat" to have the value of '-u' work properly. -- ___ Python tracker <https://bugs.python.org/issue41085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
