This PEP [1] introduces syntax to mark individual keys of a TypedDict as
either required or potentially-missing. Previously the only way to have
a TypedDict with mixed required and non-required keys was to define two
TypedDicts - one with total=True and one with total=False - and have one
of
On Sun, Jan 30, 2022 at 12:03 PM Ethan Smith wrote:
>
> As a non-committer, I want to make a plea for non-committer approval reviews,
> or at least that they have a place. When asked how outsiders can contribute I
> frequently see "review open PRs" as a suggested way of contributing to
>
As a non-committer, I want to make a plea for non-committer approval
reviews, or at least that they have a place. When asked how outsiders can
contribute I frequently see "review open PRs" as a suggested way of
contributing to CPython. Not being able to approve PRs that are good would
be a barrier
On Sun, Jan 30, 2022 at 10:39 AM Ethan Furman wrote:
>
>
> > And lots of non-committer PR reviews that only approve.
>
> I have seen this. Quite irritating.
>
We can prohibit approval from non core developers. Do we use this
setting already?
On 1/29/22 3:14 AM, Lrupert via Python-Dev wrote:
> As someone who is watching the python/cpython repository, I'm very used to
see lots of traffic. But
> lately there have been a surge of spammy PRs which are about the same,
generally very trivial subject
> but individually fixing each
As someone who is watching the python/cpython repository, I'm very used to see
lots of traffic. But lately there have been a surge of spammy PRs which are
about the same, generally very trivial subject but individually fixing each
occurrence one by one:
- Add coverage to X (tens of them, as
On Sat, Jan 29, 2022 at 1:01 AM Pablo Galindo Salgado
wrote:
> Hi everyone,
>
> We have a huge amount of buildbots failing and seems to be related to
> different issues
> that keep piling up. To prevent this from going worse,* I am blocking the
> main branch*
> *until these issues are resolved.*
On Fri, Jan 28, 2022 at 6:28 PM Guido van Rossum wrote:
> I think we will get *one* chance in the next decade to get it right. Whether
> that's HPy or evolution of the C API I'm not sure.
Would you mind to elaborate? Which risk do you expect from switching
to HPy and from fixing the C API
