For what it's worth, I've increasingly considered creating a context in
a generator (sync or async) to be an antipattern. To this end, in my
case, I moved creation of the context outside of the generator. This
resulted in a more explicit contract, which actually simplified
reasoning about its behav
I, too, think I ran into basically the same situation as Paul: An outer
async generator calls an inner async generator. The outer doesn't fully
consume the inner. The inner uses an async context manager. The inner CM
isn't exited when expected and resources aren't released when
required/expected.
On Sat, 6 Feb 2021 at 19:54, Daniel Moisset wrote:
>
> Hi Mark,
>
> I think some of these issues have already been raised and replied (even if no
> agreement has been reached). but this is a good summary, so let me reply with
> a summary of responses for this.
>
> On Sat, 6 Feb 2021 at 15:51, Ma
On Sun, Feb 07, 2021 at 12:32:40PM +0300, Paul Sokolovsky wrote:
> And nobody says that there will be *incompatible* changes to the
> pattern matching, just that previous experience, and discussion of the
> PEP622/PEP634 shows that there's a probability of that (higher than
> usual).
Fine. The ti
On Sun, Feb 07, 2021 at 09:58:03AM +0300, Paul Sokolovsky wrote:
> > A feature doesn't need to be a `__future__` import for you to just
> > not use it.
>
> Right, and the talk is about the opposite - early adopters of
> PEP634-style pattern matching should mark the modules in which they
> *use* P
Hi Paul,
I suggest that you just go straight to the PEP phase.
--Guido
On Thu, Feb 4, 2021 at 11:54 PM Paul Sokolovsky wrote:
> Hello,
>
> Everyone knows how hard to find a compelling usecase for the assignment
> expression operator (":=", colloquially "walrus operator").
> https://www.python.
Hi Python Dev team,
I submitted a PR https://github.com/python/cpython/pull/23736 two months ago.
The PR, which fixes an issue https://bugs.python.org/issue41928 in ZipFile, is
"awaiting core review".
Best regards.
Andrea Giudiceandrea
___
Python-Dev
Hi Daniel,
On 06/02/2021 7:47 pm, Daniel Moisset wrote:
Hi Mark,
I think some of these issues have already been raised and replied (even
if no agreement has been reached). but this is a good summary, so let me
reply with a summary of responses for this. >
On Sat, 6 Feb 2021 at 15:51, Mark Sha
Hello,
On Sun, 7 Feb 2021 20:02:48 +1100
Chris Angelico wrote:
> On Sun, Feb 7, 2021 at 7:54 PM Paul Sokolovsky
> wrote:
> >
> > So, you're saying that, by the benevolence of divine providence,
> > most (can you truly vouch for "all" and provide evidence?) features
> > so far added to __future_
On Sun, Feb 7, 2021 at 7:54 PM Paul Sokolovsky wrote:
>
> So, you're saying that, by the benevolence of divine providence,
> most (can you truly vouch for "all" and provide evidence?) features so
> far added to __future__ never were changed (enough).
No, I'm saying that the __future__ directive i
Hello,
On Sun, 7 Feb 2021 19:09:14 +1100
Chris Angelico wrote:
> On Sun, Feb 7, 2021 at 6:25 PM Paul Sokolovsky
> wrote:
> >
> > Hello,
> >
> > On Sat, 6 Feb 2021 23:05:19 -0800
> > Guido van Rossum wrote:
> >
> > > That’s incorrect. __future__ is used when something new and
> > > *incompati
On Sun, Feb 7, 2021 at 6:25 PM Paul Sokolovsky wrote:
>
> Hello,
>
> On Sat, 6 Feb 2021 23:05:19 -0800
> Guido van Rossum wrote:
>
> > That’s incorrect. __future__ is used when something new and
> > *incompatible* is being introduced (and the old way is being
> > deprecated at the same time). For
12 matches
Mail list logo
