[issue46150] test_pathlib assumes "fakeuser" does not exist as user

[Gregory P. Smith]

Change by Gregory P. Smith :


--
pull_requests: +28466
pull_request: https://github.com/python/cpython/pull/30244

___
Python tracker 

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

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Thanks, Guido!

> Yes, it is too late for 3.10 (but you can add it to typing_extensions). Also, 
> PEP 585 is done, we don't update PEPs. 

Got it!

> Please do test with `from __future__ import annotations` -- you never know.

Done, PR is updated. Now we test that `property` works with future import.

> When this was first proposed (https://github.com/python/typing/issues/985) 
> there were worries about backwards compatibility. Given how common property 
> is, we need to make sure there are no problems with that. Can you address 
> that? I don't see it in the original thread.

I guess you were thinking about this one: 
https://github.com/python/typing/issues/594

Here's a list of problem from the original thread:

## the returned value of property has no typing equivalent

Now there is: `property[G, S]`

## There is no consistency in how properties in classes work in comparison to 
normal variables or functions

Author points out that all python versions right now ignore `property`s when 
`get_type_hints()` is used. There's nothing we can do here: it is not related 
to `property`s being generic in any way.

Here's how it works before my patch:

```python
Python 3.10.0 (default, Nov  1 2021, 10:24:06) [Clang 11.0.0 
(clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from typing import get_type_hints
>>> class Some:
...   @property
...   def a(self) -> int:
... return 1
... 
>>> get_type_hints(Some)
{}
>>> get_type_hints(Some.a)
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/typing.py", line 
1827, in get_type_hints
raise TypeError('{!r} is not a module, class, method, '
TypeError:  is not a module, class, method, or 
function.
```

I've added a test case for my patch to make sure this behavior is not changed. 
And indeed, it works exactly the same as before.

I've also covered a part from 
https://github.com/python/typing/issues/594#issuecomment-627692188

Runtime introspection of `fget` / `fset` / `fdel` works the same as before. 
I've added a test case for this.

## Forward compat

Users of python<3.11 will have `property` with `[]` type syntax via 
`typing_extensions`.
I don't think it is going to be widely used, though.

> Also, since this requires type checkers to change, do we need a PEP?

I cannot speak for all type-checkers, but I know how it works in mypy. Mypy 
already supports descriptors. So, this example works:

```python
class Desc:
def __get__(self, obj, typ) -> int: pass

class Some:
a = Desc()

s = Some()
reveal_type(s.a) # N: Revealed type is "builtins.int"
reveal_type(Some.a)  # N: Revealed type is "builtins.int"
```

The same just works for my `property` stub example from 
https://github.com/python/typing/issues/985

All in all, I don't think that we need a PEP for three reasons:
1. properties are already supported in all type checkers (with special casing), 
if it does not cause any trouble, existing behavior can be left untouched. Mypy 
has multiple problem with our special casing
2. Underlying mechanism - which are descriptors - is also supported
3. Change is relatively small, it does not add any new concepts

Feedback on this is welcome! Maybe I am missing something.

> Honestly I think it's too soon for a PR given that we don't seem to have 
> agreement in the typing tracker discussion.

This PR is really small. It took me like 30 mins, but we have a reference now. 
We can close it anytime with no damage done!

--

___
Python tracker 

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

[issue46150] test_pathlib assumes "fakeuser" does not exist as user

[Gregory P. Smith]

Change by Gregory P. Smith :


--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +28465
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30247

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Guido van Rossum]

Guido van Rossum  added the comment:

I like the lookahead. We could also make the comma and the message mandatory 
when inside parentheses:

| 'assert' '(' a=expression ',' b=expression [','] ')' &(NEWLINE | ';')
| 'assert' a=expression b=[',' z=expression { z }]

(And probably add an "invalid" rule to cover tuples with 0, 1, 3 or more 
elements.)

--

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Eric V. Smith]

Eric V. Smith  added the comment:

@karzes: If you read all of the messages above, you'll find that the behavior 
is deeply baked in to argparse. So, no, there is no fix for this issue.

I'm not sure about others, but I believe that the behavior is so deeply 
ingrained in how argparse works that it can't be changed. I have the same 
desire as you: to use a command line parser that works like all other Unix 
commands. I've switched my personal code to click. There's also Appeal, typer, 
and others.

Unlike when argparse was added to the stdlib, at this point installing modules 
from PyPI is sufficiently easy that I'm not sure it makes sense to advocate for 
another command line parser in the stdlib.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Another possibility is actually handled this in the compiler:

if we see an assert with a tuple of two elements, we can assume is basically in 
the form that we want and proceed as if is in the form
assert A, B

This also feels a bit hacky because the AST is somehow wrong as the assert node 
is already prepared to differentiate these two cases.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

We could do this, but feels a bit hacky:

| 'assert' '(' a=expression b=[',' z=expression { z }] ')' &(NEWLINE | ';')
| 'assert' a=expression b=[',' z=expression { z }]

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> We managed to do this for 'with' so it should be possible here too, I'd 
> think. The "committing" token would be the newline following the close 
> parenthesis.


I am not so sure is that inmediate. Changing the assert statement from:

 'assert' a=expression b=[',' z=expression { z }]

to

| 'assert' '(' a=expression b=[',' z=expression { z }] ')'
| 'assert' a=expression b=[',' z=expression { z }] 

will render this invalid:

assert (a, b) <= c, "something"

The reason is that it will parse the (a, b) as the assert statement eagerly and 
then it will fail to parse the rest.

--

___
Python tracker 

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

[issue46117] tk could not refresh auto in mac os

[asper]

asper  added the comment:

tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.11
zlib.ZLIB_RUNTIME_VERSION: 1.2.11
zlib.ZLIB_VERSION: 1.2.11
On my system, it shows like that.
It works well if not change the widnow's size of program, but once change the 
window's size manually, press "change" button, it shows a little delay.

--

___
Python tracker 

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

[issue46165] pythin is core dumping with SIGILL in pytest of the jupyter-server

[Tomasz Kloczko]

Tomasz Kloczko  added the comment:

OK accorting to your expertise this could be somethning wrong in some of the 
DSOs ..

May I ask for a little help with pointing on possible module which i doing 
sometbing wrong?

Just looking on top of the call trace 

#0  0x7f480be7a54c __pthread_kill_implementation (libc.so.6 
+ 0x8f54c)
#1  0x7f480be2d696 raise (libc.so.6 + 0x42696)
#2  0x7f480be2d740 __restore_rt (libc.so.6 + 0x42740)
#3  0x7f47f9fbe8ff blake2b_init (libargon2.so.1 + 0x38ff)
#4  0x7f47f9fbfb0e argon2_ctx.part.0 (libargon2.so.1 + 
0x4b0e)
#5  0x7f47f9fc0a9f argon2_hash (libargon2.so.1 + 0x5a9f)
#6  0x7f47f9fc8f16 _cffi_f_argon2_hash (_ffi.abi3.so + 
0x2f16)
#7  0x7f480c0a0077 cfunction_call_varargs 
(libpython3.8.so.1.0 + 0xb7077)
#8  0x7f480c10febb _PyObject_MakeTpCall 
(libpython3.8.so.1.0 + 0x126ebb)
#9  0x7f480c05eee4 _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x75ee4)
#10 0x7f480c1781b7 _PyEval_EvalCodeWithName 
(libpython3.8.so.1.0 + 0x18f1b7)
#11 0x7f480c1787e3 _PyFunction_Vectorcall 
(libpython3.8.so.1.0 + 0x18f7e3)
#12 0x7f480c05d42c _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x7442c)
#13 0x7f480c05897b function_code_fastcall 
(libpython3.8.so.1.0 + 0x6f97b)
#14 0x7f480c05d8e3 _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x748e3)
#15 0x7f480c1781b7 _PyEval_EvalCodeWithName 
(libpython3.8.so.1.0 + 0x18f1b7)
#16 0x7f480c1787e3 _PyFunction_Vectorcall 
(libpython3.8.so.1.0 + 0x18f7e3)
#17 0x7f480c05d3e0 _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x743e0)
#18 0x7f480c1781b7 _PyEval_EvalCodeWithName 
(libpython3.8.so.1.0 + 0x18f1b7)
#19 0x7f480c1784e7 PyEval_EvalCode (libpython3.8.so.1.0 + 
0x18f4e7)
#20 0x7f480c1d9295 builtin_exec (libpython3.8.so.1.0 + 
0x1f0295)
#21 0x7f480c176c37 cfunction_vectorcall_FASTCALL 
(libpython3.8.so.1.0 + 0x18dc37)
#22 0x7f480c05d3e0 _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x743e0)
#23 0x7f480c05897b function_code_fastcall 
(libpython3.8.so.1.0 + 0x6f97b)
#24 0x7f480c05d8e3 _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x748e3)
#25 0x7f480c1781b7 _PyEval_EvalCodeWithName 
(libpython3.8.so.1.0 + 0x18f1b7)
#26 0x7f480c1787e3 _PyFunction_Vectorcall 
(libpython3.8.so.1.0 + 0x18f7e3)
#27 0x7f480c05e93d _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x7593d)
#28 0x7f480c1781b7 _PyEval_EvalCodeWithName 
(libpython3.8.so.1.0 + 0x18f1b7)
#29 0x7f480c1787e3 _PyFunction_Vectorcall 
(libpython3.8.so.1.0 + 0x18f7e3)
#30 0x7f480c132c9a method_vectorcall (libpython3.8.so.1.0 + 
0x149c9a)
#31 0x7f480c05d42c _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x7442c)
#32 0x7f480c05897b function_code_fastcall 
(libpython3.8.so.1.0 + 0x6f97b)
#33 0x7f480c05d8e3 _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x748e3)
#34 0x7f480c05897b function_code_fastcall 
(libpython3.8.so.1.0 + 0x6f97b)
#35 0x7f480c1100bd PyVectorcall_Call (libpython3.8.so.1.0 + 
0x1270bd)
#36 0x7f480c05ada7 _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x71da7)
#37 0x7f480c1781b7 _PyEval_EvalCodeWithName 
(libpython3.8.so.1.0 + 0x18f1b7)
#38 0x7f480c1787e3 _PyFunction_Vectorcall 
(libpython3.8.so.1.0 + 0x18f7e3)
#39 0x7f480c05e93d _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x7593d)
#40 0x7f480c05897b function_code_fastcall 
(libpython3.8.so.1.0 + 0x6f97b)
#41 0x7f480c132c9a method_vectorcall (libpython3.8.so.1.0 + 
0x149c9a)
#42 0x7f480c05e93d _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x7593d)
#43 0x7f480c1781b7 _PyEval_EvalCodeWithName 
(libpython3.8.so.1.0 + 0x18f1b7)
#44 0x7f480c1787e3 _PyFunction_Vectorcall 
(libpython3.8.so.1.0 + 0x18f7e3)
#45 0x7f480c110246 _PyObject_FastCallDict 
(libpython3.8.so.1.0 + 0x127246)
#46 0x7f480c11042d _PyObject_Call_Prepend 
(libpython3.8.so.1.0 + 0x12742d)
#47 0x7f480c110501 slot_tp_call (libpython3.8.so.1.0 + 
0x127501)
#48 0x7f480c0a01f4 PyObject_Call (libpython3.8.so.1.0 + 
0xb71f4)
#49 0x7f480c05ada7 _PyEval_EvalFrameDefault 
(libpython3.8.so.1.0 + 0x71da7)
#50 0x7f480c1781b7 _PyEval_EvalCodeWithName 

[issue46169] Same-moment datetimes with different ZoneInfo timezones are not considered ==

[Daniel Diniz]

Daniel Diniz  added the comment:

Confirmed for 3.11 in Windows. 

The C datetime code can be trivially fixed so your equality test returns True, 
but there are two Python tests that depend on current behavior so it might not 
be so easy. They were added with current code in issue 24773, to implement PEP 
495 -- Local Time Disambiguation.

Also, using a timezone implementation from the test suite makes the equality 
work, so maybe the bug depends on zoneinfo.

If you change datetimemodule.c line 5761 from "diff = 1;" to "diff = 0;", two 
tests fail and your code works.

See attached file for the tests that fail and using the timezone implementation 
mentioned above.

--
nosy: +ajaksu2
Added file: https://bugs.python.org/file50517/dt_equality.py

___
Python tracker 

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

[issue46165] pythin is core dumping with SIGILL in pytest of the jupyter-server

[Christian Heimes]

Christian Heimes  added the comment:

The traceback indicates that it's a problem with a 3rd party extension module 
and not a bug in CPython core. The C stack suggests that your copy of libargon2 
is the root cause.

--
nosy: +christian.heimes
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type:  -> crash

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Guido van Rossum]

Guido van Rossum  added the comment:

We managed to do this for 'with' so it should be possible here too, I'd think. 
The "committing" token would be the newline following the close parenthesis.

Serhiy: the benefit is when you want to split it across two lines, e.g.

assert (a_very_long_condition(),
"A Very Long Message")

I know you can do this using backslash, e..

assert a_very_long_condition(), \
"A Very Long Message"

but there's a strong cultural rejection of backslash for line splitting (it's 
in PEP 8 and engrained in many people's brains) and it's just so natural to use 
parentheses -- they work for 'import', 'with', function calls, 'if', etc.

--

___
Python tracker 

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

[issue46090] C extensions can't swap out live frames anymore

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue37295] Possible optimizations for math.comb()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

[Mark]
> Should I code up my suggestion in a PR, 

Yes, go for it.

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> can we finally get rid of this language wart

Yes, please.  This is a pretty bad pitfall.

I've seen this happen to people who've been conditioned by other languages to 
think of assert() as a macro or function:

assert(sometest, somemessage)

--
nosy: +rhettinger

___
Python tracker 

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

[issue46170] Improving the error message when subclassing NewType

[Gobot1234]

New submission from Gobot1234 :

I'd like to propose making the error message when subclassing typing.NewType 
much more understandable. Currently it looks like:
```
TypeError: NewType.__init__() takes 3 positional arguments but 4 were given
```
But I think we could do much better by adding __mro_entries__ to the class and 
then just having that raise a TypeError telling users they cannot subclass 
NewType and they are probably looking for `NewType('Subclass', OlderType)`. I'd 
be happy to patch this myself if this sounds like a good idea.

--
components: Library (Lib)
messages: 409114
nosy: Gobot1234, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Improving the error message when subclassing NewType
type: enhancement
versions: Python 3.10

___
Python tracker 

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

[issue46169] Same-moment datetimes with different ZoneInfo timezones are not considered ==

[Huon Wilson]

New submission from Huon Wilson :

The documentation suggests that two datetimes that represent the same moment 
should compare equal, even if they have different timezones: "If both 
comparands are aware and have different tzinfo attributes, the comparands are 
first adjusted by subtracting their UTC offsets (obtained from 
self.utcoffset())." (below 
https://docs.python.org/3/library/datetime.html#datetime.datetime.fold)

This doesn't seem to be true for == with ZoneInfo timezones, even though it is 
true for <= and >=, and -, meaning these seem to violate mathematical 
laws/expectations:

from zoneinfo import ZoneInfo
from datetime import datetime, timezone

dt_utc = datetime(2020, 11, 1, 8, tzinfo=timezone.utc)
dt_local = dt_utc.astimezone(ZoneInfo("America/Los_Angeles"))
print(f"{dt_local == dt_utc = }")
print(f"{dt_local <= dt_utc = }")
print(f"{dt_local >= dt_utc = }")
print(f"{dt_local - dt_utc = }")

Output:

dt_local == dt_utc = False
dt_local <= dt_utc = True
dt_local >= dt_utc = True
dt_local - dt_utc = datetime.timedelta(0)

Tested with:

- macOS 11.4; Python 3.9.7, 3.10.1, 3.11.0a3
- Linux; via docker image python:3.9.7

Full test including comparisons to python-dateutil (same behaviour as ZoneInfo) 
and pytz (== gives True as expected) is attached.

Comparing timestamps for exact equality is potentially unusual, but we use it 
extensively in tests for some time-handling functions.

--
components: Library (Lib)
files: tz.py
messages: 409113
nosy: huonw
priority: normal
severity: normal
status: open
title: Same-moment datetimes with different ZoneInfo timezones are not 
considered ==
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50516/tz.py

___
Python tracker 

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

[issue504219] locale.resetlocale is broken

[Daniel Diniz]

Change by Daniel Diniz :


--
nosy: +ajaksu2
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.3, Python 
3.4

___
Python tracker 

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

[issue42673] Optimize round_size for rehashing

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Closing as it sounds like OP agreed to it in the last msg; and no benchmarking 
was provided.

--
nosy: +andrei.avk
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +gvanrossum, serhiy.storchaka

___
Python tracker 

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

[issue46168] Incorrect format specified for the "style" key in the configuration file format formatter example

[Daniel Diniz]

Daniel Diniz  added the comment:

This example was added in issue 43047. It only seems to affect 3.10+ docs. Ian, 
is this something you'd like to tackle?

--
keywords: +easy
nosy: +ajaksu2, iwienand
stage:  -> needs patch
versions: +Python 3.10, Python 3.11 -Python 3.8

___
Python tracker 

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

[issue37295] Possible optimizations for math.comb()

[Tim Peters]

Tim Peters  added the comment:

Please don't use "long long". It usually introduces platform dependence where 
none is intended, or helpful. PEP 7 requires that the compiler in use supply 
the fixed-width integer types defined by C99's stdint.h[1]. These are:

int8_t
int16_t
int32_t
int64_t
uint8_t
uint16_t
uint32_t
uint64_t

This has been required since Python 3.6. There is no reason not to use them.

[1] https://www.python.org/dev/peps/pep-0007/#c-dialect

--

___
Python tracker 

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

[issue45587] argparse add_argument_group: distinguish title and description from **kwargs

[SelfAdjointOperator]

New submission from SelfAdjointOperator :

This is a pretty trivial PR; Can it be merged? Nearly 2 months have gone by.

--

___
Python tracker 

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

[issue46168] Incorrect format specified for the "style" key in the configuration file format formatter example

[David Bereza]

New submission from David Bereza :

Documentation link: 
https://docs.python.org/3/library/logging.config.html#configuration-file-format

It seems that the example for the "formatter_form01" formatter section 
specifies following for the style(please note the single-quotes around the 
value). 
style='%'

This seems to raise a ValueError with the message "Style must be one of..." 
when parsing the configuration file. Removing the single quotes seems to fix 
the issue:
style=%

--
assignee: docs@python
components: Documentation
messages: 409108
nosy: bokunogf, docs@python
priority: normal
severity: normal
status: open
title: Incorrect format specified for the "style" key in the configuration file 
format formatter example
versions: Python 3.8

___
Python tracker 

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

[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

[Carl Friedrich Bolz-Tereick]

Carl Friedrich Bolz-Tereick  added the comment:

Or, in other words, in my opinion this is the root cause of the bug:

class Base:
def __init_subclass__(cls):
global broken_class
broken_class = cls
assert 0
try:
class Broken(Base): pass
except: pass
assert broken_class not in Base.__subclasses__()

The assert fails, which imo it shouldn't.

--

___
Python tracker 

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

[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results

[Carl Friedrich Bolz-Tereick]

Carl Friedrich Bolz-Tereick  added the comment:

hm, I think I figured it out. The root cause is that even though the creation 
of the class Triffid fails, it can still be found via Animal.__subclasses__(), 
which the special subclass logic for ABCs is looking at. Triffid fills its 
_abc_impl data with some content, but Triffid._abc_impl was never successfully 
initialized, therefore it mutates the _abc_impl of its first base class Animal.

My conclusion would be that if a class is not successfully created, it 
shouldn't appear in the .__subclasses__() list of its bases.

See attached script for some illuminating prints.

--
nosy: +Carl.Friedrich.Bolz
Added file: https://bugs.python.org/file50515/x.py

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Gregory P. Smith]

Gregory P. Smith  added the comment:

It's not about an advantage, it's about removing the problem of what edit to 
make when working on


assert 
thing_that_has_a_meaningful_name.methods_have_good_names(value_from_somewhere) 
== other_thing_that_is_meaningful, "Description of what the issue is if this 
fails for humans, as if the names weren't enough"

and making that fit within whatever line length limit your codebase has.

put () in the wrong place and it triggers the long standing Python wart or 
parsing as a tuple.

rather than warn about the syntax wart, we should just do the thing code 
authors want in the first place.

--

___
Python tracker 

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

[issue46117] tk could not refresh auto in mac os

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The script seems to work fine for me, python 3.10.1 on macOS 12.1. I used the 
python.org installer.

Did you install Python from source or using the installer? What's the output of 
``python3 -m test.pythoninfo``, in particular the lines related to Tcl/Tk at 
the end?

For example:

...
time.tzname: ('CET', 'CEST')
tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.12
zlib.ZLIB_RUNTIME_VERSION: 1.2.11
...

--

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I can try to prototype something in the parser to see how it looks and work on 
the pep if everything looks ok.

Parentheses are a bit tricky in general as backtracking ends causing all sorts 
of tricky situations with custom syntax errors as the parser needs to 
distinguish between function calls, tuple construction and grouping so that's 
the only dangerous situation I can think of

--
nosy:  -gvanrossum, serhiy.storchaka

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It does not need any change in parser, it can be done in the code generator 
which currently explicitly warns about such ambiguity.

Although it needs changes in formal grammar which will be more complex.

But what is a benefit? What is an advantage of writing

   assert (thing, description)

instead of

   assert thing, description

?

--
nosy: +gvanrossum, serhiy.storchaka

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Sergei Lebedev]

Change by Sergei Lebedev :


--
nosy: +slebedev

___
Python tracker 

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

[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

[Gregory P. Smith]

New submission from Gregory P. Smith :

Now that we have a shiny new parser, can we finally get rid of this language 
wart:

assert thing, description  # works as intended

assert (thing, description)  # always True as non-empty tuples are Truthy

This most often happens when extending thing or description beyond a single 
line on assert statements as () are the natural way to do that and as it is 
with assert being a statement, knowing specifically where to place the ()s to 
not fall into the pit of snakes of unintentionally nerfing your assertion to be 
an always true tuple is hard for human authors.

This would obsolete the pylint error about tuple assertion and enable more 
natural assert use.

py.test framework users would presumably rejoice as well.


This parsing change would need a PEP.  I fail to see any obvious downsides 
though.

--
components: Parser
messages: 409101
nosy: gregory.p.smith, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parse assert (x == y, "Descriptive text") as statement params instead of 
a tuple
versions: Python 3.11

___
Python tracker 

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

[issue46166] Get "self" args or non-null co_varnames from frame object with C-API

[Henry Schreiner]

Change by Henry Schreiner :


--
nosy: +Henry Schreiner

___
Python tracker 

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

[issue46166] Get "self" args or non-null co_varnames from frame object with C-API

[Aaron Gokaslan]

New submission from Aaron Gokaslan :

Hello, I am a maintainer with the PyBind11 project. We have been following the 
3.11 development branch and have noticed an issue we are encountering with 
changes to the C-API. 

Particularly, we have an edge case in our overloading dispatch mechanism that 
we used to solve by inspecting the "self" argument in the co_varnames member of 
the python frame object: 
(https://github.com/pybind/pybind11/blob/a224d0cca5f1752acfcdad8e37369e4cda42259e/include/pybind11/pybind11.h#L2380).
 However, in the new struct, the co_varnames object can now be null. There also 
doesn't appear to be any public API to populate it on the C-API side. Accessing 
it via the "inspect" module still works, but that requires us to run a Python 
code snippit in a potentially very hot code path: 
(https://github.com/pybind/pybind11/blob/a224d0cca5f1752acfcdad8e37369e4cda42259e/include/pybind11/pybind11.h#L2408).

As such, we were hoping that either there is some new API change we have 
missed, or if there is some way other modern (and hopefully somewhat  stable 
way to access the API) so we can emulate the old behavior with the C-API.

--
components: C API
messages: 409100
nosy: Skylion007
priority: normal
severity: normal
status: open
title: Get "self" args or non-null co_varnames from frame object with C-API
type: enhancement
versions: Python 3.11

___
Python tracker 

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

[issue46162] Make `builtins.property` generic

[Guido van Rossum]

Guido van Rossum  added the comment:

Yes, it is too late for 3.10 (but you can add it to typing_extensions). Also, 
PEP 585 is done, we don't update PEPs. Please do test with `from __future__ 
import annotations` -- you never know.

When this was first proposed (https://github.com/python/typing/issues/985) 
there were worries about backwards compatibility. Given how common property is, 
we need to make sure there are no problems with that. Can you address that? I 
don't see it in the original thread.

Also, since this requires type checkers to change, do we need a PEP?

Finally. Please keep discussion in this bpo issue, don't have long discussions 
on the PR. (Honestly I think it's too soon for a PR given that we don't seem to 
have agreement in the typing tracker discussion.)

--

___
Python tracker 

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

[issue46165] pythin is core dumping with SIGILL in pytest of the jupyter-server

[Tomasz Kloczko]

New submission from Tomasz Kloczko :

I;m packaging python modules as rpm packages and just found that package 
jupyter-server (1.13.1) when pytest was executed python crashed with call trace

+ /usr/bin/pytest -ra jupyter_server
=== 
test session starts 

platform linux -- Python 3.8.12, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
rootdir: /home/tkloczko/rpmbuild/BUILD/jupyter_server-1.13.1, configfile: 
pyproject.toml
plugins: cov-3.0.0, console-scripts-1.2.0, mock-3.6.1, tornasync-0.6.0.post2, 
anyio-3.3.4
collected 581 items

jupyter_server/auth/security.py Fatal Python error: Illegal instruction

Current thread 0x7f480bd08740 (most recent call first):
  File "/usr/lib64/python3.8/site-packages/argon2/low_level.py", line 112 in 
hash_secret
  File "/usr/lib64/python3.8/site-packages/argon2/_password_hasher.py", line 
133 in hash
  File 
"/home/tkloczko/rpmbuild/BUILD/jupyter_server-1.13.1/jupyter_server/auth/security.py",
 line 73 in passwd
  File "", line 1 in 
  File "/usr/lib64/python3.8/doctest.py", line 1336 in __run
  File "/usr/lib64/python3.8/doctest.py", line 1483 in run
  File "/usr/lib64/python3.8/doctest.py", line 1844 in run
  File "/usr/lib/python3.8/site-packages/_pytest/doctest.py", line 287 in 
runtest
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 162 in 
pytest_runtest_call
  File "/usr/lib/python3.8/site-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3.8/site-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3.8/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 255 in 

  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 311 in 
from_call
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 254 in 
call_runtest_hook
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 215 in 
call_and_report
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 126 in 
runtestprotocol
  File "/usr/lib/python3.8/site-packages/_pytest/runner.py", line 109 in 
pytest_runtest_protocol
  File "/usr/lib/python3.8/site-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3.8/site-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3.8/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 348 in 
pytest_runtestloop
  File "/usr/lib/python3.8/site-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3.8/site-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3.8/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 323 in _main
  File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 269 in 
wrap_session
  File "/usr/lib/python3.8/site-packages/_pytest/main.py", line 316 in 
pytest_cmdline_main
  File "/usr/lib/python3.8/site-packages/pluggy/_callers.py", line 39 in 
_multicall
  File "/usr/lib/python3.8/site-packages/pluggy/_manager.py", line 80 in 
_hookexec
  File "/usr/lib/python3.8/site-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3.8/site-packages/_pytest/config/__init__.py", line 162 
in main
  File "/usr/lib/python3.8/site-packages/_pytest/config/__init__.py", line 185 
in console_main
  File "/usr/bin/pytest", line 33 in 
/var/tmp/rpm-tmp.WmHwan: line 49: 2150294 Illegal instruction (core dumped) 
PATH="/home/tkloczko/rpmbuild/BUILDROOT/python-jupyter-server-1.13.1-2.fc35.x86_64/usr/bin:$PATH"
 PYTHONDONTWRITEBYTECODE=1 SETUPTOOLS_SCM_PRETEND_VERSION=1.13.1 
PYTHONPATH="${PYTHONPATH:-/home/tkloczko/rpmbuild/BUILDROOT/python-jupyter-server-1.13.1-2.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-jupyter-server-1.13.1-2.fc35.x86_64/usr/lib/python3.8/site-packages}"
 /usr/bin/pytest -ra jupyter_server

I'm using my own Linux distribution (which I';m supporting for may clients) and 
I'm still using python 3.8.12.

Here is list of modules installed in build env
[tkloczko@ss-desktop SPECS]$ pip list
Package   Version
- ---
alabaster 0.7.12
anyio 3.3.4
appdirs   1.4.4
argon2-cffi   21.1.0
attrs 21.2.0
Babel 2.9.1
backcall  0.2.0
bleach4.0.0
build 0.7.0
cffi  1.15.0
chardet   4.0.0
charset-normalizer2.0.9
coverage  6.2
cycler0.11.0
dbus-python   1.2.18
decorator 5.1.0
defusedxml

[issue46160] IPy->IPSet AttributeError: module 'collections' has no attribute 'MutableSet'

[dafu-wu]

dafu-wu  added the comment:

Many thanks，You help me to solve the problem！

--

___
Python tracker 

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

[issue46164] New `both()` operator for matching multiple variables to one

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Just use

if a == b == 1:

Comparisons can be chained arbitrarily.

https://docs.python.org/3/reference/expressions.html#comparisons

--
nosy: +steven.daprano
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue37295] Possible optimizations for math.comb()

[Mark Dickinson]

Mark Dickinson  added the comment:

Raymond: how do you want to proceed on this? Should I code up my suggestion in 
a PR, or are you already working on it?

--

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[Christian Heimes]

Christian Heimes  added the comment:

You are using a OpenSSL build with custom, additional patches and your code is 
crashing somewhere in OpenSSL. It is likely that your patches are causing 
issue. I'm not going to provide free service for custom builds.

--
assignee: christian.heimes -> 
nosy: +christian.heimes
resolution:  -> third party
status: open -> closed

___
Python tracker 

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

[issue46153] function fails in exec when locals is given

[Eryk Sun]

Eryk Sun  added the comment:

> You seem to be arguing that a description in the docs is "misleading", 
> not because it misleads, but because it don't describe a situation 
> which has nothing to do with the situation that the docs are describing.

To me it's misleading to say "the code will be executed as if it were embedded 
in a class definition" because that is not always the case. The example with 
print(a) shows that. One can take it another level to compare function 
definitions in a class definition compared to exec(). A function defined in an 
exec() is not compiled to bind its free variables to the outer lexical scope in 
the context of the exec() call, while a function defined in a class definition 
does. For example:

class:

def f():
   a = 2
   class C:
   def g(): print(a)
   return C.g

>>> a = 1
>>> g = f()
>>> g()
2

exec():

def f():
   a = 2
   l = {}
   exec('def g(): print(a)', globals(), l)
   return l['g']

>>> a = 1
>>> g = f()
>>> g()
1

You asked what I would say in its place, but I don't have a simple answer that 
can take the place of the one-liner in the docs. Here's something, but I'm sure 
you won't be happy with it:

The code will be executed in a manner that's similar to a class definition with 
regard to the use of separate locals and globals scopes. However, there can be 
significant differences in certain contexts with regard to how the same code is 
compiled for an exec() call compared to a class definition. In particular, code 
in a class definition is compiled to bind its free variables to the lexical 
scopes of outer function calls in the defining context, which isn't possible 
with exec(). Also, the top-level code in a class definition supports `nonlocal` 
declarations, which is a syntax error with exec().

--

___
Python tracker 

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

[issue46055] Speed up binary shifting operators

[Mark Dickinson]

Change by Mark Dickinson :


--
keywords: +patch
pull_requests: +28464
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30243

___
Python tracker 

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

[issue46164] New `both()` operator for matching multiple variables to one

[Eric V. Smith]

Eric V. Smith  added the comment:

I think this is a rarely needed operation. I looked through a few tens of 
thousand lines of my code and couldn't find anywhere it would be used.

Plus, you could write it yourself, so I don't see the advantage of it being 
part of the language or standard library.

--
nosy: +eric.smith

___
Python tracker 

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

[issue46164] New `both()` operator for matching multiple variables to one

[Billy]

New submission from Billy :

A new `both()` operator for matching multiple variables to one at the same time.

Currently,
```py
if a == 1 and b == 1:
...
```

With a `both()` operator, it can be done as follows (concept):
```py
if both(a, b) == 1:
...
```

Why? 
-> With the increasing number of variables, it may be hard to compare each of 
them at once, hence this operator can help a lot in such situations. 
Of course, using lists appropriately can solve this issue easily, but a 
general-direct method for achieving this would be a lot helpful. This also 
makes the code more simplistic and easily readable and understandable.



*Sorry for the bad formatting if markdown is not supported for this comment 
section, I couldn't find it mentioned anywhere in the python developer's guide. 
Hence I'm assuming it is supported since it's a common and highly needed 
feature nowadays.

--
messages: 409091
nosy: billyeatcookies
priority: normal
severity: normal
status: open
title: New `both()` operator for matching multiple variables to one
type: enhancement

___
Python tracker 

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

[issue46055] Speed up binary shifting operators

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue46153] function fails in exec when locals is given

[Quentin Peter]

Quentin Peter  added the comment:

Maybe a note could be added to 
https://docs.python.org/3/library/functions.html#exec

Something along the lines of:

Note: If exec gets two separate objects as `globals` and `locals`, the code 
will not be executed as if it were embedded in a function definition. For 
example, any function or comprehension defined at the top level will not have 
access to the `locals` scope.

PS: It would be nice for my usecase to have a way around this, maybe a flag in 
`compile` or `exec` that would produce "function code" instead of "module 
code". My workaround for this problem consist in wrapping my code in a function 
definition.

I think this means https://bugs.python.org/issue41918 should be closed as well?

--

___
Python tracker 

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

[issue46153] function fails in exec when locals is given

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Thu, Dec 23, 2021 at 05:47:33AM +, Eryk Sun wrote:
> 
> Eryk Sun  added the comment:
> 
> > That's taken straight out of the documentation.
> 
> Yes, but it's still a misleading comparison.

I asked how you would re-word the docs, but you haven't responded.

The description given in the docs exactly explains the observed 
behaviour. Without recognising that, the observed behaviour is 
perplexing to the point that it suggested to at least one person that it 
was a bug in the language.

If you're not prepared to suggest an improvement to the documentation, 
then I don't think that this conversation is going anywhere and maybe 
we should just let the discussion die.

But for the record, in case you, or anyone else, does want to continue 
the discussion in the hope of reaching additional insight to the 
problem, my further comments are below.

[...]
> Saying that code will be "executed as if it were embedded in a class 
> definition" is correct only so far as the fact that globals and locals 
> are different in this case. 

So it's correct in all the ways that matter:

- different globals and locals;
- and the behaviour is different.

and incorrect in no ways at all (see below). I don't think that supports 
a charge of "misleading".

The bottom line here is that the description in the docs that you call 
"misleading" did not mislead me, but lead me directly to the solution of 
why the code behaved as it did, and why that was the intentional 
behaviour rather than a bug.

So un-misleading, if you will.

> But it's also misleading because the code 
> gets compiled as module-level code, not as class code.

Obviously there is no actual "class code" involved. That is why the 
description says that it is executed *as if* it were embedded inside a 
class statement, rather than by having an actual class statement added 
to your source string.

I don't understand your comment about "compiled as module-level ... not 
as class code". What's class code? (Aside from the actual class 
statement itself, which is a red herring.)

If you look at the disassembly of the following two snippets:

dis.dis("""
a = 1
def f():
return a
print(f())
""")

and 

dis.dis("""
class C:
a = 1
def f():
return a
print(f())
""")

the generated bytecode for the lines `a = 1` etc is the same, putting 
aside the code for the actual class statement part. You get the same 
code for `a = 1`

LOAD_CONST(1)
STORE_NAME(a)

the same code for both the body of the function:

LOAD_GLOBAL   (a)
RETURN_VALUE

and the `def f()` statement:

LOAD_CONST()
LOAD_CONST('f')
MAKE_FUNCTION
STORE_NAME

and the same code for the call to print:

 LOAD_NAME(print)
 LOAD_NAME(f)
 CALL_FUNCTION
 CALL_FUNCTION
 POP_TOP
 LOAD_CONST   (None)
 RETURN_VALUE

Obviously the offsets and locations of constants will be different, but 
aside from those incidental details, the code generated for the block is 
the same whether it is inside a class statement or not.

So I don't understand what you consider to be the difference between 
code compiled at module-level and code compiled at class-level. They 
seem to me to be identical (aside from the incidentals).

The visible difference in behaviour relates to the *execution* of the 
code, not to whether (quote):

"the code gets compiled as module-level code [or] as class code".

There is no distinct "class code". The difference in behaviour is in the 
execution, not to the compilation.

> It should be pretty obvious why the following fails:
> 
> exec("a = 1\ndef f(): return a\nprint(f())", {}, {})

Yes, it is obvious why it fails, in the same sense as the maths joke 
about the professor who stares at the equations on the blackboard for 
twenty minutes before exclaiming "Yes, it is obvious!".

It takes a sophisticated understanding of Python's scoping rules to 
understand why that fails when the other cases succeed.

> Assignment is local by default, unless otherwise declared. Function 
> f() has no access to the local scope where `a` is defined

With the same dict used for globals and locals, execution runs the 
statements `a = 1`, the `def f` and the print in the same scope, which 
is *both* global and local. This is what happens when you run code at 
the module level: locals is globals.

Consequently, the statement `a = 1` assigns a to the local namespace, 
which is the global namespace. And the call to f() retrieves a from the 
global namespace, which is the local namespace.

This is what happens when you execute the code at module-level.

With different dicts, the three statements still run in the same scope, 
the local scope, but the call to f() attempts to retrieve a from the 
global namespace, which is distinct from local namespace.

[issue46163] multiprocessing logger deadlocks if used with logging.handlers.QueueHandler

[dmitry-bychkov]

New submission from dmitry-bychkov :

Hello!
If you use multiprocessing logger with logging.handlers.QueueHandler it will 
deadlock on first attempt at logging.

First attempt will initialize queue's background thread, which uses 
multiprocessing logger itself which will result in something what looks like 
deadlock :) 

There are workarounds and I'm not sure if it can be classified as a bug, 
prehaps a little note in documentation about this behaviour will do? 

I've attached example script.

--
files: logger_deadlock.py
messages: 409088
nosy: iamdbychkov
priority: normal
severity: normal
status: open
title: multiprocessing logger deadlocks if used with 
logging.handlers.QueueHandler
versions: Python 3.9
Added file: https://bugs.python.org/file50513/logger_deadlock.py

___
Python tracker 

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

[issue43424] Document the `controller.name` field in `webbrowser` module

[Alex Waygood]

Change by Alex Waygood :


--
type: security -> enhancement
versions: +Python 3.11 -Python 3.10

___
Python tracker 

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

[issue43424] Document the `controller.name` field in `webbrowser` module

[Nikita Sobolev]

Change by Nikita Sobolev :


--
pull_requests: +28463
pull_request: https://github.com/python/cpython/pull/30241

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

Change by tongxiaoge :


--
nosy:  -christian.heimes, sxt1001, thatiparthy, vstinner
Added file: https://bugs.python.org/file50512/python3.spec

___
Python tracker 

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

[issue43424] Document the `controller.name` field in `webbrowser` module

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Hm, looks like `.name` does not exist for `MacOSXOSAScript`:

```
Python 3.11.0a3+ (heads/main-dirty:71ef0b4c2b, Dec 23 2021, 12:38:09) [Clang 
11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> webbrowser.get()

>>> a = webbrowser.get()
>>> dir(a)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', 
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__', '_name', 'args', 'open', 
'open_new', 'open_new_tab']
>>> a.name
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'MacOSXOSAScript' object has no attribute 'name'. Did you mean: 
'_name'?
```

This happens because `MacOSXOSAScript` does not call `super().__init__()` in 
any way, nor it defines `name` and `basename` attributes.

It has this API for 12 years now: 
https://github.com/python/cpython/commit/4d39f6e09a5c0a0e09eb51d678bacd1adaa3f2ca

So, I see two possible ways to solve this:
1. Ensure all subtypes of `BaseBrowser` to have `name` and `basename` (because 
they are defined in `BaseBrowser`) and document them
2. Add a code comment that they are just implementation details and not a part 
of the public API

--
nosy: +sobolevn

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

tongxiaoge  added the comment:

I want to know whether this is an OpenSSL problem or a python 3 problem, and 
how to fix it? Thanks.
(The OpenSSL source package is large and has not been uploaded successfully. We 
can download it from the OpenSSL official website)

--
status: closed -> open

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

Change by tongxiaoge :


Added file: https://bugs.python.org/file50511/openssl-1.1.1-build.patch

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

Change by tongxiaoge :


--
keywords: +patch
Added file: https://bugs.python.org/file50510/openssl-1.1.1-fips.patch

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

Change by tongxiaoge :


Added file: https://bugs.python.org/file50509/openssl.spec

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

Change by tongxiaoge :


Added file: https://bugs.python.org/file50508/Makefile.certificate

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

tongxiaoge  added the comment:

Other information:
```
(gdb) f 2
#2  SSL_CTX_new (meth=0xe222cc30) at ssl/ssl_lib.c:3046
warning: Source file is more recent than executable.
3046ret->session_timeout = meth->get_timeout();
(gdb) l
3041ret->max_proto_version = 0;
3042ret->mode = SSL_MODE_AUTO_RETRY;
3043ret->session_cache_mode = SSL_SESS_CACHE_SERVER;
3044ret->session_cache_size = SSL_SESSION_CACHE_MAX_SIZE_DEFAULT;
3045/* We take the system default. */
3046ret->session_timeout = meth->get_timeout();
3047ret->references = 1;
3048ret->lock = CRYPTO_THREAD_lock_new();
3049if (ret->lock == NULL) {
3050SSLerr(SSL_F_SSL_CTX_NEW, ERR_R_MALLOC_FAILURE);
```

--

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

tongxiaoge  added the comment:

Today, I upgraded my version of Python3 to 3.9.9. When running test_ ssl,It has 
a segment error again. The version of OpenSSL I use is 1.1.1l, here is part of 
the stack information (the complete one is too long):

```
(gdb) bt
#0  0x9e563830 in raise () from /lib64/libpthread.so.0
#1  
#2  SSL_CTX_new (meth=0x9076cc30) at ssl/ssl_lib.c:3046
#3  0x90799f38 in _ssl__SSLContext_impl () from 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/build/debug/build/lib.linux-aarch64-3.9-pydebug/_ssl.cpython-39d-aarch64-linux-gnu.so
#4  0x9079a3ac in _ssl__SSLContext () from 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/build/debug/build/lib.linux-aarch64-3.9-pydebug/_ssl.cpython-39d-aarch64-linux-gnu.so
#5  0x9e76d034 in tp_new_wrapper (self=0x907c0510 
, args=0x8ff4db90, kwds=0x0) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/typeobject.c:6247
#6  0x9e748ae8 in cfunction_call (func=0x907d60b0, args=, kwargs=) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/methodobject.c:543
#7  0x9e6f18a8 in _PyObject_MakeTpCall 
(tstate=tstate@entry=0xaaadd8db33b0, callable=callable@entry=0x907d60b0, 
args=args@entry=0x8fcb45b0, nargs=nargs@entry=2, 
keywords=keywords@entry=0x0)
at /home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/call.c:191
#8  0x9e670fd8 in _PyObject_VectorcallTstate (kwnames=, 
nargsf=, args=, callable=, 
tstate=)
at /home/abuild/rpmbuild/BUILD/Python-3.9.9/Include/cpython/abstract.h:116
#9  PyObject_Vectorcall (kwnames=, nargsf=, 
args=, callable=) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Include/cpython/abstract.h:127
#10 call_function (tstate=0xaaadd8db33b0, pp_stack=0xc5ebf240, 
oparg=, kwnames=0x0) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Python/ceval.c:5075
#11 0x9e67a7e8 in _PyEval_EvalFrameDefault (tstate=, 
f=, throwflag=) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Python/ceval.c:3487
#12 0x9e80c52c in _PyEval_EvalFrame (throwflag=0, f=0x8fcb4410, 
tstate=0x903e2050) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Include/internal/pycore_ceval.h:40
#13 _PyEval_EvalCode (tstate=0x903e2050, _co=0x908b3110, 
globals=, locals=locals@entry=0x0, args=, 
argcount=281473096927744, kwnames=0xaaadd8db33b0,
kwargs=0xc5ebf4a0, kwcount=281473343352832, kwstep=kwstep@entry=1, 
defs=0x903dd798, defcount=, kwdefs=0x0, closure=, name=, qualname=)
at /home/abuild/rpmbuild/BUILD/Python-3.9.9/Python/ceval.c:4327
#14 0x9e6f13f0 in _PyFunction_Vectorcall (func=, 
stack=, nargsf=, kwnames=) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/call.c:396
#15 0x9e6f1c5c in _PyObject_FastCallDictTstate 
(tstate=tstate@entry=0xaaadd8db33b0, callable=callable@entry=0x903e2050, 
args=args@entry=0xc5ebf4a0, nargsf=nargsf@entry=2,
kwargs=kwargs@entry=0x0) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/call.c:118
#16 0x9e6f2004 in _PyObject_Call_Prepend 
(tstate=tstate@entry=0xaaadd8db33b0, callable=callable@entry=0x903e2050, 
obj=obj@entry=0xaaadd8f8fe00, args=args@entry=0x8ff4ca00,
kwargs=kwargs@entry=0x0) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/call.c:489
#17 0x9e769960 in slot_tp_new (type=0xaaadd8f8fe00, 
args=0x8ff4ca00, kwds=0x0) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/typeobject.c:6994
#18 0x9e76d438 in type_call (type=0xaaadd8f8fe00, args=0x8ff4ca00, 
kwds=0x0) at /home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/typeobject.c:1014
#19 0x9e6f18a8 in _PyObject_MakeTpCall 
(tstate=tstate@entry=0xaaadd8db33b0, callable=callable@entry=0xaaadd8f8fe00, 
args=args@entry=0x8fcf7f08, nargs=nargs@entry=1, 
keywords=keywords@entry=0x0)
at /home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/call.c:191
#20 0x9e670fd8 in _PyObject_VectorcallTstate (kwnames=, 
nargsf=, args=, callable=, 
tstate=)
at /home/abuild/rpmbuild/BUILD/Python-3.9.9/Include/cpython/abstract.h:116
#21 PyObject_Vectorcall (kwnames=, nargsf=, 
args=, callable=) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Include/cpython/abstract.h:127
#22 call_function (tstate=0xaaadd8db33b0, pp_stack=0xc5ebf730, 
oparg=, kwnames=0x0) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Python/ceval.c:5075
#23 0x9e67a7e8 in _PyEval_EvalFrameDefault (tstate=, 
f=, throwflag=) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Python/ceval.c:3487
#24 0x9e66f024 in _PyEval_EvalFrame (throwflag=0, f=0x8fcf7d70, 
tstate=0xaaadd8db33b0) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Include/internal/pycore_ceval.h:40
#25 function_code_fastcall (tstate=0xaaadd8db33b0, co=, 
args=, nargs=1, globals=) at 
/home/abuild/rpmbuild/BUILD/Python-3.9.9/Objects/call.c:330
#26 0x9e6f55f0 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=1, 
args=0x8fcc6f48, callable=, tstate=)
at /home/abuild/rpmbuild/BUILD/Python-3.9.9/Include/cpython/abstract.h:118
#27 

[issue46150] test_pathlib assumes "fakeuser" does not exist as user

[Nikita Sobolev]

Change by Nikita Sobolev :


--
keywords: +patch
nosy: +sobolevn
nosy_count: 1.0 -> 2.0
pull_requests: +28462
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30240

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Kumar Aditya]

Kumar Aditya  added the comment:

Fixed in a new PR @Serhiy

--

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Kumar Aditya]

Change by Kumar Aditya :


--
pull_requests: +28461
pull_request: https://github.com/python/cpython/pull/30239

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 30237 introduced few new errors.

--

___
Python tracker 

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

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

Change by Nikita Sobolev :


--
keywords: +patch
pull_requests: +28460
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30238

___
Python tracker 

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

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

Nikita Sobolev  added the comment:

One more question about PEP585: it does not specify `property`. Do we need to 
update it?

--

___
Python tracker 

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

[issue46162] Make `builtins.property` generic

[Nikita Sobolev]

New submission from Nikita Sobolev :

Original discussion in `typing` bug tracker: 
https://github.com/python/typing/issues/985

Short description:
- `property[GetType, SetType]` is required for us to remove a lot of special 
casing from type-checkers and just use the primitive type
- In runtime it copies the same behavior `list` / `dict` / other primitive 
types have under PEP585

Open questions:
- I think that it is too late to backport this in 3.10. Am I right?
- I hope that `from __future__ import annotations` will just work for this new 
change. Is there anything I should do in scope of this PR? Is my assumption 
about `__future__` import is even correct in this context? Do I need to test 
that it works with `__future__ annotations`?

--
components: Library (Lib)
messages: 409080
nosy: gvanrossum, kj, sobolevn
priority: normal
severity: normal
status: open
title: Make `builtins.property` generic
type: behavior
versions: Python 3.11

___
Python tracker 

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

[issue46161] `class A(1, 2, 3, **d): pass` gives bad bytecode

[Dennis Sweeney]

Dennis Sweeney  added the comment:

I was trying to figure out how code like this could ever *not* raise an 
exception, and here is one case that runs to completion on 3.6--3.8, but it 
raises `TypeError: 'str' object is not callable` on 3.9--3.11.


class I(int):
def __init__(*args, **kwargs): pass
def __new__(*args, **kwargs): pass

d = {'metaclass': I}
class A(1, 2, 3, **d):
pass

--

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 71ef0b4c2b77195bb1adc42602549284f7ee9566 by Kumar Aditya in 
branch 'main':
bpo-46157: fix typo in docs (GH-30237)
https://github.com/python/cpython/commit/71ef0b4c2b77195bb1adc42602549284f7ee9566


--
nosy: +asvetlov

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
versions: +Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

And more errors can be found with:

$ find -name '*.rst' -exec egrep --color -i '\ban +[qwrtpsdfghjklzxcvbnm]' '{}' 
+
$ find -name '*.rst' -exec egrep --color -i '\ba +[eioa]' '{}' +

It is worth to check also:

$ find -name '*.rst' -exec egrep --color -i '\ban +[yu]' '{}' +
$ find -name '*.rst' -exec egrep --color -i '\ba +[yu]' '{}' +

Most of them should be correct, but there may be some new errors.

--

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Kumar Aditya]

Kumar Aditya  added the comment:

I have fixed most of them in the PR which I found correct, rest can be fixed 
later on.

--

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you Kumar.

These errors were found with the following one-liners:

$ find -name '*.rst' -exec egrep --color -i '\ban 
+:[a-z:]+:`[qwrtpsdfghjklzxcvbnm]' '{}' +
$ find -name '*.rst' -exec egrep --color -i '\ba +:[a-z:]+:`[eyuioa]' '{}' +

They produce a lot of false positive results because of signatures and 
different reading of initial "y" and "u" (and "o", but there are no such cases 
here).

--

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Doc/using/cmdline.rst:474:   * ``-X warn_default_encoding`` issues a 
:class:`EncodingWarning` when the
Doc/c-api/init_config.rst:601:  If non-zero, emit a :exc:`EncodingWarning` 
warning when :class:`io.TextIOWrapper`
Doc/library/fractions.rst:90:  and *denominator*. :func:`math.gcd` always 
return a :class:`int` type.
Doc/library/asyncio-future.rst:122:  a :exc:`InvalidStateError` exception.
Doc/library/asyncio-future.rst:128:  Raises a :exc:`InvalidStateError` 
error if the Future is
Doc/library/asyncio-future.rst:135:  Raises a :exc:`InvalidStateError` 
error if the Future is
Doc/library/inspect.rst:402:  wrapped function is a :term:`asynchronous 
generator` function.
Doc/library/importlib.rst:881:   Returns a 
:class:`importlib.abc.Traversable` object for the loaded
Doc/library/importlib.rst:960:Given a 
:class:`importlib.resources.abc.Traversable` object representing
Doc/library/pathlib.rst:721:   Return a :class:`os.stat_result` object 
containing information about this path, like :func:`os.stat`.
Doc/library/os.rst:3412:   Provide semaphore-like semantics for reads from a 
:func:`eventfd` file
Doc/library/asyncio-task.rst:947:  a :exc:`InvalidStateError` exception.
Doc/library/ast.rst:782:   be a :class:`Name`, a :class:`Attribute` or a 
:class:`Subscript`.
Doc/library/ast.rst:1772:   must be wrapped in a :class:`Expr` node if the 
value sent back is not used.
Doc/library/asyncio-eventloop.rst:116:   is implicitly scheduled to run as a 
:class:`asyncio.Task`.
Doc/library/asyncio-eventloop.rst:357:   must return a 
:class:`asyncio.Future`-compatible object.
Doc/library/asyncio-eventloop.rst:1129:   This method returns a 
:class:`asyncio.Future` object.
Doc/glossary.rst:113:  An object created by a :term:`asynchronous 
generator` function.
Doc/reference/expressions.rst:216:clause may be used to iterate over a 
:term:`asynchronous iterator`.
Doc/reference/expressions.rst:710:   This method is normally called implicitly 
by a :keyword:`async for` loop.
Doc/whatsnew/3.7.rst:607:a :class:`importlib.abc.ResourceReader` instance to 
support this
Misc/NEWS.d/3.10.0a1.rst:825:``True``, ``False`` and ``None`` are used within a 
:class:`ast.Name` node.
Misc/NEWS.d/3.9.0a4.rst:407:always return a :class:`int` type. Previously, the 
GCD type depended on
Misc/NEWS.d/3.9.0b1.rst:394:When a :class:`asyncio.Task` is cancelled, the 
exception traceback now

--

___
Python tracker 

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

[issue46161] `class A(1, 2, 3, **d): pass` gives bad bytecode

[Dennis Sweeney]

Dennis Sweeney  added the comment:

Bisected to here:


13bc13960cc83dbd1cb5701d9a59ac9b9144b205 is the first bad commit
commit 13bc13960cc83dbd1cb5701d9a59ac9b9144b205
Author: Mark Shannon 
Date:   Thu Jan 23 09:25:17 2020 +

bpo-39320: Handle unpacking of *values in compiler (GH-17984)

* Add three new bytecodes: LIST_TO_TUPLE, LIST_EXTEND, SET_UPDATE. Use them 
to implement star unpacking expressions.

* Remove four bytecodes BUILD_LIST_UNPACK, BUILD_TUPLE_UNPACK, 
BUILD_SET_UNPACK and  BUILD_TUPLE_UNPACK_WITH_CALL opcodes as they are now 
unused.

* Update magic number and dis.rst for new bytecodes.



In debug mode, the following code gives fails a C-level assertion:

d = {'metaclass': type}
for _ in [1]:
class A(1, 2, 3, **d):
pass

Assertion failed: b->b_startdepth < 0 || b->b_startdepth == depth, file 
compile.c, line 6959

--
nosy: +Dennis Sweeney, Mark.Shannon
title: Incorrect bytecpde compilation for class -> `class A(1, 2, 3, **d): 
pass` gives bad bytecode
type: compile error -> crash
versions: +Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Kumar Aditya]

Kumar Aditya  added the comment:

I'll fix them all :)

--

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There are other similar errors:

Doc/library/json.rst:162:   will result in an :exc:`RecursionError` (or worse).
Doc/library/json.rst:435:   prevent an infinite recursion (which would cause an 
:exc:`RecursionError`).
Doc/library/tarfile.rst:66:   |  | Raise an 
:exc:`FileExistsError` exception   |
Doc/library/tarfile.rst:70:   |  | Raise an 
:exc:`FileExistsError` exception   |
Doc/library/tarfile.rst:74:   |  | Raise an 
:exc:`FileExistsError` exception   |
Doc/library/tarfile.rst:78:   |  | Raise an 
:exc:`FileExistsError` exception   |
Doc/library/poplib.rst:124:An :class:`POP3` instance has the following methods:
Doc/library/urllib.request.rst:1112:   implementation will raise an 
:exc:`ValueError` in that case.
Doc/library/enum.rst:180:  Returns the Enum member in *cls* matching 
*name*, or raises an :exc:`KeyError`::
Doc/library/os.rst:2084:   If *exist_ok* is ``False`` (the default), an 
:exc:`FileExistsError` is
Doc/library/os.rst:2360:   not empty, an :exc:`FileNotFoundError` or an 
:exc:`OSError` is raised
Doc/library/asyncio-eventloop.rst:900:  method, before Python 3.7 it 
returned an :class:`Future`.
Doc/library/asyncio-eventloop.rst:1085:   The *executor* argument should be an 
:class:`concurrent.futures.Executor`
Doc/whatsnew/3.9.rst:700::pep:`593` introduced an :data:`typing.Annotated` type 
to decorate existing

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue26897] [doc] Clarify Popen stdin, stdout, stderr

[Kumar Aditya]

Change by Kumar Aditya :


--
keywords: +patch
nosy: +kumaraditya303
nosy_count: 3.0 -> 4.0
pull_requests: +28459
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30231

___
Python tracker 

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

[issue46160] IPy->IPSet AttributeError: module 'collections' has no attribute 'MutableSet'

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue46157] Typo in JSON documentation

[Kumar Aditya]

Change by Kumar Aditya :


--
keywords: +patch
nosy: +kumaraditya303
nosy_count: 2.0 -> 3.0
pull_requests: +28458
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30237

___
Python tracker 

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

[issue46160] IPy->IPSet AttributeError: module 'collections' has no attribute 'MutableSet'

[Kumar Aditya]

Kumar Aditya  added the comment:

In Python 3.10 these deprecated aliases where removed from collections module.
To fix it you can change `collections.MutableSet` to 
`collections.abc.MutableSet`.

See 
https://docs.python.org/3/whatsnew/3.9.html#you-should-check-for-deprecationwarning-in-your-code

--
nosy: +kumaraditya303

___
Python tracker 

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

[issue46130] Untranslatable link text in whatsnew/3.10

[Rafael Fontenelle]

Change by Rafael Fontenelle :


--
pull_requests: +28457
pull_request: https://github.com/python/cpython/pull/30236

___
Python tracker 

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