[issue46813] Allow developer to resize the dictionary

[Raymond Hettinger]

Raymond Hettinger  added the comment:

This idea surfaced once before and Guido shot it down.  IIRC the rationale was 
the exposed implementation details, that would challenging for users to 
consistently set the size correctly, and that it may not make sense for other 
implementations.

This was a good while ago so it may be worth scanning the tracker or python-dev 
archives to find where he opined.

--
nosy: +rhettinger

___
Python tracker 

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

[issue46813] Allow developer to resize the dictionary

[penguin_wwy]

Change by penguin_wwy <940375...@qq.com>:


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

___
Python tracker 

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

[issue46813] Allow developer to resize the dictionary

[penguin_wwy]

New submission from penguin_wwy <940375...@qq.com>:

https://github.com/faster-cpython/ideas/discussions/288

--
components: Interpreter Core
messages: 413634
nosy: penguin_wwy
priority: normal
severity: normal
status: open
title: Allow developer to resize the dictionary
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

[issue31327] [doc] Add example of platform-specific support for negative timestamps to the time doc

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 8.0 -> 9.0
pull_requests: +29589
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31460

___
Python tracker 

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

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

[neonene]

Change by neonene :


--
pull_requests: +29588
pull_request: https://github.com/python/cpython/pull/31459

___
Python tracker 

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

[issue32514] 0x80070002 - The system cannot find the file specified

[John]

Change by John :


Removed file: https://bugs.python.org/file47370/Python 3.6.4 
(32-bit)_20180107153053[3191].log

___
Python tracker 

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

[issue32514] 0x80070002 - The system cannot find the file specified

[John]

Change by John :


Removed file: https://bugs.python.org/file47373/Python 3.6.4 
(32-bit)_20180107153053_000_core_JustForMe[3206].log

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Guido van Rossum]

Guido van Rossum  added the comment:

PS. The cancel count can work whether or not cancel() returns without setting 
must-cancel (or cancelling the underlying future/task) when there's already a 
cancellation in progress. Other things may be different though. We have to look 
into this separately.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Guido van Rossum]

Guido van Rossum  added the comment:

[Sam]
> It will probably work in this case. But, what about more complex cases? If 
> there are 2 different timeouts and the possibility of a user cancellation, 
> and we have a count of 2 cancellations, then what happened? 2 timeouts, or 1 
> timeout and user cancellation? Without being able to check the nonces of each 
> cancellation, I don't see how this would work. Or if the user calls .cancel() 
> twice explicitly, then you cancel both timeouts, even though it had nothing 
> to do with the timeout.

The cancel scope must record whether it called cancel() or not. (This is what 
TaskGroup does.) Suppose the inner timeout cancels and sees two cancellations. 
It knows one of those is its own, so it calls uncancel() and raises 
CancelledError. Now the outer cancel scope sees one cancellation. If it did not 
call cancel(), it knows it was a user cancellation (or another, even more 
outer, cancel scope -- it really doesn't matter), and it raises CancelledError. 
If the outer cancel scope also called cancel(), it knows that this is so, and 
it in turn calls uncancel() -- and it knows (by the count returned from 
uncancel()) that there are no more cancellations, so it raises TimeoutError.

QED

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Guido van Rossum]

Guido van Rossum  added the comment:

[Alex]
> The current backward incompatible changes in cancellation behavior are 
> already causing 10 tests to fail in the AnyIO test suite. I'm trying to find 
> an alternate solution that does not break anything.

Are you sure that the tests aren't over-specified? Maybe you could link to the 
failing test run? (Though I worry that understanding your test infrastructure 
might be a bit much.)

That said, when I landed this change I wasn't at all sure that it wouldn't 
break things (there just weren't any asyncio tests that it broke), and I am 
totally willing to roll that part back or change it if it breaks a valid use 
case.

So basically I am saying please chill, feature freeze isn't until late May.

--

___
Python tracker 

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

[issue46812] Thread starvation with threading.Condition

[Tim Peters]

Tim Peters  added the comment:

Unassigning myself - I have no insight into this.

I suspect the eternally contentious issue 7946 is related.

--

___
Python tracker 

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

[issue46812] Thread starvation with threading.Condition

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +tim.peters

___
Python tracker 

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

[issue46812] Thread starvation with threading.Condition

[Mark Gordon]

New submission from Mark Gordon :

When using Condition variables to manage access to shared resources you can run 
into starvation issues due to the thread that just gave up a resource (making a 
call to notify/notify_all) having priority on immediately reacquiring that 
resource before any of the waiting threads get a chance. The issue appears to 
arise because unlike the Lock implementation Condition variables are 
implemented partly in Python and a thread must hold the GIL when it reacquires 
its underlying condition variable lock.

Coupled with Python's predictable switch interval this means that if a thread 
notifies others of a resource being available and then shortly after attempts 
to reacquire that resource it will be able to do so since it will have held the 
GIL the entire time.

This can lead to some threads being entirely starved (forever) for access to a 
shared resource. This came up in a real world situation for me when I had 
multiple threads trying to access a shared database connection repeatedly 
without blocking between accesses. Some threads were never getting a connection 
leading to unexpected timeouts. See 
https://github.com/sqlalchemy/sqlalchemy/issues/7679


Here's a simple example of this issue using the queue.Queue implementation: 
https://gist.github.com/msg555/36a10bb5a0c0fe8c89c89d8c05d00e21

Similar example just using Condition variables directly: 
https://gist.github.com/msg555/dd491078cf10dbabbe7b1cd142644910

Analagous C++ implementation. On Linux 5.13 this is still not _that_ fair but 
does not completely starve threads: 
https://gist.github.com/msg555/14d8029b910704a42d372004d3afa465

Thoughts:
- Is this something that's worth fixing? The behavior at the very least is 
surprising and I was unable to find discussion or documentation of it.
- Can Condition variables be implemented using standard C libraries? (e.g. 
pthreads) Maybe at least this can happen when using the standard threading.Lock 
as the Condition variables lock?
- I mocked up a fair Condition variable implementation at 
https://github.com/msg555/fairsync/blob/main/fairsync/condition.py. However 
fairness comes at its own overhead of additional context switching.


Tested on Python 3.7-3.10

--
components: Library (Lib)
messages: 413629
nosy: msg555
priority: normal
severity: normal
status: open
title: Thread starvation with threading.Condition
type: behavior
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

[issue46732] Builtin __bool__ docstrings are wrong

[Terry J. Reedy]

Terry J. Reedy  added the comment:

For whatever reason, all builtins with a __bool__ method appear to share the 
same docstring.  For example,

>>> range.__bool__.__doc__
'self != 0'
>>> bool(range(0))
False
>>> bool(range(1))
True

The concrete collection classes have their lengths stored internally so bool 
use that via len(self).  But len(range) != 0 iff stop != start.

--
title: None.__bool__ docstring is wrong -> Builtin __bool__ docstrings are wrong

___
Python tracker 

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

[issue46733] pathlib.Path methods can raise NotImplementedError

[Barney Gale]

Barney Gale  added the comment:

Thanks both. I've adjusted PR 31338 to leave is_mount() unchanged. I've opened 
a new pull request that implements is_mount() on Windows using 
ntpath.ismount(): PR 31458

--

___
Python tracker 

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

[issue46757] dataclasses should define an empty __post_init__

[Raymond Hettinger]

Raymond Hettinger  added the comment:

-1

* I concur with Eric that this is mostly not needed.  Probably 99.95% of 
dataclass use case don't need this.  When it is needed, it is trivial to 
implement and probably should be explicit rather that implicit.

* Vedran is also correct in noting that it would sometimes mask errors.

* There is a runtime cost for all dataclasses that do not use __post_init__.  
Calling an empty method takes time.  We shouldn't make all users pay for a 
feature that almost no one needs.

* With respect to use of super(), it might help a little bit, but only because 
__post_init__() takes no arguments.  For the other methods in cooperative 
multiple inheritance, a user would need to either incorporate a straight 
forward hasattr() check or add a terminal root class as described in 
super-considered-super.  I see no reason to make __post_init__ a special case 
that would differ from other methods (for example, object() doesn't provide an 
empty __call__ or __getitem__).

* Adding a default __post_init__ will create a new problem.  Currently, it is 
possible to easily introspect and determine whether a __post_init__ has been 
provided, but if there is an empty default, it becomes a much more tricky test. 
 We had this problem with functools.total_ordering.  When that tool was first 
created, we could easily use hasattr() to test for a user defined rich 
comparison method.  But after default methods were added to object(), the test 
because much more delicate:  ``getattr(cls, op, None) is not getattr(object, 
op, None)``.  Likewise the Hashable ABC cannot just use hasattr() because 
__hash__() is always present and has to be set to None to turn it off.  A 
default __post_init__ is worse than both cases.  You can't test for it, so you 
just have to call it, not knowing in advance whether it would do anything.

* Anyone supporting multiple versions of Python will still need to write the 
hasattr() check or provide a terminal/root class.  They won't be able to rely 
on the default being present.

I recommend leaving dataclasses as is.

--
nosy: +rhettinger

___
Python tracker 

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

[issue42777] WindowsPath does not implement is_mount but ntpath implements and offers a ismount method

[Barney Gale]

Change by Barney Gale :


--
keywords: +patch
nosy: +barneygale
nosy_count: 1.0 -> 2.0
pull_requests: +29587
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31458

___
Python tracker 

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

[issue36557] [doc] Clarify the meaning of /uninstall in windows cli

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 7.0 -> 8.0
pull_requests: +29586
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31457

___
Python tracker 

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

[issue45492] stdlib inspect documentation on code.co_names is incorrect

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 2.0 -> 3.0
pull_requests: +29585
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31456

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Sam Bull]

Sam Bull  added the comment:

> We could store the nonces in a single CancelledError instead.

Indeed, my initial proposal was exactly that, but after learning about 
ExceptionGroup, I thought that was a cleaner approach.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Alex Grönholm]

Alex Grönholm  added the comment:

> I was under the impression that ExceptionGroup was somewhat backwards 
> compatible, in that you could still use `except CancelledError:` and it would 
> catch all the errors in the group. But, maybe I'm wrong, I've not seen the 
> documentation for the final feature yet, but that's the impression I got from 
> the PEP.

No, you need the new except* syntax for that.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Sam Bull]

Sam Bull  added the comment:

> Previously, when the task was cancelled twice, only one CancelledError was 
> raised. Now it would raise a BaseExceptionGroup instead.

I was under the impression that ExceptionGroup was somewhat backwards 
compatible, in that you could still use `except CancelledError:` and it would 
catch all the errors in the group. But, maybe I'm wrong, I've not seen the 
documentation for the final feature yet, but that's the impression I got from 
the PEP.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Alex Grönholm]

Alex Grönholm  added the comment:

> But, if we are using nonces on the CancelledError to keep track, then only 1 
> context manager will know if it was themselves or not. This is exactly why 
> I'm proposing to use multiple CancelledErrors, so that every nonce is passed 
> to the handling code.

Raising multiple CancelledErrors is not the only way to accomplish this. We 
could store the nonces in a single CancelledError instead.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Sam Bull]

Sam Bull  added the comment:

Actually, in your counter proposal, you say:

> Such context managers should still keep track of whether they cancelled the 
> task themselves or not, and if they did, they should always call t.uncancel().

But, if we are using nonces on the CancelledError to keep track, then only 1 
context manager will know if it was themselves or not. This is exactly why I'm 
proposing to use multiple CancelledErrors, so that every nonce is passed to the 
handling code.

--

___
Python tracker 

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

[issue43853] [sqlite3] Improve sqlite3_value_text() error handling

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:


New changeset ba457fe6f8e50ad3ef3ceffb75dee96629a42ad7 by Erlend Egeberg 
Aasland in branch '3.10':
[3.10] bpo-43853: Expand test suite for SQLite UDF's (GH-27642) (GH-31030)
https://github.com/python/cpython/commit/ba457fe6f8e50ad3ef3ceffb75dee96629a42ad7


--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Alex Grönholm]

Alex Grönholm  added the comment:

> Propagating an ExceptionGroup where every exception can be inspected to see 
> if it was caused by this code or not still seems like the safe option to me 
> (and obviously still has the cancel count implicitly).

Note that this, too, causes backwards incompatible changes in cancellation 
behavior. Previously, when the task was cancelled twice, only one 
CancelledError was raised. Now it would raise a BaseExceptionGroup instead.

The current backward incompatible changes in cancellation behavior are already 
causing 10 tests to fail in the AnyIO test suite. I'm trying to find an 
alternate solution that does not break anything.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Sam Bull]

Sam Bull  added the comment:

> This should be solved when using the cancel count -- the explicit cancel 
> bumps the cancel count so the cancel scope (i.e. timeout()) will not raise 
> TimeoutError.

It will probably work in this case. But, what about more complex cases? If 
there are 2 different timeouts and the possibility of a user cancellation, and 
we have a count of 2 cancellations, then what happened? 2 timeouts, or 1 
timeout and user cancellation? Without being able to check the nonces of each 
cancellation, I don't see how this would work. Or if the user calls .cancel() 
twice explicitly, then you cancel both timeouts, even though it had nothing to 
do with the timeout.

Propagating an ExceptionGroup where every exception can be inspected to see if 
it was caused by this code or not still seems like the safe option to me (and 
obviously still has the cancel count implicitly).

--

___
Python tracker 

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

[issue46805] Add low level UDP socket functions to asyncio

[Alex Grönholm]

Alex Grönholm  added the comment:

Yeah, my question was specific about the new functions, so I understood that a 
separate PR should add that to the all the relevant functions.

I have a different problem now however: the test suite is failing in CI but not 
locally. It's giving me NameError about a function used by existing tests but 
for some reason, it's not defined in the scope of the new test functions?!?

The proactor version of sock_recvfrom_into() is giving me quite a bit of 
trouble, as it seems to require heavy handed changes in _overlapped.c. 

I'm also not very successful in testing cases where sendto() would fill the 
kernel buffer and raise BlockingIOError. With TCP this is easy but with UDP 
near impossible to do in a controlled fashion in the test suite.

--

___
Python tracker 

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

[issue46805] Add low level UDP socket functions to asyncio

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Sorry, I was not clear maybe.
Newly added methods can have a `flag` argument from the very beginning.
Adding a flag to already existing methods requires a separate issue.

--

___
Python tracker 

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

[issue46808] remove NEXT_BLOCK() from compile.c

[Irit Katriel]

Irit Katriel  added the comment:

The patch in PR31448 delays the creation of an implicit block to when it is 
needed (do if we begin using another block before a new instruction is added, 
the implicit block is never created). 

I counted how many empty blocks are being detected by the optimizer during 
"python -m test" and this number went down from 41798 (for main) to 35405 (for 
my PR), which shows that it is not only a theoretical possibility but actually 
happens. It would be things like:

NEXT_BLOCK()
VISIT_SEQ(c, stmt, s->v.Try.orelse);
compiler_use_next_block(c, end);

where the orelse block is empty.


In summary, the patch simplifies the code as well as making it more efficient.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Tin Tvrtković]

Change by Tin Tvrtković :


--
pull_requests: +29584
pull_request: https://github.com/python/cpython/pull/31434

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Tin Tvrtković]

Tin Tvrtković  added the comment:

@Alex you can follow along here: https://github.com/python/cpython/pull/31394

With the cancel_counter approach, a context manager knows whether to handle or 
propagate the exception by examining its own local state and the remaining 
counter on the task. If after uncancelling the counter is still non-zero, it 
propagates.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Andrew Svetlov]

Andrew Svetlov  added the comment:

> This should be solved when using the cancel count -- the explicit cancel 
> bumps the cancel count so the cancel scope (i.e. timeout()) will not raise 
> TimeoutError.

Hmmm. Interesting!

Timeouts are not the single primitive that should care about the cancellation 
source.

Suppose, async code reconnects on network problem but should be terminated on 
explicit task cancelling.
Could cancel count be used here? Is the approach generic enough? My first 
answer is "why not?"

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Alex Grönholm]

Alex Grönholm  added the comment:

> It looks more complicated -- the extra parameter needs to be passed around 
> via the task and then into the CancelledError exception.

It reduces overall complexity by making uncancellation unnecessary and 
restoring backwards compatibility.

> What use case do you have that cannot be solved by some variation of the 
> "cancel count" proposal?

I'm not sure I'm keeping proper track of the variations, but it seems it still 
relies on task uncancellation. But worse than that, (correct me if I'm wrong) 
it makes the innermost context manager handle the cancellation, even if it was 
requested by an outer one. If you have 3 nested "cancel scopes" and the task is 
cancelled once, how do you know which one of those context managers should 
handle the cancellation?

I'm not sure my proposal is a fix-all either, in its current form. Sure, it 
fixes the case where a full task cancellation would go unnoticed, but if two 
unrelated context managers trigger cancellation at the same time, only the 
first one would actually receive it. Perhaps then we need to raise a 
CancelledError separately for each scope? I'm not sure yet.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Guido van Rossum]

Guido van Rossum  added the comment:

(Sam Bull)
> To expand on this point, I've been looking at solving the race conditions in 
> async-timeout. To see how such a race condition can end up with a task never 
> exiting, take a look at this example: 
> https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523

This should be solved when using the cancel count -- the explicit cancel bumps 
the cancel count so the cancel scope (i.e. timeout()) will not raise 
TimeoutError.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Guido van Rossum]

Guido van Rossum  added the comment:

> Can I also get comments on my proposal for the "scope" parameter? Is there a 
> use case it would not solve?

It looks more complicated -- the extra parameter needs to be passed around via 
the task and then into the CancelledError exception.

What use case do you have that cannot be solved by some variation of the 
"cancel count" proposal?

--

___
Python tracker 

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

[issue46805] Add low level UDP socket functions to asyncio

[Alex Grönholm]

Change by Alex Grönholm :


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

___
Python tracker 

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

[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +29582
pull_request: https://github.com/python/cpython/pull/31454

___
Python tracker 

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

[issue46232] Client certificates with UniqueIdentifier in the subject break ssl.peer_certificate()

[Christian Heimes]

Christian Heimes  added the comment:


New changeset be095f6c32188bba02079d086ac8639ea37cec3c by Christian Heimes in 
branch 'main':
bpo-46232: Fix parsing of certs with bit string in DN (GH-30351)
https://github.com/python/cpython/commit/be095f6c32188bba02079d086ac8639ea37cec3c


--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Sam Bull]

Sam Bull  added the comment:

> If the task is already pending a cancellation targeted at a cancel scope, the 
> task itself cannot be cancelled anymore since calling cancel() again on the 
> task is a no-op. This would be solved by updating the cancel message on the 
> second call.

> I think Andrew missed one case: in his second diagram, what if the explicit 
> cancel() happened *after* the timeout (but still in the same iteration)? 
> That's the case that makes me want to delete those two lines from 
> Task.cancel() (see my earlier message).

To expand on this point, I've been looking at solving the race conditions in 
async-timeout. To see how such a race condition can end up with a task never 
exiting, take a look at this example: 
https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523

In the condition Guido describes, the user's cancellation is suppressed and the 
code runs forever.

I also wrote tests that seem to reliably reproduce the race condition (the 2nd 
one still seems unfixable with the current solutions, the 1st was fixed with 
the nonce/sentinel trick): 
https://github.com/aio-libs/async-timeout/commit/ab04eb53dcf49388b6e6eacf0a50bafe19c5c74b#diff-60a009a48129ae41018d588c32a6d94c54d1d2948cbc3b831fc27a9c8fdbac68L364-L421

You can see the flow of execution from the call_order assert at the end.

I think most of the solutions proposed here will still not solve this race 
condition. I initially proposed a solution at: 
https://bugs.python.org/issue45098

In short, I think that every time we call .cancel(), we need to raise another 
CancelledError. So, in this race condition you would get 2 CancelledErrors (via 
an ExceptionGroup). Then our code can catch the error with our nonce/sentinel 
and handle that, but also reraise any other errors which are unrelated.

--
nosy: +dreamsorcerer

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Alex Grönholm]

Alex Grönholm  added the comment:

> Alex, the 'scope' argument can be added if it is really required. 
> I'm not sure if the nonce is unavoidable still.

What other generic solution is there? I've read your last few messages but 
didn't find an answer. There needs to be some way to avoid a whole-task 
cancellation being ignored when it happens after a cancel scope triggers a 
cancellation for itself. My proposal solves that problem, and I think it 
eliminates the need for un-cancellation or other backwards incompatible changes.

--

___
Python tracker 

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

[issue46811] Test suite needs adjustments for Expat >=2.4.5

[sping]

Change by sping :


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

___
Python tracker 

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

[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

[sping]

sping  added the comment:

I have created a dedicated ticket bpo-46811 now, test suite pull request 
upcoming.

--

___
Python tracker 

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

[issue46811] Test suite needs adjustments for Expat >=2.4.5

[sping]

New submission from sping :

It has been reported at https://bugs.python.org/issue46794#msg413587 that the 
current CPython test suite needs some adjustments for Expat >=2.4.5. Since that 
is somewhat separate from updating the bundled copy of Expat to >=2.4.6, I am 
creating this dedicated ticket.  I pull request for discussion will follow 
shortly.

--
components: XML
messages: 413605
nosy: mgorny, sping
priority: normal
severity: normal
status: open
title: Test suite needs adjustments for Expat >=2.4.5
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Alex, the 'scope' argument can be added if it is really required. 
I'm not sure if the nonce is unavoidable still.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Updated https://github.com/python/cpython/pull/31394 demonstrated the approach 
with global dict for counters.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Andrew Svetlov]

Andrew Svetlov  added the comment:

In docs we can explain the behavior as "the outer expired timeout cancels the 
inner waiter, waits for CancelError bubbling up, and raising TimeoutError 
instead".

I agree that a counter is required for this behavior.
An alternative implementation can use the global `dict[Task, int]` for keeping 
counters. It can be either WeakKeyDictionary or a regular dict that deletes 
entries on `task.add_done_callback()` call.  We have a similar structure for 
`asyncio.all_tasks()` support already.

The global dict has a benefit: it doesn't overlap with the user's `.cancel()` 
calls but counts timeouts only.

A few words regarding task internals: _must_cancel boolean flag is set when a 
task doesn't wait for something, it was just created or `await sleep(0)` 
context switch was executed on the previous step.
Otherwise, a task always waits for a future completion, the future is stored as 
_fut_waiter.

If we use the global counting dict, timeout could call `.cancel()` only if the 
cancellation was not initiated previously. The current behavior works fine with 
this as the second `.cancel()` call is ignored.  Technically the ignorance 
could be reverted, `task.cancelling()` check is enough.

> If we don't set must-cancel, its cleanup is "shielded"

If I understand it correctly, I want this feature. Cleanup can perform async 
operations for a graceful resources shutdown, cancelling these cleaups look 
dangerous. With the current asyncio state, you can do it by calling 
`task.uncancel(); task.cancel()` in a line though.

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Alex Grönholm]

Alex Grönholm  added the comment:

Can I also get comments on my proposal for the "scope" parameter? Is there a 
use case it would not solve?

--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Guido van Rossum]

Guido van Rossum  added the comment:

The 3rd party context managers are somewhat of a red herring.
These are just try/except or try/finally blocks.

The inner cm (cm4) is irrelevant, it will see CancelledError and presumably 
that bubbles out. If it does any resource cleanup we can replace it with 
try/finally for purposes of simplifying the example.

But here's an even simpler example that poses the same question:

async with asyncio.timeout(1) as cm1:
  try:
async with asyncio.timeout(1) as cm3:
  await asyncio.sleep(10)  # Raises CancelledError
  except TimeoutError:
print("timed out")

Does this see CancelledError or catch TimeoutError? I had naively expected that 
it would catch TimeoutError, but then there's no place for the outer cancel 
scope to have any effect, so I agree that it should indeed see CancelledError, 
and "timed out" is never printed. The outer cancel scope sees CancelledError 
and turns it into TimeoutError.

Note that if the outer cancel scope has a longer timeout (which isn't expired 
yet), the try/except will catch TimeoutError. If it then enters another `await 
asyncio.sleep(10)` it will be cancelled and the outer cancel scope will raise 
TimeoutError.

How to implement this behavior? It can be done with the "cancel counter" that I 
proposed and Tin implemented in https://github.com/python/cpython/pull/31434.

Can it be done with the simpler version (just a cancel-requested bit), without 
using a nonce? I don't think so -- we don't know in which order the cancel call 
from the inner and outer cancel scope happen, and if the inner goes first, it 
cannot be aware of the outer.

So I think the cancel counter is the minimal change needed.

I have one final question, to which I don't have a firm answer yet. In 
Task.cancel(), if the cancel counter is already nonzero, should it still go 
ahead and set the must-cancel flag (or pass the cancellation on to 
`self._fut_waiter` -- I am still not sure what that's for :-( ). I think it 
only makes a difference if the task being cancelled has already caught a 
CancelledError (from the first cancel()) and is handling it. If we set 
must-cancel, then if it uses `await` it will be cancelled again. If we don't 
set must-cancel, its cleanup is "shielded". **Opinions?**




(PS. There's a typo in Andrew's example -- it should be "async with", not 
"async def".)

--

___
Python tracker 

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

[issue46810] multiprocessing.connection.Client doesn't support ipv6

[Michael Hupfer]

New submission from Michael Hupfer :

Hi there,

connecting a multiprocessing.connection.Client to an ipv6 address is not 
possible, since the address family is not passed into the constructor of class 
SocketClient. The constructor determines the family by calling 
address_type(address), which never returns AF_INET6.

The class SocketListener already implemented ipv6 support.

kind regards

--
messages: 413599
nosy: mhupfer
priority: normal
severity: normal
status: open
title: multiprocessing.connection.Client doesn't support ipv6
type: behavior
versions: Python 3.9

___
Python tracker 

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

[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

[sping]

sping  added the comment:

I'm busy with the release upstream at the moment.  I'll see what I can do.

--

___
Python tracker 

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

[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

[Michał Górny]

Michał Górny  added the comment:

Could you make a PR to fix the test failures?  I suppose that could speed 
things up and if not, I'd at least have something to pull into Gentoo.

--

___
Python tracker 

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

[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

[sping]

sping  added the comment:

Hi Michal,


TL;DR would be:

- There is a regression but none of these test fails are related.

- There will be a release Expat 2.4.6 with the regression fixed later today.

- The 3 failing tests need (small) adjustments to Expat 2.4.5
  and these fails are not considered bugs in Expat.

I will demo a fix to 2 of the 3 test fails below:


# git diff -U1 | cat
diff --git a/Lib/test/test_minidom.py b/Lib/test/test_minidom.py
index 1663b1f114..38cea97a97 100644
--- a/Lib/test/test_minidom.py
+++ b/Lib/test/test_minidom.py
@@ -12,2 +12,3 @@
 from xml.dom.minidom import getDOMImplementation
+from xml.parsers.expat import ExpatError
 
@@ -1149,4 +1150,6 @@ def testEncodings(self):
 # of crashing
-self.assertRaises(UnicodeDecodeError, parseString,
-b'Comment \xe7a va ? Tr\xe8s bien 
?')
+self.assertRaises(ExpatError, parseString,
+b'')
+self.assertRaises(ExpatError, parseString,
+b'Comment \xe7a va ? Tr\xe8s bien ?')
 
@@ -1611,3 +1614,3 @@ def testEmptyXMLNSValue(self):
 def testExceptionOnSpacesInXMLNSValue(self):
-with self.assertRaisesRegex(ValueError, 'Unsupported syntax'):
+with self.assertRaisesRegex(ExpatError, "syntax error"):
 parseString('')
 

For the third test, the key is that the closing curly brace is used as the
namespace separator in line 3660…

  self->parser = EXPAT(ParserCreate_MM)(encoding, &ExpatMemoryHandler, "}");
  
…in file Modules/_elementtree.c (which is okay but part of the test fail).

Best



Sebastian

--
title: Please update bundled libexpat to 2.4.5 with security fixes (5 CVEs) -> 
Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)

___
Python tracker 

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

[issue39327] shutil.rmtree using vagrant synched folder fails

[miss-islington]

Change by miss-islington :


--
pull_requests: +29580
pull_request: https://github.com/python/cpython/pull/31451

___
Python tracker 

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

[issue39327] shutil.rmtree using vagrant synched folder fails

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +29579
pull_request: https://github.com/python/cpython/pull/31450

___
Python tracker 

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

[issue39327] shutil.rmtree using vagrant synched folder fails

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset b77158b4da449ec5b8f682816a79d004fd65ed07 by Lital Natan in branch 
'main':
bpo-39327: Close file descriptors as soon as possible in shutil.rmtree 
(GH-31384)
https://github.com/python/cpython/commit/b77158b4da449ec5b8f682816a79d004fd65ed07


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue46809] copy.deepcopy can fail with unhelpful diagnostics

[Royce Mitchell]

New submission from Royce Mitchell :

Dear devs,

I have a small change request to make to a built-in Python file.

I'm currently running python 3.9.5

The file is copy.py

I would like to propose changing line 264 (in _reconstruct) from this:

y = func(*args)

to something like this:

try:
y = func(*args)
except TypeError as e:
raise TypeError(
f'calling {func.__module__}.{func.__qualname__}: {e.args[0]}', 
*e.args[1:]
).with_traceback(e.__traceback__) from None

All the change does it inject the module and qualified-name of the function 
trying to be
created onto the front-end of the error.

It makes this:

TypeError: __init__() missing 1 required positional argument: 'delta'

into this:

TypeError: calling datetime.datetime: calling mytz.Tzoffset: __init__() missing 
1 required positional argument: 'delta'

Here's a summary of the situation that led to this difficulty:

I have a project that is a couple years old and I'm no longer intimately aware 
of every single
thing the program is doing. I went to make some enhancements and noticed the 
unit tests
hadn't been touched since early in the project and decided I wanted to start 
using it.

I got stuck trying to prettyprint an object and getting a TypeError from the 
line above
because it was trying to call a function but was missing a required argument.

The traceback was unhelpful because I didn't know what object it was trying to 
copy,
which was very complicated with lots of data and sub-objects.

It turns out that a dataclass (named TransDetail) I was trying to prettyprint
had a list of another dataclass (named Billing) which had a datetime.datetime 
object
with a custom tzinfo object that I had never tried to deepcopy before.
(The custom tzinfo object was adapted from examples on StackOverflow)

Trying to google the issue, I found many others experiencing the same problem.

The fix was to define a default datetime.timedelta value for that custom tzinfo 
object,
but I had to make the changes to copy.py in order to efficiently figure out 
that this
was the problem.

--
components: Library (Lib)
messages: 413594
nosy: remdragon
priority: normal
severity: normal
status: open
title: copy.deepcopy can fail with unhelpful diagnostics
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue46757] dataclasses should define an empty __post_init__

[Eric V. Smith]

Change by Eric V. Smith :


--
assignee:  -> eric.smith

___
Python tracker 

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

[issue46807] Wrong class __annotations__ when field name and type are equal

[Larry Hastings]

Larry Hastings  added the comment:

Yeah, it's the same behavior.  In that class, you have defined Str to be "", 
then you reference Str in the annotation, and its value is "".  Whatever you 
set Str to in the example in [21], that's the value of the annotation.

GvR closed the previous report as "not a bug", so I'm gonna do that here too.

--

___
Python tracker 

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

[issue46672] NameError in asyncio.gather when passing a invalid type as an arg with multiple awaitables

[Andrew Svetlov]

Change by Andrew Svetlov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +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

[issue46672] NameError in asyncio.gather when passing a invalid type as an arg with multiple awaitables

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset f1916cde24053f4c8b6799730666d19474f8dd09 by Miss Islington (bot) 
in branch '3.10':
bpo-46672: fix `NameError` in `asyncio.gather` if type check fails (GH-31187) 
(GH-31440)
https://github.com/python/cpython/commit/f1916cde24053f4c8b6799730666d19474f8dd09


--

___
Python tracker 

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

[issue46771] Add some form of cancel scopes

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Suppose we have a case when two nested timeouts are reached at the same event 
loop iteration:

async def asyncio.timeout(1) as cm1:
   async with third_party_cm() as cm2:
   async def asyncio.timeout(1) as cm3:
   async with third_party_cm() as cm4:
   await asyncio.sleep(10)

What exception should be bubbled between outer and inner context manager 'exit' 
executions?

`sleep()` is interrupted with CancelledError, it is clear (and the only 
possible solution in asyncio world). `cm4.__aexit__` receives the 
CancelledError, does the cleanup if required, and re-raises the cancellation.

`cm3.__aexit__` receives the bubbled CancelledError and updates its own state 
and raises an exception.
The question is: what exception should be raised, CancelledError or 
TimeoutError?
What exception should see `cm2.__aexit__` code?

After careful thinking, I believe that CancelledError should be re-raised by 
*inner affected* timeout context managers, the only top-level *affected* 
context should convert CancelledError and raise TimeoutError.

My reasons for this behavior are:
  A generic asyncio code is usually *ready* for cancellation. If it wants to 
react to the cancellation event, it caught `asyncio.CancelledError` and 
reraised it. Also, the asyncio code is cancellation-ready by default because 
usually `BaseException` is now handled (asyncio.CancelledError is derived from 
BaseException). TimeoutError is caught by `except Exception` instead, it adds 
extra difficulty.
  Handling both CancelledError and TimeoutError by *any* asyncio code on async 
stack unwinding is tedious and error-prone. If we should choose one I bet on 
CancelledError.
  The inner code ignores timeouts usually (and executes resource cleanup only). 
That's what CancelledError handling exists for already. If the cleanup differs 
depending on timeout expiration, `cm3.expired` (name it) can be used as a flag. 
You can disagree with me here, my opinion is based on my experience of writing 
asyncio code only.
  The top-level affected timeout context manager should raise TimeoutError 
because it exists and is used for such things.

Long story short: all *internal affected* timeout context managers should not 
raise TimeoutError (or it should be configurable and 'off' by default) because 
`third_party_cm()` should have the same simple implementation whether is it 
used as `cm2` or `cm4`.

Happy to see your opinions regarding the question, folks!

--

___
Python tracker 

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

[issue46807] Wrong class __annotations__ when field name and type are equal

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Wrong type when missname dataclass attribute with existing 
variable name

___
Python tracker 

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

[issue46807] Wrong class __annotations__ when field name and type are equal

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This looks similar to https://bugs.python.org/issue36363

--
nosy: +xtreak

___
Python tracker 

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

[issue46740] Improve Telnetlib's throughput

[Martin Kirchgessner]

Change by Martin Kirchgessner :


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

___
Python tracker 

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

[issue46808] remove NEXT_BLOCK() from compile.c

[Irit Katriel]

Change by Irit Katriel :


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

___
Python tracker 

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

[issue46808] remove NEXT_BLOCK() from compile.c

[Irit Katriel]

New submission from Irit Katriel :

The compiler currently requires the code-generation functions to explicitly 
specify where basic blocks end, with a NEXT_BLOCK().

If you get that wrong, you get an exception about "malformed control flow 
graph" later, in the cfg analysis stage. It is not obvious then where the error 
is, and it makes it difficult to make changes in the compiler. 

We can instead make the compiler implicitly create a new block when this is 
needed (which is after specific opcodes).

--
assignee: iritkatriel
components: Interpreter Core
messages: 413589
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: remove NEXT_BLOCK() from compile.c
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

[issue46757] dataclasses should define an empty __post_init__

[Neil Girdhar]

Neil Girdhar  added the comment:

> How would an arbitrary derived class know how to call this? It can't. There 
> has to be knowledge of the base class's requirements already. Surely knowing 
> "__post_init__ must be called with some_arg" isn't too different from "I know 
> __post_init__ doesn't exist".

This is exactly the same problem you have with all other "augmenting methods" 
that have arbitrary parameters (e.g., __init__).  When calling super on a 
non-final class you could simply forward keyword arguments.


@dataclass
class X:
def __post_init__(self, **kwargs):
super().__post_init__(**kwargs)
...

@dataclass
class Y(X):
def __post_init__(self, **kwargs):
super().__post_init__(**kwargs)
...

> I'm still unconvinced, but I'll hold off on making a decision to see if 
> there's more support. Maybe taking it to python-ideas would be worthwhile.

Sounds good, done:  https://groups.google.com/g/python-ideas/c/-gctNaSqgew

--

___
Python tracker 

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

[issue46794] Please update bundled libexpat to 2.4.5 with security fixes (5 CVEs)

[Michał Górny]

Michał Górny  added the comment:

BTW there are test regressions with expat 2.4.5, apparently due to some test 
snippets now being rejected as invalid XML:

==
ERROR: test_issue3151 (test.test_xml_etree.BugsTest)
--
Traceback (most recent call last):
  File "/home/mgorny/git/cpython/Lib/xml/etree/ElementTree.py", line 1718, in 
feed
self.parser.Parse(data, False)
^^
xml.parsers.expat.ExpatError: syntax error: line 1, column 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mgorny/git/cpython/Lib/test/test_xml_etree.py", line 2196, in 
test_issue3151
e = ET.XML('')
^
  File "/home/mgorny/git/cpython/Lib/xml/etree/ElementTree.py", line 1347, in 
XML
parser.feed(text)
^
  File "/home/mgorny/git/cpython/Lib/xml/etree/ElementTree.py", line 1720, in 
feed
self._raiseerror(v)
^^^
  File "/home/mgorny/git/cpython/Lib/xml/etree/ElementTree.py", line 1627, in 
_raiseerror
raise err
^
xml.etree.ElementTree.ParseError: syntax error: line 1, column 0


==
ERROR: testEncodings (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
  File "/home/mgorny/git/cpython/Lib/test/test_minidom.py", line 1150, in 
testEncodings
self.assertRaises(UnicodeDecodeError, parseString,
^^
  File "/home/mgorny/git/cpython/Lib/unittest/case.py", line 734, in 
assertRaises
return context.handle('assertRaises', args, kwargs)
   
  File "/home/mgorny/git/cpython/Lib/unittest/case.py", line 218, in handle
callable_obj(*args, **kwargs)
^
  File "/home/mgorny/git/cpython/Lib/xml/dom/minidom.py", line 1998, in 
parseString
return expatbuilder.parseString(string)
   
  File "/home/mgorny/git/cpython/Lib/xml/dom/expatbuilder.py", line 925, in 
parseString
return builder.parseString(string)
   ^^^
  File "/home/mgorny/git/cpython/Lib/xml/dom/expatbuilder.py", line 223, in 
parseString
parser.Parse(string, True)
^^
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 5

==
ERROR: testExceptionOnSpacesInXMLNSValue (test.test_minidom.MinidomTest)
--
Traceback (most recent call last):
  File "/home/mgorny/git/cpython/Lib/test/test_minidom.py", line 1613, in 
testExceptionOnSpacesInXMLNSValue
parseString('')


  File "/home/mgorny/git/cpython/Lib/xml/dom/minidom.py", line 1998, in 
parseString
return expatbuilder.parseString(string)
   
  File "/home/mgorny/git/cpython/Lib/xml/dom/expatbuilder.py", line 925, in 
parseString
return builder.parseString(string)
   ^^^
  File "/home/mgorny/git/cpython/Lib/xml/dom/expatbuilder.py", line 223, in 
parseString
parser.Parse(string, True)
^^
xml.parsers.expat.ExpatError: syntax error: line 1, column 0

--
nosy: +mgorny

___
Python tracker 

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

[issue46807] Wrong class __annotations__ when field name and type are equal

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue46807] Wrong class __annotations__ when field name and type are equal

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +AlexWaygood, larry

___
Python tracker 

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

[issue46807] Wrong class __annotations__ when field name and type are equal

[Konstantin]

New submission from Konstantin :

In [18]: class Str(str):
...: pass

In [19]: class Class:
...: Str: str
...: 
...: 
...: Class.__annotations__
Out[19]: {'Str': str}

In [20]: class Class:
...: Str: str = ""
...: 
...: 
...: Class.__annotations__
Out[20]: {'Str': str}

In [21]: class Class:
...: Str: Str = ""
...: 
...: 
...: Class.__annotations__  # Wrong!
Out[21]: {'Str': ''}

In [22]: class Class:
...: Str: Str
...: 
...: 
...: Class.__annotations__
Out[22]: {'Str': __main__.Str}

It reproduced all the version which support annotations as part of the core (I 
tested python 3.6..3.10.2)

--
components: Parser
messages: 413586
nosy: kgubaev, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Wrong class __annotations__ when field name and type are equal
type: behavior
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

[issue46806] Overlapping PYTHONPATH may cause import already imported module

[aklajnert]

Change by aklajnert :


--
title: Overlapping PYTHONPATH may cause -> Overlapping PYTHONPATH may cause 
import already imported module

___
Python tracker 

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

[issue46252] Forbid passing SSLSocket into asyncio methods

[Andrew Svetlov]

Change by Andrew Svetlov :


--
resolution:  -> fixed
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

[issue46672] NameError in asyncio.gather when passing a invalid type as an arg with multiple awaitables

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset a6116a980c9eae91c2f9af7cbd0a9727e9b887ba by Andrew Svetlov in 
branch '3.9':
[3.9] bpo-46672: fix `NameError` in `asyncio.gather` if type check fails 
(GH-31187) (GH-31441)
https://github.com/python/cpython/commit/a6116a980c9eae91c2f9af7cbd0a9727e9b887ba


--

___
Python tracker 

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

[issue46806] Overlapping PYTHONPATH may cause

[aklajnert]

New submission from aklajnert :

I'm not 100% sure whether it is a bug or intentional behavior but looks like a 
bug to me. I couldn't find anything about it here or anywhere else.

Sample project structure:
```
.
├── main.py
└── src
├── __init__.py
├── common_object.py
├── user_1.py
├── user_2.py
└── user_3.py
```

`__init__.py` is an empty file.


```
# src/common_object.py
OBJECT = object()
```

```
# src/user_1.py
from .common_object import OBJECT
```

```
# src/user_2.py
from src.common_object import OBJECT
```

```
# src/user_3.py
from common_object import OBJECT
```

```
# main.py
import sys

sys.path.append("src")

from src import user_1, user_2, user_3


if __name__ == '__main__':
print(user_1.OBJECT is user_2.OBJECT) # True
print(user_1.OBJECT is user_3.OBJECT) # False
```

Since `src` package is added to `PYTHONPATH`, it is possible to import 
`common_object` by calling `from src.common_object` or `from common_object`.  
Both methods work, but using import without `src.` makes Python load the same 
module again instead of using the already loaded one.

If you extend `main.py` with the following code, you'll see a bit more:
```
modules = [
module
for name, module in sys.modules.items()
if "common_object" in name
]
print(len(modules)) # 2
print(modules[0].__file__ == modules[1].__file__) # True
```

In the `sys.modules` dict there will be two separate modules - one called 
`common_object` and another named `src.common_object`. 
If you compare the `__file__` value for both modules you'll see that they are 
the same. It seems that python gets the module name wrong.

--
messages: 413584
nosy: aklajnert
priority: normal
severity: normal
status: open
title: Overlapping PYTHONPATH may cause
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue46252] Forbid passing SSLSocket into asyncio methods

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +29575
pull_request: https://github.com/python/cpython/pull/31444

___
Python tracker 

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

[issue46252] Forbid passing SSLSocket into asyncio methods

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +29574
pull_request: https://github.com/python/cpython/pull/31443

___
Python tracker 

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

[issue46252] Forbid passing SSLSocket into asyncio methods

[Andrew Svetlov]

Andrew Svetlov  added the comment:

The issue can be backported.
It doesn't change existing behavior but raises a better error.

--

___
Python tracker 

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

[issue46252] Forbid passing SSLSocket into asyncio methods

[Andrew Svetlov]

Change by Andrew Svetlov :


--
versions: +Python 3.9

___
Python tracker 

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

[issue46805] Add low level UDP socket functions to asyncio

[Andrew Svetlov]

Andrew Svetlov  added the comment:

A separate issue for 'flags' adding looks better. The reason for missing is an 
oversight I think.

--

___
Python tracker 

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

[issue46805] Add low level UDP socket functions to asyncio

[Alex Grönholm]

Alex Grönholm  added the comment:

One question: should I add the "flags" argument to the new functions? For some 
reason it's missing from the existing functions, so maybe I should add that in 
a separate PR?

--

___
Python tracker 

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

[issue46252] Forbid passing SSLSocket into asyncio methods

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +29573
pull_request: https://github.com/python/cpython/pull/31442

___
Python tracker 

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

[issue46252] Forbid passing SSLSocket into asyncio methods

[Andrew Svetlov]

New submission from Andrew Svetlov :

SSLSocket is a blocking object by definition, it is not compatible with asyncio.

asyncio has a check for SSLSocket in sock_*() operations, it should be extended 
to transport-based API

--
title: SSLWantReadError causes _SelectorSocketTransport to close -> Forbid 
passing SSLSocket into asyncio methods

___
Python tracker 

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

[issue46672] NameError in asyncio.gather when passing a invalid type as an arg with multiple awaitables

[Andrew Svetlov]

Change by Andrew Svetlov :


--
pull_requests: +29572
pull_request: https://github.com/python/cpython/pull/31441

___
Python tracker 

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

[issue46805] Add low level UDP socket functions to asyncio

[Alex Grönholm]

New submission from Alex Grönholm :

The asyncio module currently has a number of low-level functions for working 
asynchronously with raw socket objects. Such functions for working with UDP 
sockets are, however, notably absent, and there is no workaround for this. You 
can of course use sock_receive() with UDP sockets but that would discard the 
sender address which is a showstopper problem. Also, having a send function 
that applies back pressure to the sender if the kernel buffer is full would 
also be prudent.

I will provide a PR if you're okay with this.
It would include the following functions:

* sock_sendto()
* sock_recvfrom()
* sock_recvfrom_into()

--
components: asyncio
messages: 413579
nosy: alex.gronholm, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Add low level UDP socket functions to asyncio
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

[issue46804] Yaytext.net - Tạo văn bản chữ kiểu, kí tự đặc biệt độc đáo

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> not a bug
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

[issue46804] Yaytext.net - Tạo văn bản chữ kiểu, kí tự đặc biệt độc đáo

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
Removed message: https://bugs.python.org/msg413575

___
Python tracker 

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

[issue46804] Yaytext.net - Tạo văn bản chữ kiểu, kí tự đặc biệt độc đáo

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
Removed message: https://bugs.python.org/msg413574

___
Python tracker 

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

[issue46672] NameError in asyncio.gather when passing a invalid type as an arg with multiple awaitables

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 4ab8167b9c60d1a04b2e3116d0c52db254b68cda by Nikita Sobolev in 
branch 'main':
bpo-46672: fix `NameError` in `asyncio.gather` if type check fails (GH-31187)
https://github.com/python/cpython/commit/4ab8167b9c60d1a04b2e3116d0c52db254b68cda


--

___
Python tracker 

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

[issue46672] NameError in asyncio.gather when passing a invalid type as an arg with multiple awaitables

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +29571
pull_request: https://github.com/python/cpython/pull/31440

___
Python tracker 

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

[issue46752] Introduce task groups to asyncio and change task cancellation semantics

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset e7130c2e8c6abfaf04b209bd5b239059eda024b9 by Andrew Svetlov in 
branch 'main':
bpo-46752: Uniform TaskGroup.__repr__ (GH-31409)
https://github.com/python/cpython/commit/e7130c2e8c6abfaf04b209bd5b239059eda024b9


--

___
Python tracker 

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

[issue45620] A misleading url in 'Floating Point Arithmetic' page

[Akuli]

Akuli  added the comment:

If you still have the problem, can you show us what headers your browser sends 
to websites? You can see that by running in Python:

import socket
print(socket.create_server(('127.0.0.1', 
12345)).accept()[0].recv(1024).decode())

and then going to http://localhost:12345/ in your browser.

I'm especially interested in the line that starts with Accept-Language. For me, 
the site now works, and my Accept-Language header is:

Accept-Language: 
en-US,en;q=0.9,fi;q=0.8,sv;q=0.7,pt;q=0.6,it;q=0.5,zh-CN;q=0.4,zh;q=0.3

--

___
Python tracker 

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

[issue44791] Substitution of ParamSpec in Concatenate

[Mehdi2277]

Mehdi2277  added the comment:

Concatenate[int, ...] I would interpret as a function signature with first 
argument int, followed by arbitrary arguments afterwards. I haven't run into 
this case, but ... is allowed in other spots Paramspec is allowed currently.

P = Paramspec("P")

class Foo(Generic[P]):
  ...

Foo[...] # Allowed 
Callable[..., None] # Allowed

Are there any other places a paramspec is allowed? Generic type argument, first 
argument to callable, last to concatenate, anything else?

I'm unaware of any type checking use case for Concatenate[int, ...]. You can 
practically get same thing by using a paramspec variable without using it 
elsewhere so that it captures, but then effectively discards that information.

def use_func1(f: Callable[Concatenate[int, P], None]) -> None:
  ...

def use_func2(f: Callable[Concatenate[int, ...], None]) -> None:
  ...

feels like those two signatures should encode same information.

--
nosy: +med2277

___
Python tracker 

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

[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox

[Steven D'Aprano]

Change by Steven D'Aprano :


Removed file: https://bugs.python.org/file50635/6.jpeg

___
Python tracker 

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

[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox

[Steven D'Aprano]

Change by Steven D'Aprano :


--
nosy:  -xiaox55066

___
Python tracker 

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

[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox

[Steven D'Aprano]

Change by Steven D'Aprano :


--
Removed message: https://bugs.python.org/msg413568

___
Python tracker 

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

[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox

[Steven D'Aprano]

Change by Steven D'Aprano :


--
Removed message: https://bugs.python.org/msg413567

___
Python tracker 

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

[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox

[Steven D'Aprano]

Change by Steven D'Aprano :


--
Removed message: https://bugs.python.org/msg413566

___
Python tracker 

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

[issue45620] A misleading url in 'Floating Point Arithmetic' page

[肖小小]

肖小小  added the comment:

It shows the drug ad slogan even with the google search result.
http://www.strong19.com/I searched 'The Perils of Floating Point lahey'

--

___
Python tracker 

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