[issue1146] TextWrap vs words 1-character shorter than the width
New submission from sam:
>>> from textwrap import wrap
>>> wrap("foobarbaz reallylongwordgoeshere", width = 10)
['foobarbaz r', 'eallylongw', 'ordgoesher', 'e']
>>> print [len(s) for s in _]
[11, 10, 10, 1]
This only seems to happen when the first word on the line is exactly one
character shorter than the width, and the next word is too long to fit,
so it is broken:
>>> wrap("foo bar reallylongwordgoeshere", width = 7)
['foo bar', 'reallyl', 'ongword', 'goesher', 'e']
>>> wrap("foobarbaz really longwordgoeshere", width = 10)
['foobarbaz', 'really lon', 'gwordgoesh', 'ere']
>>> wrap("foobarbaz reallylongwordgoeshere", width = 10,
break_long_words = False)
['foobarbaz', 'reallylongwordgoeshere']
This is on Python 2.5, on Windows XP SP2.
--
messages: 55822
nosy: sam
severity: normal
status: open
title: TextWrap vs words 1-character shorter than the width
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1146>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3766] socket.socket.recv broken (unbearably slow)
Sam added the comment:
I know this bug is closed, but I too am experiencing it under Linux
2.6.24-22 and Python 2.5.2.
I'm using urllib2, and it's just spending an obscene amount of cpu time
in {method 'recv' of '_socket.socket' objects}
Anyone have any ideas?
Would switching to httplib2 help?
--
nosy: +samslists
___
Python tracker
<http://bugs.python.org/issue3766>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22699] cross-compilation of Python3.4
Sam added the comment: Has there been any update on this? I've run into this issue trying to cross-compile python for Android. I've tried 3.7.4, 3.8 and current master, both in-source and out of source builds, all ending with the modules failing to compile due to wrong paths. ... CC='/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android26-clang' LDSHARED='/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android26-clang -shared -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,--gc-sections -lc++ -lm -lgcc -ldl -lc -lgcc -ldl -latomic -lm -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,--gc-sections -lc++ -lm -lgcc -ldl -lc -lgcc -ldl -latomic -lm ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' _PYTHON_PROJECT_BASE=/home/samuel/android/cpython _PYTHON_HOST_PLATFORM=linux-aarch64 PYTHONPATH=/home/s amuel/android/cpython/build/lib.linux-aarch64-3.7:./Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_ python3 ./setup.py build running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers building '_struct' extension /home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android26-clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall --target=aarch64-none-linux-android26 --gcc-toolchain=/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -O3 -fPIE --target=aarch64-none-linux-android26 --gcc-toolchain=/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -O3 -fPIE -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -I./Include -I. -I/home/samuel/android/cpython_build/host/venv/include -I/home/samuel/android/cpython_build/host/install/include/python3.7m -c _struct.c -o build/temp.linux-aarch64-3.7/_struct.o clang: error: no such file or directory: '_struct.c' clang: error: no input files ... Failed to build these modules: _asyncio _bisect _blake2 _bz2 _codecs_cn_codecs_hk _codecs_iso2022 _codecs_jp_codecs_kr _codecs_tw_contextvars _crypt _csv _ctypes _ctypes_test _datetime _decimal _heapq _json _lsprof _md5 _multibytecodec _multiprocessing _opcode _pickle _posixsubprocess _queue _random _sha1 _sha256 _sha3 _sha512 _socket _struct _testbuffer _testcapi _testimportmultiple _testmultiphase _uuid _xxtestfuzz array audioop binascii cmath fcntl grp math mmap ossaudiodev parserpyexpat resource selectspwd syslogtermios unicodedata xxlimited ... -- nosy: +iliis ___ Python tracker <https://bugs.python.org/issue22699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46205] Race condition in runtest_mp leads to hangs (never exits)
New submission from Sam Gross : The runtest_mp.py has a race condition between checking for worker.is_alive() and processing the queue that can lead to indefinite hangs. The hang happens when the all the results from the self.output queue are processed but at least one of the workers hasn't finished exiting. https://github.com/python/cpython/blob/8d7644fa64213207b8dc6f555cb8a02bfabeced2/Lib/test/libregrtest/runtest_mp.py#L394-L418 The main thread tries to get a result from the output queue, but the queue is empty and remains empty. Although the queue.get() operation eventually times out (after 30 seconds), the main thread does not re-check if all the workers have exited (!), but instead retries the queue.get() in the "while True" loop. https://github.com/python/cpython/blob/8d7644fa64213207b8dc6f555cb8a02bfabeced2/Lib/test/libregrtest/runtest_mp.py#L415-L418 To reproduce, apply the below patch which introduces a small delay to more reliably trigger the hang. curl "https://gist.githubusercontent.com/colesbury/fe3769f43dfb724c86ecbb182b1f6749/raw/e29a4eaeebb8d5252cdd66f3f8a70f7bc5fa14e7/runtest_mp.diff"; | patch -p1 ./python -m test test_regrtest -m test_module_from_test_autotest -v -- messages: 409374 nosy: colesbury priority: normal severity: normal status: open title: Race condition in runtest_mp leads to hangs (never exits) versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46205] Race condition in runtest_mp leads to hangs (never exits)
Change by Sam Gross : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46205] Race condition in runtest_mp leads to hangs (never exits)
Change by Sam Gross : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46205] test.libregrtest: Race condition in runtest_mp leads to hangs (never exits)
Change by Sam Gross : -- keywords: +patch pull_requests: +28673 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30470 ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38633] shutil.copystat fails with PermissionError in WSL
Sam Park added the comment: FWIW I just ran into this today on Ubuntu 18.04 container on GKE 1.21.5-gke.1302 and on a Ubuntu-with-Docker underlying node (if that's relevant). Applying the monkeypatch solves the issue as well. -- nosy: +sam.park ___ Python tracker <https://bugs.python.org/issue38633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.datetime.fromtimestamp
New submission from Sam Roberts : Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64 bit (AMD64)] on win32 datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch, but for some reason works properly for aware-datetime values prior to the start of the epoch. This is at least inconsistent, but seems like a bug. Negative timestamps for dates prior to the start of the epoch are used by yahoo finance and in the yfinance module. >>> import datetime >>> start = int(datetime.datetime(1962, 1, 31, >>> tzinfo=datetime.timezone.utc).timestamp()) >>> start -249868800 >>> start = int(datetime.datetime(1962, 1, 31).timestamp()) Traceback (most recent call last): File "", line 1, in start = int(datetime.datetime(1962, 1, 31).timestamp()) OSError: [Errno 22] Invalid argument -- components: Library (Lib) messages: 412649 nosy: smrpy priority: normal severity: normal status: open title: datetime.datetime.fromtimestamp type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch
Change by Sam Roberts : -- title: datetime.datetime.fromtimestamp -> datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.timestamp() fails for naive-datetime values prior to the start of the epoch
Sam Roberts added the comment: the first sentence should have read: datetime.timestamp() fails for naive-datetime values prior to the start of the epoch, but for some reason works properly for aware-datetime values prior to the start of the epoch. -- title: datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch -> datetime.timestamp() fails for naive-datetime values prior to the start of the epoch ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.timestamp() fails for naive-datetime values prior to the start of the epoch
Sam Roberts added the comment: this seems like an expected discrepancy because of a difference in the mechanism used for aware datatimes vs. naive datetimes, although I'm not sure I understand why the computation with naive datetimes uses the mktime() function rather than invoking datetime.timedelta.total_seconds() on a datetime difference. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.timestamp() fails for naive-datetime values prior to the start of the epoch
Change by Sam Roberts : -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45098] asyncio.CancelledError should contain more information on cancellations
Sam Bull added the comment: I think there's still a problem, in that the user still expects a task to be cancelled in the example previously: https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523 If we encounter the race condition where the timeout cancels the task and then the user cancels the task, then we still have the case that async-timeout swallows the cancellation and the task will run forever. This would basically require the user to check everytime they want to cancel the task, with something awkward like: ``` while not task.cancel() and not task.cancelled(): await asyncio.sleep(0) ``` I think this change is still necessary, but rather than adding multiple values to e.args, we can use the new ExceptionGroup to raise multiple CancelledErrors. So, each call of task.cancel() will create a new CancelledError, and then all of those CancelledErrors will get raised together. For async-timeout, we can then just catch the CancelledError with our sentinel and raise a TimeoutError, while reraising any other CancelledErrors. -- ___ Python tracker <https://bugs.python.org/issue45098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: > If the task is already pending a cancellation targeted at a cancel scope, the > task itself cannot be cancelled anymore since calling cancel() again on the > task is a no-op. This would be solved by updating the cancel message on the > second call. > I think Andrew missed one case: in his second diagram, what if the explicit > cancel() happened *after* the timeout (but still in the same iteration)? > That's the case that makes me want to delete those two lines from > Task.cancel() (see my earlier message). To expand on this point, I've been looking at solving the race conditions in async-timeout. To see how such a race condition can end up with a task never exiting, take a look at this example: https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523 In the condition Guido describes, the user's cancellation is suppressed and the code runs forever. I also wrote tests that seem to reliably reproduce the race condition (the 2nd one still seems unfixable with the current solutions, the 1st was fixed with the nonce/sentinel trick): https://github.com/aio-libs/async-timeout/commit/ab04eb53dcf49388b6e6eacf0a50bafe19c5c74b#diff-60a009a48129ae41018d588c32a6d94c54d1d2948cbc3b831fc27a9c8fdbac68L364-L421 You can see the flow of execution from the call_order assert at the end. I think most of the solutions proposed here will still not solve this race condition. I initially proposed a solution at: https://bugs.python.org/issue45098 In short, I think that every time we call .cancel(), we need to raise another CancelledError. So, in this race condition you would get 2 CancelledErrors (via an ExceptionGroup). Then our code can catch the error with our nonce/sentinel and handle that, but also reraise any other errors which are unrelated. -- nosy: +dreamsorcerer ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: > This should be solved when using the cancel count -- the explicit cancel > bumps the cancel count so the cancel scope (i.e. timeout()) will not raise > TimeoutError. It will probably work in this case. But, what about more complex cases? If there are 2 different timeouts and the possibility of a user cancellation, and we have a count of 2 cancellations, then what happened? 2 timeouts, or 1 timeout and user cancellation? Without being able to check the nonces of each cancellation, I don't see how this would work. Or if the user calls .cancel() twice explicitly, then you cancel both timeouts, even though it had nothing to do with the timeout. Propagating an ExceptionGroup where every exception can be inspected to see if it was caused by this code or not still seems like the safe option to me (and obviously still has the cancel count implicitly). -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: Actually, in your counter proposal, you say: > Such context managers should still keep track of whether they cancelled the > task themselves or not, and if they did, they should always call t.uncancel(). But, if we are using nonces on the CancelledError to keep track, then only 1 context manager will know if it was themselves or not. This is exactly why I'm proposing to use multiple CancelledErrors, so that every nonce is passed to the handling code. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: > Previously, when the task was cancelled twice, only one CancelledError was > raised. Now it would raise a BaseExceptionGroup instead. I was under the impression that ExceptionGroup was somewhat backwards compatible, in that you could still use `except CancelledError:` and it would catch all the errors in the group. But, maybe I'm wrong, I've not seen the documentation for the final feature yet, but that's the impression I got from the PEP. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: > We could store the nonces in a single CancelledError instead. Indeed, my initial proposal was exactly that, but after learning about ExceptionGroup, I thought that was a cleaner approach. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13376] readline: pre_input_hook not getting called
New submission from Sam Cates :
OS: Mac 10.7.2
Python: 2.7.1
Setting a pre input hook in readline has no effect. This simple example
illustrates the problem:
#!/usr/bin/python
import readline
def hook():
readline.insert_text(' from pre_input_hook')
readline.redisplay()
readline.set_pre_input_hook(hook)
while True:
line = raw_input('Prompt ("stop" to quit): ')
if line == 'stop':
break
print 'ENTERED: "%s"' % line
The hook never gets called, thus "from pre_input_hook" is never displayed.
--
assignee: ronaldoussoren
components: Macintosh
messages: 147336
nosy: ronaldoussoren, scates
priority: normal
severity: normal
status: open
title: readline: pre_input_hook not getting called
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13376>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp
Sam Bull added the comment: I think there's a much simpler solution to this ticket than the retry logic that's currently in place. The code originally avoided the infinite recursion by checking to see if the previous request had already submitted the auth credentials that would be used in the retry. If it had, it would return None. If it hadn't, it would add the auth credentials to the request header and the request again: if req.headers.get(self.auth_header, None) == auth: return None req.add_header(self.auth_header, auth) Then, to fix #3819, it was changed. Instead of calling add_header, it called add_unredirected_header: if req.headers.get(self.auth_header, None) == auth: return None req.add_unredirected_header(self.auth_header, auth) This caused the loop because the auth creds were going into unredirected_hdrs instead of the headers dict. But I think the original logic is sound. The code just wasn't checking in all the headers. Luckily there's a get_header method that checks both for you. This one-line change should fix the issue: if req.get_header(self.auth_header, None) == auth: return None req.add_unredirected_header(self.auth_header, auth) I think this fix is cleaner and makes more sense, but I'm worried I might be missing something. I don't fully understand the distinction between headers and unredirected headers. Maybe there's a reason why the code isn't checking in unredirected headers for the auth header. I'm attaching a patch. I'm new to contributing to python so I apologize if the format is wrong. -- nosy: +sambull versions: +Python 2.7 Added file: http://bugs.python.org/file20471/simpler_fix.patch ___ Python tracker <http://bugs.python.org/issue8797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37658] In some cases asyncio.wait_for can lead to socket leak.
Sam Bull added the comment: There is still an issue here. I proposed a possible solution at: https://github.com/python/cpython/pull/28149#issuecomment-1007823782 You can also scroll up through the lengthy discussion to see how I reached that conclusion. I've not had time yet to actually try implementing something yet. -- ___ Python tracker <https://bugs.python.org/issue37658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14265] Fully qualified test name in failure output
Change by Sam Ezeh : -- nosy: +dignissimus ___ Python tracker <https://bugs.python.org/issue14265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14265] Fully qualified test name in failure output
Change by Sam Ezeh : -- keywords: +patch pull_requests: +30218 pull_request: https://github.com/python/cpython/pull/32138 ___ Python tracker <https://bugs.python.org/issue14265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14265] Fully qualified test name in failure output
Sam Ezeh added the comment: The provided patch wasn't entirely compatible with the current upstream code. I used the patch file to apply the changes to `Lib/unittest/case.py`, resolved the remaining conflicts with the patches to the test files and amended existing tests for the library. I updated the documentation for unittest to reflect the changes in behaviour. -- ___ Python tracker <https://bugs.python.org/issue14265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
Change by Sam Ezeh : -- nosy: +sam_ezeh ___ Python tracker <https://bugs.python.org/issue4833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
Sam Ezeh added the comment: I'm looking into adding ZipFile.mkdir -- ___ Python tracker <https://bugs.python.org/issue4833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
Change by Sam Ezeh : -- keywords: +patch pull_requests: +30238 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32160 ___ Python tracker <https://bugs.python.org/issue4833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
Sam Ezeh added the comment: I've submitted the above patch. I created the ZipFile.mkdir function, created the necessary tests and wrote the documentation. I think it is ready for review. -- Added file: https://bugs.python.org/file50705/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue4833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Sam Ezeh added the comment: I've submitted a patch that introduces code that raises TypeError at construction if `fieldnames` is not a sequence -- keywords: +patch nosy: +sam_ezeh Added file: https://bugs.python.org/file50709/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : Removed file: https://bugs.python.org/file50709/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : Added file: https://bugs.python.org/file50710/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : Removed file: https://bugs.python.org/file50710/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : Added file: https://bugs.python.org/file50711/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : -- pull_requests: +30300 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32225 ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Sam Ezeh added the comment: I'm looking into adding this > Seems reasonable to me, but I think a full implementation would want to throw > an error for keyword args that don't already exist as context attributes > (otherwise typos would fail silently) For _pydecimal, I think this would automatically happen automatically as Context.__setattr__ raises AttributeError when it's passed a name that isn't a context attribute. For _decimal this can be done with keyword arguments and `PyArg_ParseTupleAndKeywords`. -- nosy: +sam_ezeh ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Sam Ezeh added the comment: I've uploaded a patch and it seems to work, which I'm very proud of. I'll create some tests, amend documentation and create a news entry. After that, I'll create a pull request on GitHub. -- keywords: +patch Added file: https://bugs.python.org/file50713/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Sam Ezeh added the comment: This is what functionality looks like when supplying incorrect attribute names with the patch. Python 3.11.0a6+ (heads/bpo-47135-dirty:d4bb38f82b, Apr 1 2022, 20:01:56) [GCC 11.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import _pydecimal >>> ctx = _pydecimal.getcontext() >>> ctx.precision = 10 Traceback (most recent call last): File "", line 1, in File "/run/media/sam/OS/Git/cpython/Lib/_pydecimal.py", line 3974, in __setattr__ raise AttributeError( ^ AttributeError: 'decimal.Context' object has no attribute 'precision' >>> with _pydecimal.localcontext(precision=10) as ctx: ... pass ... Traceback (most recent call last): File "", line 1, in File "/run/media/sam/OS/Git/cpython/Lib/_pydecimal.py", line 506, in localcontext setattr(ctx, key, value) File "/run/media/sam/OS/Git/cpython/Lib/_pydecimal.py", line 3974, in __setattr__ raise AttributeError( ^ AttributeError: 'decimal.Context' object has no attribute 'precision' >>> import decimal >>> ctx = decimal.getcontext() >>> ctx.precision = 10 Traceback (most recent call last): File "", line 1, in AttributeError: 'decimal.Context' object has no attribute 'precision' >>> with decimal.localcontext(precision=10) as ctx: ... pass ... Traceback (most recent call last): File "", line 1, in TypeError: 'precision' is an invalid keyword argument for this function >>> -- ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Change by Sam Ezeh : -- pull_requests: +30313 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32242 ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47200] Add ZipInfo.mode property
New submission from Sam Ezeh : Initially, I was looking at bpo-18262 and saw the following Stack Overflow thread that was linked. https://stackoverflow.com/questions/434641/how-do-i-set-permissions-attributes-on-a-file-in-a-zip-file-using-pythons-zip/6297838 I've attached a patch that gives ZipInfo objects a `ZipInfo.mode` property getter and setter to get and set the file mode. I considered adding ZipFile.chmod but I didn't know how it would work given that archives can contain duplicate files. As an aside, I wondered if there's a way to update file attributes inside zip archives without deleting and rewriting them and if not, whether it would be worthwhile to add one. -- components: Library (Lib) files: sam_ezeh.patch keywords: patch messages: 416550 nosy: sam_ezeh priority: normal severity: normal status: open title: Add ZipInfo.mode property type: enhancement versions: Python 3.11 Added file: https://bugs.python.org/file50715/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue47200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47200] Add ZipInfo.mode property
Change by Sam Ezeh : -- pull_requests: +30323 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32252 ___ Python tracker <https://bugs.python.org/issue47200> ___ ___ 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 Sam Ezeh : -- nosy: +sam_ezeh ___ 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
[issue15795] Zipfile.extractall does not preserve file permissions
Change by Sam Ezeh : -- pull_requests: +30350 pull_request: https://github.com/python/cpython/pull/32289 ___ 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
[issue39064] ValueError in zipfile.ZipFile
Change by Sam Ezeh : -- nosy: +sam_ezeh ___ Python tracker <https://bugs.python.org/issue39064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39064] ValueError in zipfile.ZipFile
Sam Ezeh added the comment:
One way of doing this is by making the central directory offset negative by
first taking the zip file containing just an EOCD record and then listing the
total size of the central directory records as positive.
```
Python 3.11.0a4+ (heads/bpo-39064:eb1935dacf, Apr 3 2022, 19:09:53) [GCC
11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
>>> import io
>>> b = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>>> b[12] = 1
>>> f = io.BytesIO(bytes(b))
>>> zipfile.ZipFile(f)
Traceback (most recent call last):
File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1370, in
_RealGetContents
fp.seek(self.start_dir, 0)
^^
ValueError: negative seek value -1
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1284, in __init__
self._RealGetContents()
^^^
File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1372, in
_RealGetContents
raise BadZipFile("Bad offset for central directory")
zipfile.BadZipFile: Bad offset for central directory
>>>
```
--
___
Python tracker
<https://bugs.python.org/issue39064>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39064] ValueError in zipfile.ZipFile
Sam Ezeh added the comment: Yes, of course. -- ___ Python tracker <https://bugs.python.org/issue39064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30964] Mention ensurepip in package installation docs
Change by Sam Ezeh : -- nosy: +sam_ezeh nosy_count: 3.0 -> 4.0 pull_requests: +30352 pull_request: https://github.com/python/cpython/pull/32291 ___ Python tracker <https://bugs.python.org/issue30964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39064] ValueError in zipfile.ZipFile
Change by Sam Ezeh : -- pull_requests: +30353 pull_request: https://github.com/python/cpython/pull/32291 ___ Python tracker <https://bugs.python.org/issue39064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30964] Mention ensurepip in package installation docs
Change by Sam Ezeh : -- pull_requests: -30352 ___ Python tracker <https://bugs.python.org/issue30964> ___ ___ 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
Sam Ezeh added the comment: I don't know what the best course of action would be but if preserving permissions needs to be back-ported, could the default permission preservation flag in 3.11+ be the one to preserve safe permissions and then make it so that the previous versions (<3.11, without the constants) always take this course of action? Maintaining the different options for preserving permissions while still allowing for this functionality to be back-ported. I don't have a strong opinion on backporting permission preservation but to me, it seems like it would be a change in behaviour instead of a bug fix. The current default in the PR is to not preserve any permissions but if necessary, I'll change it to whatever is agreed upon. I'll move the constants into an enum, but right now I'm not sure how I'd name the class. As an aside, while writing this comment I realised that the reason tests aren't passing on my end might very well be due to the fact I do CPython work on an NTFS partition instead of on my main EXT4 partition. -- ___ 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
[issue47184] multiprocessing.set_start_method force argument is not documented
Change by Sam Ezeh : -- keywords: +patch nosy: +sam_ezeh nosy_count: 2.0 -> 3.0 pull_requests: +30395 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32339 ___ Python tracker <https://bugs.python.org/issue47184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47184] multiprocessing.set_start_method force argument is not documented
Sam Ezeh added the comment: It's quite weird, the documentation says set_start_method "should not be used more than once in the program" twice. The source code also contains the following line ``` # Type of default context -- underlying context can be set at most once ``` I'm not too familiar with the multiprocessing library but with the force parameter set to True, I don't understand why that can't happen. If there's a specific reason, maybe that should be documented too. -- ___ Python tracker <https://bugs.python.org/issue47184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37910] argparse wrapping fails with metavar="" (no metavar)
New submission from Sam Franklin :
When argparse wraps the usage text, it can fail its assertion tests with
whitespace differences. This can occur when metavar="", needed if a user wishes
to avoid having a metavar print. It also could occur if a user specifies any
other whitespace.
Here's a minimum example (depending on $COLUMNS):
import argparse
# based on Vajrasky Kok's script in https://bugs.python.org/issue11874
parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument('--nil', metavar='', required=True)
parser.add_argument('--a', metavar='a' * 165)
parser.parse_args()
This produces the AssertionError at the bottom of this comment.
A solution is to have the two asserts ignore whitespace. I'll submit a pull
request very shortly for this. (First time so happy for any comments or
critiques!)
A more extensive example:
import argparse
# based on Vajrasky Kok's script in https://bugs.python.org/issue11874
parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument('--nil', metavar='', required=True)
parser.add_argument('--Line-Feed', metavar='\n', required=True)
parser.add_argument('--Tab', metavar='\t', required=True)
parser.add_argument('--Carriage-Return', metavar='\r', required=True)
parser.add_argument('--Carriage-Return-and-Line-Feed',
metavar='\r\n', required=True)
parser.add_argument('--vLine-Tabulation', metavar='\v', required=True)
parser.add_argument('--x0bLine-Tabulation', metavar='\x0b', required=True)
parser.add_argument('--fForm-Feed', metavar='\f', required=True)
parser.add_argument('--x0cForm-Feed', metavar='\x0c', required=True)
parser.add_argument('--File-Separator', metavar='\x1c', required=True)
parser.add_argument('--Group-Separator', metavar='\x1d', required=True)
parser.add_argument('--Record-Separator', metavar='\x1e', required=True)
parser.add_argument('--C1-Control-Code', metavar='\x85', required=True)
parser.add_argument('--Line-Separator', metavar='\u2028', required=True)
parser.add_argument('--Paragraph-Separator', metavar='\u2029', required=True)
parser.add_argument('--a', metavar='a' * 165)
parser.parse_args()
This is related to https://bugs.python.org/issue17890 and
https://bugs.python.org/issue32867.
File "/minimum_argparse_bug.py", line 7, in
parser.parse_args()
File "/path/to/cpython/Lib/argparse.py", line 1758, in parse_args
args, argv = self.parse_known_args(args, namespace)
File "/path/to/cpython/Lib/argparse.py", line 1790, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
File "/path/to/cpython/Lib/argparse.py", line 1996, in _parse_known_args
start_index = consume_optional(start_index)
File "/path/to/cpython/Lib/argparse.py", line 1936, in consume_optional
take_action(action, args, option_string)
File "/path/to/cpython/Lib/argparse.py", line 1864, in take_action
action(self, namespace, argument_values, option_string)
File "/path/to/cpython/Lib/argparse.py", line 1037, in __call__
parser.print_help()
File "/path/to/cpython/Lib/argparse.py", line 2483, in print_help
self._print_message(self.format_help(), file)
File "/path/to/cpython/Lib/argparse.py", line 2467, in format_help
return formatter.format_help()
File "/path/to/cpython/Lib/argparse.py", line 281, in format_help
help = self._root_section.format_help()
File "/path/to/cpython/Lib/argparse.py", line 212, in format_help
item_help = join([func(*args) for func, args in self.items])
File "/path/to/cpython/Lib/argparse.py", line 212, in
item_help = join([func(*args) for func, args in self.items])
File "/path/to/cpython/Lib/argparse.py", line 336, in _format_usage
assert ' '.join(opt_parts) == opt_usage
AssertionError
--
components: Library (Lib)
messages: 350117
nosy: sjfranklin
priority: normal
severity: normal
status: open
title: argparse wrapping fails with metavar="" (no metavar)
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue37910>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37910] argparse wrapping fails with metavar="" (no metavar)
Change by Sam Franklin : -- keywords: +patch pull_requests: +15084 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15372 ___ Python tracker <https://bugs.python.org/issue37910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37992] Change datetime.MINYEAR to allow for negative years
Change by Sam Wainwright : -- components: Library (Lib) nosy: Sam Wainwright priority: normal severity: normal status: open title: Change datetime.MINYEAR to allow for negative years type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue37992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37992] Change datetime.MINYEAR to allow for negative years
New submission from Sam Wainwright : The value of datetime.MINYEAR (1) seems arbitrarily restrictive. There are plenty of reasons why users of the standard library might want to work with negative years. Workarounds involving things like astropy don't work in all cases, particularly when you're working with other third-party libraries that use python dates internally and forking them is a hassle. -- ___ Python tracker <https://bugs.python.org/issue37992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38395] proxy_contains (weakref.proxy) can access an object with 0 refcount
New submission from Sam Gross :
The implementation of weakref.proxy's methods call back into the Python API
using a "borrowed reference" of the weakly referenced object (acquired via
PyWeakref_GET_OBJECT). This API call may delete the last reference to the
object (either directly or via GC), leaving a dangling pointer, which can be
subsequently dereferenced.
Tested with Python 3.8.0b4 (debug build)
The following code crashes with a debug build of Python 3.8.0b4 on Linux.
import weakref
obj = None
class MyObj:
def __iter__(self):
global obj
del obj
return NotImplemented
obj = MyObj()
p = weakref.proxy(obj)
print(5 in p)
This particular test case does not crash with a release build (on Linux).
The implementation of `in` on a proxy object calls proxy_contains:
return PySequence_Contains(PyWeakref_GET_OBJECT(proxy), value);
https://github.com/python/cpython/blob/v3.8.0b4/Objects/weakrefobject.c#L556
This eventually calls _PySequence_IterSearch. The call to PyObject_GetIter can
call arbitrary code, which can lead to seq (the proxy's referent) being
deleted. The subsequent call to type_error dereferences a dead object.
it = PyObject_GetIter(seq);
if (it == NULL) {
type_error("argument of type '%.200s' is not iterable", seq);
return -1;
}
https://github.com/python/cpython/blob/v3.8.0b4/Objects/abstract.c#L2003-L2007
I believe some functions, like proxy_length, may be immune to this problem
because they do not access the borrowed referent after calling into user code.
However, this is hard to verify from reading the code and may be fragile --
small changes to PyObject_Length/Size, for example, might .
See also https://bugs.python.org/issue16602
--
components: Interpreter Core
messages: 354102
nosy: colesbury
priority: normal
severity: normal
status: open
title: proxy_contains (weakref.proxy) can access an object with 0 refcount
type: crash
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38395>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37910] argparse wrapping fails with metavar="" (no metavar)
Sam Franklin added the comment: Paul, very true. If I find time I may take a look at rewriting it as you suggest. For the moment, though, there's a relatively simple change that opens up a range of allowable whitespace characters. It's still a bandage, but it covers decent-sized area and should be easily backported. What do you think of the pull request? It's passed a first review. -- ___ Python tracker <https://bugs.python.org/issue37910> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43781] SIGSEGV when replacing _multiprocessing.SemLock at runtime
New submission from Sam Stern : When patching `_multiprocessing.SemLock` at runtime and then instantiating an instance of `multiprocessing.Pool`, the interpreter throws a SIGSEGV when trying to access a field of `_multiprocessing.SemLock` on pre-3.9 pythons -- components: Interpreter Core files: this-segfaults.py messages: 390577 nosy: sternj priority: normal severity: normal status: open title: SIGSEGV when replacing _multiprocessing.SemLock at runtime type: crash versions: Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file49945/this-segfaults.py ___ Python tracker <https://bugs.python.org/issue43781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43781] SIGSEGV when replacing _multiprocessing.SemLock at runtime
Sam Stern added the comment: This does not arise on 3.8.9 -- ___ Python tracker <https://bugs.python.org/issue43781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36153] Freeze support documentation is misleading.
Sam Schott added the comment: I think freeze_support becomes relevant always when the start method is spawn since `sys.executable` will point to the frozen app bundle instead of the Python interpreter. Spawn was historically only used on Windows (therefore the note in the docs) but now also is the default for macOS. The start method can of course also be set manually and it might therefore make more sense to specify the start method instead of the platform in the docs. -- nosy: +samschott ___ Python tracker <https://bugs.python.org/issue36153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44597] Poll returns POLLOUT on Pipe read endpoint on MacOS 10.14
New submission from Sam Harding : The behaviour of select.poll() is inconsistent across MacOS versions, on MacOS Mojave (10.14.6) registering and polling the receiving channel of mp.Pipe(duplex=False) returns the event POLLOUT (ready to write to). This is verified by a colleagues setup. Whereas on MacOS 11 the same scenario will not have poll() return that the receiving channel is ready for writing to (POLLOUT). Example: ### import select import multiprocessing as mp recv_end, send_end = mp.Pipe(duplex=False) poll = select.poll() poll.register(recv_end) print(poll.poll(1000)) ### MacOS 10.14.6 Result: > [(3,4)] MacOS 11.0.1 Result: > [] I am assuming that the MacOS 11 behaviour is should be the expected behaviour, and that the recv connection from a Pipe should never return that it is writable. This was tested with Python 3.9.4, and 3.7.6. -- components: Extension Modules, macOS messages: 397246 nosy: ned.deily, ronaldoussoren, samh42 priority: normal severity: normal status: open title: Poll returns POLLOUT on Pipe read endpoint on MacOS 10.14 type: behavior versions: Python 3.7, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29753] [Linux] ctypes packs bitfields Incorrectly
Sam Price added the comment: I’ve been looking forward to this fix. The old implementation did not match what my LLVM compiler generated. On Sun, Jul 11, 2021 at 2:52 PM Charles Machalow wrote: > > Charles Machalow added the comment: > > Maybe we need to add a __packing__ option to specify how packing should > work and default to legacy behavior. Then allow users to specify if they > want similar behavior cross-os. > > Otherwise changing this does change packing for existing users and can lead > to breakages. > > What exactly was the hit regression here? > > On Sun, Jul 11, 2021, 10:47 AM miss-islington > wrote: > > > > > miss-islington added the > > comment: > > > > > > New changeset 42da46ed522157b057d73e6b623615ef6427999e by Miss Islington > > (bot) in branch '3.10': > > bpo-29753: revert 0d7ad9f (GH-19850) (GH-27085) > > > > > https://github.com/python/cpython/commit/42da46ed522157b057d73e6b623615ef6427999e > > > > > > -- > > > > ___ > > Python tracker > > <https://bugs.python.org/issue29753> > > ___ > > > > -- > > ___ > Python tracker > <https://bugs.python.org/issue29753> > ___ > -- Thank you, Sam Price (707) 742-3726 -- ___ Python tracker <https://bugs.python.org/issue29753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44657] instancemethod_call should use PyInstanceMethod_GET_FUNCTION macro
New submission from Sam Gross : The instancemethod_call function should use the PyInstanceMethod_GET_FUNCTION macro instead of the PyMethod_GET_FUNCTION macro. The current code is incorrect, but still works okay (doesn't crash) because PyInstanceMethodObject.func is at the same offset as PyMethodObject.im_func. https://github.com/python/cpython/blob/c90c591e5158ab7b531dcd6e2a5f00bc70ba7637/Objects/classobject.c#L465 -- components: Interpreter Core messages: 397660 nosy: colesbury priority: normal severity: normal status: open title: instancemethod_call should use PyInstanceMethod_GET_FUNCTION macro 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/issue44657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44657] instancemethod_call should use PyInstanceMethod_GET_FUNCTION macro
Change by Sam Gross : -- type: enhancement -> behavior ___ Python tracker <https://bugs.python.org/issue44657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44815] asyncio.gather no DeprecationWarning if task are passed
New submission from Sam Bull : When calling asyncio.gather() a DeprecationWarning is only emitted if no tasks are passed (which is probably the exceptional case, rather than the standard one). This has resulted in us missing this deprecated argument in aiohttp until we received a bug report from a user trying it out against the 3.10 beta. For some reason the warning only appears under a `if not coros_or_futures:` block. I think it should be run regardless: https://github.com/python/cpython/blob/3.9/Lib/asyncio/tasks.py#L757 -- components: asyncio messages: 398794 nosy: asvetlov, dreamsorcerer, yselivanov priority: normal severity: normal status: open title: asyncio.gather no DeprecationWarning if task are passed versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44815] asyncio.gather no DeprecationWarning if task are passed
Change by Sam Bull : -- keywords: +patch pull_requests: +26075 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27568 ___ Python tracker <https://bugs.python.org/issue44815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44815] asyncio.gather no DeprecationWarning if task are passed
Sam Bull added the comment: There is another issue with asyncio.sleep() too, if the passed argument is 0. This also tripped up the tests in aiohttp (though I've also used an explicit 0 in production code to yield back to the loop). -- ___ Python tracker <https://bugs.python.org/issue44815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44815] asyncio.gather no DeprecationWarning if task are passed
Change by Sam Bull : -- pull_requests: +26076 pull_request: https://github.com/python/cpython/pull/27569 ___ Python tracker <https://bugs.python.org/issue44815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition
Change by Sam Bull : -- nosy: +dreamsorcerer nosy_count: 8.0 -> 9.0 pull_requests: +26587 pull_request: https://github.com/python/cpython/pull/28149 ___ Python tracker <https://bugs.python.org/issue42130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45098] asyncio.CancelledError should contain more information on cancellations
New submission from Sam Bull : There are awkward edge cases caused by race conditions when cancelling tasks which make it impossible to reliably cancel a task. For example, in the async-timeout library there appears to be no way to avoid suppressing an explicit t.cancel() if that cancellation occurs immediately after the timeout. In the alternative case where a cancellation happens immediately before the timeout, the solutions feel dependant on the internal details of how asynico.Task works and could easily break if the behaviour is tweaked in some way. What we really need to know is how many times a task was cancelled as a cause of the CancelledError and ideally were the cancellations caused by us. The solution I'd like to propose is that the args on the exception contain all the messages of every cancel() call leading up to that exception, rather than just the first one. e.g. In these race conditions e.args would look like (None, SENTINEL), where SENTINEL was sent in our own cancellations. From this we can see that the task was cancelled twice and only one was caused by us, therefore we don't want to suppress the CancelledError. For more details to fully understand the problem: https://github.com/aio-libs/async-timeout/pull/230 https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523 https://github.com/aio-libs/async-timeout/pull/237 -- components: asyncio messages: 401045 nosy: asvetlov, dreamsorcerer, yselivanov priority: normal severity: normal status: open title: asyncio.CancelledError should contain more information on cancellations type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44751] crypt.h should be in _cryptmodule.c, not in public header
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45331] Can create enum of ranges, cannot create range enum. Range should be subclassable... or EnumMeta.__new__ should be smarter.
New submission from Sam Bishop : Range types are perfectly valid as values in an enum, like so. class EnumOfRanges(Enum): ZERO = range(0, 0) RANGE_A = range(1, 11) RANGE_B = range(11, 26) However unlike the other base types , 'int', 'str', 'float', etc. You cannot create a "range enum" class RangeEnum(range, Enum): ZERO = range(0, 0) RANGE_A = range(1, 11) RANGE_B = range(11, 26) produces `TypeError: type 'range' is not an acceptable base type` when you try and import `RangeEnum`. The current documentation for `enum` implicitly says this should work by not mentioning anything special here https://docs.python.org/3/library/enum.html#others It also allows the use of range objects as value types, another implicit suggestion that we should be able to restrict an enum class to just range values like we can for other builtin class types. Also to keep this a concise issue: - Yes I'm aware not all of the base classes can be subclassed. - Yes I know I that there are good reasons bool should not be subclassable. So I'd like to suggest one of three things should be done to improve the situation: A: Solve https://bugs.python.org/issue17279 and by documenting the special base class objects that cannot be subclassed and reference this in the documentation for Enums. B: Make a decision as to which base class objects we should be able to subclass, and then improve their C implementations to allow subclassing. (It's also probably worth documenting the final list of special objects and solving https://bugs.python.org/issue17279 should this approach be selected.) C: The __new__ method on EnumMeta should be made smarter so that it either emits a more useful warning (I had to head to the CPython source code to work out what the error `TypeError: type 'range' is not an acceptable base type` meant) or somehow being more smart about how it handles the special classes which can't cannot be subclassed allowing them to be used anyway. which again sort of involves solving https://bugs.python.org/issue17279, and in the case that its just made magically smarter, I'll admit could confuse some people as to why "Enum" is special and can subclass these but their own code can't just do `class MyRange(range):` Regardless of the outcome, it would be good to fill in this pitfall one way or the other for the sake of future developers, I'm a reasonably experienced Python developer and it caught me by surprise I'm likely not the first and probably wont be the last if the behaviour remains as it currently is. -- components: Interpreter Core messages: 402960 nosy: techdragon priority: normal severity: normal status: open title: Can create enum of ranges, cannot create range enum. Range should be subclassable... or EnumMeta.__new__ should be smarter. type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45433] libpython should not be linked with libcrypt
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37658] In some cases asyncio.wait_for can lead to socket leak.
Change by Sam Bull : -- nosy: +dreamsorcerer nosy_count: 10.0 -> 11.0 pull_requests: +27471 pull_request: https://github.com/python/cpython/pull/29202 ___ Python tracker <https://bugs.python.org/issue37658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37658] In some cases asyncio.wait_for can lead to socket leak.
Sam Bull added the comment: Can I get a review? https://github.com/python/cpython/pull/29202 Seems like a simple mistake given the original description of this issue: > 1. the inner task is completed and the outer task will receive the result – > transport and protocol in this case > 2. The inner task is cancelled and no connection was established The try/except blocks clearly add a 3rd condition, where the inner task is completed and a TimeoutError is raised without returning the result. -- ___ Python tracker <https://bugs.python.org/issue37658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Change by Sam Gross : -- assignee: docs@python -> colesbury ___ Python tracker <https://bugs.python.org/issue28737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Sam Gross added the comment: Antoine Pitrou already fixed the "noddy4" example (now renamed to "custom4") and updated the newtypes_tutorial, but I think it's still worth mentioning PyObject_GC_Untrack in a few additional places. -- ___ Python tracker <https://bugs.python.org/issue28737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Change by Sam Gross : -- keywords: +patch pull_requests: +27510 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29246 ___ Python tracker <https://bugs.python.org/issue28737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Change by Sam Gross : -- pull_requests: +27513 pull_request: https://github.com/python/cpython/pull/29249 ___ Python tracker <https://bugs.python.org/issue28737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45668] Some PGO tests are failing when building with --enable-optimizations --disable-test-modules
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45484] test_pickle segfault on s390x RHEL7 LTO 3.x
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45256] Remove the usage of the C stack in Python to Python calls
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45643] SIGSTKFLT is missing from the signals module on Linux
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45350] configure incorrectly ignores pkg-config information for libffi and Tcl/Tk in 3.10
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45598] setup.py grep_headers_for() is broken by design
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with a non-system libffi?
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue14527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45809] Race condition in WeakKeyDictionary/WeakKeyDictionary
New submission from Sam Gross : The issue described issue7105 (and maybe issue7060) still exists due to a race condition in WeakKeyDictionary. This shows up as test failure that looks like: test test_weakref failed -- Traceback (most recent call last): File "Lib/test/test_weakref.py", line 1960, in test_threaded_weak_value_dict_deepcopy self.check_threaded_weak_dict_copy(weakref.WeakValueDictionary, True) File "Lib/test/test_weakref.py", line 1940, in check_threaded_weak_dict_copy raise exc[0] File "Lib/test/test_weakref.py", line 1897, in dict_copy _ = copy.deepcopy(d) File "Lib/copy.py", line 153, in deepcopy y = copier(memo) File "Lib/weakref.py", line 189, in __deepcopy__ for key, wr in self.data.items(): RuntimeError: dictionary changed size during iteration The cause is that the check of "self._iterating" and the call to "_atomic_removal" are not performed atomically together. By the time _atomic_removal() is called, an iteration might have already started. https://github.com/python/cpython/blob/ec382fac0db6d9159c2d3496a70b7a605545957e/Lib/weakref.py#L109-L114 -- components: Library (Lib) messages: 406357 nosy: colesbury priority: normal severity: normal status: open title: Race condition in WeakKeyDictionary/WeakKeyDictionary type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45809] Race condition in WeakKeyDictionary/WeakKeyDictionary
Sam Gross added the comment: The attached patch (issue45809-repro.patch) introduces artificial delays to make reproduction of the underlying issue easier. To reproduce the issue: patch -p1 < issue45809-repro.patch ./python -m test test_weakref -m test_threaded_weak_value_dict_deepcopy -v -- keywords: +patch Added file: https://bugs.python.org/file50440/issue45809-repro.patch ___ Python tracker <https://bugs.python.org/issue45809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42540] Debug pymalloc crash when using os.fork() [regression]
Change by Sam Gross : -- keywords: +patch nosy: +colesbury nosy_count: 2.0 -> 3.0 pull_requests: +27812 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29564 ___ Python tracker <https://bugs.python.org/issue42540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful
Sam Gross added the comment: The `pthread_exit` behavior has been a problem for PyTorch and related libraries since Python 3.9. The PyTorch team has tried working around the problems without success (i.e. they keep getting bug reports involving crashes in PyEval_SaveThread/RestoreThread). The hang/paused the thread behavior suggested by jbms and gps seems like the only reliable option. This is also what the Java VM does when returning from native code and the JVM has exited. I believe it's not difficult to hang a thread in a cross-platform way: create a mutex, acquire it in the main thread (before setting PyRuntime._finalizing), never release it. Other threads can acquire that same mutex to block until the application exits. The crashes can occur even without daemon threads if the user presses ctrl-c while _thread_shutdown is running. -- nosy: +colesbury ___ Python tracker <https://bugs.python.org/issue42969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42540] Debug pymalloc crash when using os.fork() [regression]
Change by Sam Gross : -- pull_requests: +27843 pull_request: https://github.com/python/cpython/pull/29600 ___ Python tracker <https://bugs.python.org/issue42540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45835] Race condition in test_queue can lead to test failures
New submission from Sam Gross : The test_queue suite has a race condition that can lead to test failures in test_many_threads, test_many_threads_nonblock, and test_many_threads_timeout. Consumers are signaled to exit by a sentinel value (None). The sentinel values are at the end of the input list, but that doesn't mean they are necessarily enqueued at the end of the inter-thread queue when there are multiple "feeder" threads. In particular, a feeder thread may be delayed in enqueueing a non-sentinel value. The other feeder threads may finish popping and enqueueing the remaining values including all the sentinels, leading to the delayed non-sentinel value arriving AFTER all the sentinels. The "consumer" threads exit before processing all the values leading to the assertion error in run_threads() in test_queue.py: self.assertTrue(q.empty()) I will attach a patch that adds a delay in feed() to make the race condition occur more frequently so that the issue is easier to reproduce. -- components: Tests messages: 406498 nosy: colesbury priority: normal severity: normal status: open title: Race condition in test_queue can lead to test failures type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45835] Race condition in test_queue can lead to test failures
Change by Sam Gross : -- keywords: +patch Added file: https://bugs.python.org/file50447/issue45835_repro.patch ___ Python tracker <https://bugs.python.org/issue45835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45835] Race condition in test_queue can lead to test failures
Change by Sam Gross : -- pull_requests: +27844 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29601 ___ Python tracker <https://bugs.python.org/issue45835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45838] Incorrect line numbers in GDB Python backtraces [3.9]
New submission from Sam Gross : Starting in Python 3.6 the line numbers table contains a *signed* byte indicating line delta. The calculation in Tools/gdb/libpython.py was not updated to handle signed bytes leading to incorrect line numbers when running "py-bt" (or printing frames) in GDB. This issue does not exist in Python 3.10 or later because line number table was changed (and libpython.py was updated) in GH-23113. -- components: Demos and Tools messages: 406560 nosy: colesbury priority: normal severity: normal status: open title: Incorrect line numbers in GDB Python backtraces [3.9] type: behavior versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45838] Incorrect line numbers in GDB Python backtraces [3.9]
Change by Sam Gross : -- keywords: +patch pull_requests: +27860 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29628 ___ Python tracker <https://bugs.python.org/issue45838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition
Sam Bull added the comment: It has been addressed, PR should be merged this week: https://github.com/python/cpython/pull/28149 Like most open source projects, it just needed someone to actually propose a fix. -- ___ Python tracker <https://bugs.python.org/issue42130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
