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

2022-02-11 Thread James Gerity 


Change by James Gerity :


--
nosy: +SnoopJeDi

___
Python tracker 
<https://bugs.python.org/issue46726>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46555] Unicode-mangled names refer inconsistently to constants

2022-01-31 Thread James Gerity 

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) building the AST. 
Normalization happens after (1), and `핋핣핦핖 = 0` is valid syntax because the 
grammar is NOT defined in terms of normalized identifiers, it's describing the 
valid (but confusing!) assignment that Carl described.

I agree that this doesn't seem like bug, but it IS my new favorite quirk of 
identifier normalization.

--

___
Python tracker 
<https://bugs.python.org/issue46555>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46555] Unicode-mangled names refer inconsistently to constants

2022-01-28 Thread James Gerity 


Change by James Gerity :


--
nosy: +SnoopJeDi

___
Python tracker 
<https://bugs.python.org/issue46555>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46282] return value of builtins is not clearly indicated

2022-01-25 Thread James Gerity 


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()
* help()
* print()
* setattr()

Which makes me wonder if the hint is even worth having, since it's so few of 
them.

Note that of these, exec() does what this ticket originally proposed for 
print() - i.e. it explicitly says that the function returns None.

--

___
Python tracker 
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46282] return value of builtins is not clearly indicated

2022-01-25 Thread James Gerity 

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 little more clear, but that isn't the scope of this ticket.

The title change reflects my intent to submit a PR that adds a hint to the 
builtins doc.

--

___
Python tracker 
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46282] return value of builtins is not clearly indicated

2022-01-25 Thread James Gerity 


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/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2022-01-06 Thread James Gerity 


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 signature?
   
09:34:27 ringo__ | for example, 
https://docs.python.org/3/library/functions.html, function  

   
 | abs(x), it returns what, int? I need to read the 
whole sentence to figure
   
 | out the return value of a function?  

   
09:34:48 ringo__ | (or argument for that matter)

   
09:35:51 bjs | ringo__: well like it says it doesn't just support 
int 
 
09:36:00 bjs | int, float, or any type that supports it 

   
09:37:01 bjs | in general you can find actual type annotations for 
the functions in the

 | typeshed 

   
 | 
https://github.com/python/typeshed/blob/master/stdlib/builtins.pyi  


09:37:32 bjs | I wonder if it would be useful to include the 
typeshed annotation in the  
  
 | docs, or whether it would be more confusing  

   
09:37:49 ringo__ | Thanks bjs ! I'll bookmark this typeshed 

   
09:38:13  SnoopJ | abs() will do whatever __abs__() on the type does, 
which can be different  
 
 | for any given type. You'd expect T -> T but it's not 
guaranteed. 
   
09:38:18 ringo__ | I used abs() as an example. In fact I was wondering 
what does print()   

 | return. I *guessed* it returns None, but the docs 
won't say   
  
09:39:05 ringo__ | I could do a try-it-yourself approach but I was 
puzzled why the docs

 | simply won't give you full fn signature, ie 
print(..) -> None   

09:39:17  SnoopJ | that one is just an omission :)
```

--

___
Python tracker 
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2022-01-06 Thread James Gerity 


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 scope of this issue. I do think it's worth mentioning 
for print(), though.

--

___
Python tracker 
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2022-01-06 Thread James Gerity 


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/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2022-01-06 Thread James Gerity 


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 
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2021-12-06 Thread James Gerity 


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/issue46001>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2021-12-06 Thread James Gerity 


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/issue46001>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2021-12-06 Thread James Gerity 


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 reference to recursion.

Since the fix for bpo-43225 (7b78d43) the string-escaping machinery in 
`_json.c` is capable of raising OverflowError, but the reference in the 
documentation predates this addition by quite a long time.

--
assignee: docs@python
components: Documentation
messages: 407837
nosy: SnoopJeDi, docs@python
priority: normal
severity: normal
status: open
title: JSON module documentation mentions OverflowError for case that raises 
RecursionError
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue46001>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2021-11-29 Thread James Gerity 


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 be closed.

If anybody comes to this issue with the same problem, you can `make 
profile-removal` or `make clobber` to get GNU Make to clean up the PGO data, or 
you can remove the files yourself with the `find` invocation.

--
nosy: +SnoopJeDi

___
Python tracker 
<https://bugs.python.org/issue34820>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2021-06-03 Thread James Gerity 


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 that isn't '__main__'. 

Not sure if this is stating the obvious and I don't see any general solution 
short of adding a filter for the special filenames, but I caught wind of this 
in #python on Libera, got curious, and thought I'd share what I learned here. 
I've also attached a gdb session showing how changing the filename affects this 
behavior.

Reproducing this in debug/dev contexts is definitely fraught, since the warning 
behavior is different.

[1] The given compile() sample, at the REPL, when using -c, or when piping 
input via stdin are the ones I know about
[2] 
https://github.com/python/cpython/blob/f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970/Parser/string_parser.c#L19-L20

--
nosy: +SnoopJeDi2
Added file: https://bugs.python.org/file50091/gdb_deprecationwarning_session.txt

___
Python tracker 
<https://bugs.python.org/issue40199>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42485] Full grammar specification should link to PEP 617

2020-11-27 Thread James Gerity 


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/issue42485>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42485] Full grammar specification should link to PEP 617

2020-11-27 Thread James Gerity 


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: Documentation
messages: 381954
nosy: docs@python, snoopjedi
priority: normal
severity: normal
status: open
title: Full grammar specification should link to PEP 617
versions: Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue42485>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2019-10-23 Thread James Gerity 


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 well as '_'. If the ASCII flag 
> is used, only [a-zA-Z0-9_] is matched.

I think it'd also be nice for the term "alphanumeric Unicode character" to link 
to the documentation for `str.isalnum()`, which provides enough clarity for the 
user to work out exactly what Unicode category properties will end up 
qualifying as a match.

--

___
Python tracker 
<https://bugs.python.org/issue38566>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

2019-10-23 Thread James Gerity 

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 Technical Standard #18², which defines the class `` to 
include all alphabetic and decimal codepoints, as well as U+200C ZERO WIDTH 
NON-JOINER and U+200D ZERO WIDTH JOINER. This does not appear to be a correct 
description of `re`, however, as these zero-width characters are not counted 
when matching '\w', e.g.:

```
>>> re.match('\w*', 'Auf\u200Clage')

```

It seems from examining the CPython source³ that SRE treats '\w' as meaning any 
alphanumeric character OR U+005F SPACING UNDERSCORE, which does not match any 
Unicode class definition I've been able to find.

Can anyone provide clarification on what part of Unicode this documentation is 
referring to? If there is some other definition, the documentation should be 
more specific about referring to it (and including a link would be preferred). 
If instead the documentation is incorrect, this language should be changed to 
describe the true meaning of \w.

¹ https://docs.python.org/3/library/re.html#index-32
² http://unicode.org/reports/tr18/
³ https://github.com/python/cpython/blob/master/Modules/_sre.c#L125

--
assignee: docs@python
components: Documentation
messages: 355239
nosy: docs@python, snoopjedi
priority: normal
severity: normal
status: open
title: Description of '\w' behavior is vague in `re` documentation

___
Python tracker 
<https://bugs.python.org/issue38566>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com