[issue46726] Thread spuriously marked dead after interrupting a join call

Change by James Gerity : -- nosy: +SnoopJeDi ___ Python tracker <https://bugs.python.org/issue46726> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46555] Unicode-mangled names refer inconsistently to constants

James Gerity added the comment: > Why was it decided to not raise a syntax error... I'm not sure if such a decision was even ever made, the error happens before normalization is applied. I.e. the parser is doing two things here: (1) validating the syntax against the grammar and (2) build

[issue46555] Unicode-mangled names refer inconsistently to constants

Change by James Gerity : -- nosy: +SnoopJeDi ___ Python tracker <https://bugs.python.org/issue46555> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46282] return value of builtins is not clearly indicated

James Gerity added the comment: My thought was to add something like this to the top of functions.rst: ``` Note that some of the functions listed here have the :ref:`default return value of ``None``. ``` For reference, the builtins this applies to are: * breakpoint() * delattr() * exec

[issue46282] return value of builtins is not clearly indicated

James Gerity added the comment: > advertising that all functions default to returning None This is already communicated in § 4.7 ("Defining Functions") of the official tutorial. I think it would be a good idea to revise that section so that this property of functions is a litt

[issue46282] return value of builtins is not clearly indicated

Change by James Gerity : -- title: print() docs do not indicate its return value -> return value of builtins is not clearly indicated ___ Python tracker <https://bugs.python.org/issu

[issue46282] print() docs do not indicate its return value

James Gerity added the comment: The original question was closer to the related issue of "indicate return types for all built-ins," conversation log follows (UTC-5): ``` 09:33:50 ringo__ | is there a stdlib api docs which actually has *full* functions

[issue46282] print() docs do not indicate its return value

James Gerity added the comment: I opened this ticket on behalf of a user who asked about print() specifically in #python on the Libera IRC network, who I assume does not find this obvious. I don't think it would be tenable to add this note to every built-in, but that's not the intended

[issue46282] print() docs do not indicate its return value

Change by James Gerity : -- keywords: +patch pull_requests: +28642 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30435 ___ Python tracker <https://bugs.python.org/issu

[issue46282] print() docs do not indicate its return value

Change by James Gerity : -- assignee: docs@python components: Documentation nosy: SnoopJeDi, docs@python priority: normal severity: normal status: open title: print() docs do not indicate its return value versions: Python 3.11 ___ Python tracker

[issue46001] JSON module documentation mentions OverflowError for case that raises RecursionError

James Gerity added the comment: Correction: the bug whose resolution adds the OverflowError mentioned above is bpo-24522, not bpo-43255 -- ___ Python tracker <https://bugs.python.org/issue46

[issue46001] JSON module documentation mentions OverflowError for case that raises RecursionError

Change by James Gerity : -- keywords: +patch pull_requests: +28168 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29943 ___ Python tracker <https://bugs.python.org/issu

[issue46001] JSON module documentation mentions OverflowError for case that raises RecursionError

New submission from James Gerity : The docstrings for `json.JSONEncoder, json.dump(), json.dumps()` all refer to `OverflowError` when describing the behavior of the `check_circular` parameter, but the module's test of this parameter catches a `RecursionError` and the documentation does make

[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

James Gerity added the comment: The Makefile issue was fixed in bpo-37725 (GitHub: https://github.com/python/cpython/commit/c6bbcd258302b4b9b3d4f3c39bb5f7ff0120ec67), but the change wasn't ported to the 3.7, 3.8 branches. Those versions are now security-only, so this issue can probably just

[issue40199] Invalid escape sequence DeprecationWarnings don't trigger by default

James Gerity added the comment: The cause of DeprecationWarning sometimes [1] not being issued is I believe because in string_parser.c [2] the module is explicitly set to NULL and the filename will be '' or '' or somesuch, which eventually that ends up being normalized to something

[issue42485] Full grammar specification should link to PEP 617

Change by James Gerity : -- keywords: +patch nosy: +SnoopJeDi2 nosy_count: 2.0 -> 3.0 pull_requests: +22414 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23532 ___ Python tracker <https://bugs.python.org/i

[issue42485] Full grammar specification should link to PEP 617

New submission from James Gerity : Now that CPython uses the new PEG parser, it would be helpful to include a reference to the guiding PEP (617) on the docs page (https://docs.python.org/3/reference/grammar.html) that gives the grammar. -- assignee: docs@python components

[issue38566] Description of '\w' behavior is vague in `re` documentation

James Gerity added the comment: Cheers for the additional context. My recommendation would be to change the language to avoid confusion with the consortium's formal specifications. Describing what SRE does should be fine: > Matches any alphanumeric Unicode character, as w

[issue38566] Description of '\w' behavior is vague in `re` documentation

New submission from James Gerity : The documentation for the `re` library¹ describes the behavior of the specifier '\w' as matching "Unicode word characters," which is very vague. The closest thing I can find that corresponds to this language is the guidance offered in Unicode