Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEP 646: Decide on substitution behavior #91162

Closed
JelleZijlstra opened this issue Mar 13, 2022 · 70 comments
Closed

PEP 646: Decide on substitution behavior #91162

JelleZijlstra opened this issue Mar 13, 2022 · 70 comments
Assignees
Labels
3.11 only security fixes topic-typing type-bug An unexpected behavior, bug, or error

Comments

@JelleZijlstra
Copy link
Member

BPO 47006
Nosy @gvanrossum, @serhiy-storchaka, @JelleZijlstra, @Fidget-Spinner, @mrahtz, @mrahtz, @AlexWaygood
PRs
  • gh-87390: Add tests demonstrating current type variable substitution behaviour #32341
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/JelleZijlstra'
    closed_at = None
    created_at = <Date 2022-03-13.20:46:16.314>
    labels = ['type-bug', 'release-blocker', '3.11']
    title = 'PEP 646: Decide on substitution behavior'
    updated_at = <Date 2022-04-07.01:50:13.871>
    user = 'https://github.com/JelleZijlstra'

    bugs.python.org fields:

    activity = <Date 2022-04-07.01:50:13.871>
    actor = 'gvanrossum'
    assignee = 'JelleZijlstra'
    closed = False
    closed_date = None
    closer = None
    components = []
    creation = <Date 2022-03-13.20:46:16.314>
    creator = 'JelleZijlstra'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 47006
    keywords = ['patch']
    message_count = 17.0
    messages = ['415100', '415107', '415108', '415109', '415557', '415623', '415637', '415694', '415710', '415712', '415734', '415752', '415753', '416707', '416795', '416813', '416913']
    nosy_count = 7.0
    nosy_names = ['gvanrossum', 'serhiy.storchaka', 'JelleZijlstra', 'kj', 'matthew.rahtz', 'mrahtz', 'AlexWaygood']
    pr_nums = ['32341']
    priority = 'release blocker'
    resolution = None
    stage = 'patch review'
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue47006'
    versions = ['Python 3.11']

    @JelleZijlstra
    Copy link
    Member Author

    We've had some disagreement about the behavior of TypeVarTuple substitution related to PEP-646, and the discussion has now spilled around multiple PRs. I'd like to use this issue to come to an agreement so we don't have to chase through so many different places.

    Links:

    I'd like to ask that until we come to an agreement we hold off on making any more changes, so we don't have to go back and forth and we ensure that the eventual solution covers all edge cases.

    The disagreement is about what to do with TypeVarTuple substitution: the behavior when a generic type is subscripted, like tuple[*Ts][int, str].

    There are two possible extreme approaches:

    • Implement full substitution support, just as we have it for existing TypeVars. This is complicated because TypeVarTuple makes it much harder to match up the types correctly. However, it is consistent with the behavior for other TypeVar-like objects. My example would turn into GenericAlias(tuple, (int, str)).
    • Give up on substitution and just return a new GenericAlias object: GenericAlias(GenericAlias(tuple, Unpack[Ts]), (int, str). This avoids implementing any complex runtime behavior, but it inconsistent with existing behavior and less pretty when you print out the type. I prefer this approach because there's less risk that future enhancements to typing will break it. I also want to explore extending this approach to ParamSpec substitution.

    @JelleZijlstra JelleZijlstra added the 3.11 only security fixes label Mar 13, 2022
    @JelleZijlstra JelleZijlstra self-assigned this Mar 13, 2022
    @JelleZijlstra JelleZijlstra added the 3.11 only security fixes label Mar 13, 2022
    @JelleZijlstra JelleZijlstra self-assigned this Mar 13, 2022
    @mrahtz
    Copy link
    Mannequin

    mrahtz mannequin commented Mar 13, 2022

    Thanks for starting this, Jelle - I was a bit unsure about how to proceed here.

    Given that #31800 is already merged, I'd also propose something halfway between the two extremes: return a sensible substitution when the logic to compute that isn't too onerous, and a new GenericAlias object when it is. The upsides are that we'd probably be able to return reasonable substitutions for the vast majority of cases, and that we wouldn't have to remove what's already been merged. The downsides would be lack of consistency, and the potential for changing rules about what does and doesn't return a full substitution as time goes on and new features are added.

    @mrahtz
    Copy link
    Mannequin

    mrahtz mannequin commented Mar 13, 2022

    (Having said that, to be clear: my preferred solution currently would still be the solution where we just return a new GenericAlias for anything involving a TypeVarTuple. The crux is what Serhiy is happy with.)

    @JelleZijlstra
    Copy link
    Member Author

    Thanks Matthew! Merged PRs can still be reverted, and we have some time before the feature freeze. I'd like to hear what Guido and Ken think too.

    If we go with the GenericAlias substitution, we need to make sure that such aliases still work as base class. That would need some C work to make types.GenericAlias.__mro_entries__ recurse if the alias's origin is itself a GenericAlias. There's a few other subtleties to think about; I can work on that but don't have a ton of time today.

    @serhiy-storchaka
    Copy link
    Member

    I am for consistent behavior. If return GenericAlias(GenericAlias(tuple, Unpack[Ts]), (int, str)) for tuple[*Ts][int, str], we should also return GenericAlias(GenericAlias(list, T), int) for list[T][int], etc. And it will cause multiple problems:

    • A repr can be less readable.
    • It will break equality comparison and hashing. Good bye caching.
    • What about __origin__, __parameters__, __args__? How will they be calculated?
    • It can break code which uses annotations for something. For example it can break dataclasses.

    It may be that will need to use it as a fallback for cases like tuple[T, *Ts][*Ts2] (currently it is error). But I am not sure that such cases should be supported.

    @gvanrossum
    Copy link
    Member

    I think I'm with Serhiy, I don't understand the hesitance to transform tuple[*Ts][int, str] into tuple[int, str].

    What would be an example of a substitution that's too complex to do?

    @JelleZijlstra
    Copy link
    Member Author

    It's simple if you only look at simple examples.

    Here are some examples current main (with Serhiy's patch for the Python version of typing) gets wrong:

    >>> from typing import *
    >>> Ts = TypeVarTuple("Ts")
    >>> T1 = TypeVar("T1")
    >>> T2 = TypeVar("T2")
    >>> Tuple[T1, Unpack[Ts], T2][int, Unpack[tuple[int]]]  # expect error
    typing.Tuple[int, *tuple[int]]
    >>> Tuple[T1, Unpack[Ts], str, T2][int, Unpack[Ts]]  # expect error (T2 missing)
    typing.Tuple[int, str, *Ts]  # it put *Ts in the wrong place
    >>> Tuple[T1, Unpack[Ts], str, T2][int, Unpack[Ts], Unpack[Ts]]  # expect error (*Ts can't substitute T2)
    typing.Tuple[int, *Ts, str, *Ts]
    >>> class G(Generic[T1, Unpack[Ts], T2]): pass
    ... 
    >>> G[int]  # expect error
    __main__.G[int]

    We can probably fix that, but I'm not looking forward to implementing the fixed logic in both Python and C. Also, I'm worried that it won't work with future extensions to the type system (e.g., the rumored Map operator) that may go into 3.12 or later versions.

    @serhiy-storchaka
    Copy link
    Member

    The first case will be practically fixed by GH 32030 after chenging the grammar to allow unpacking in index tuple: A[*B].

    Two other cases will be fixed by GH 32031. It does not require any C code.

    In the last case no error is raised because some error checks are skipped if any of Generic arguments is a TypeVarTuple. We just need to add such checks. This is Python-only code too.

    Note that the alternative proposition is even more lenient to errors.

    @mrahtz
    Copy link
    Mannequin

    mrahtz mannequin commented Mar 21, 2022

    [Guido]

    What would be an example of a substitution that's too complex to do?

    We also need to remember the dreaded arbitrary-length tuple. For example, I think it should be the case that:

    T = TypeVar('T')
    Ts = TypeVarTuple('Ts')
    class C(Generic[*Ts]): pass
    Alias = C[T, *Ts]
    Alias2 = Alias[*tuple[int, ...]]
    # Alias2 should be C[int, *tuple[int, ...]]

    Ok, this is a bit of a silly example, but if we're committing to evaluating substitutions correctly, we should probably make even this kind of example behave correctly so that users who accidentally do something silly can debug what's gone wrong.

    [Serhiy]

    A repr can be less readable.

    Definitely true.

    It will break equality comparison and hashing. Good bye caching.

    Huh, I didn't know about this one. Fair enough, this is totally a downside.

    What about __origin__, __parameters__, __args__? How will they be calculated?

    This could admittedly be thorny. We'd have to think it through carefully. Admittedly also a downside.

    It can break code which uses annotations for something. For example it can break dataclasses.

    Oh, also interesting - I didn't know about this one either. Could you give an example?

    The first case will be practically fixed by GH 32030 after chenging the grammar to allow unpacking in index tuple: A[*B].

    We actually deliberately chose not to unpack concrete tuple types - see the description of #30398, under the heading 'Starred tuple types'. (If you see another way around it, though, let me know.)

    Two other cases will be fixed by GH 32031. It does not require any C code.

    I'm also not sure about this one; disallowing unpacked TypeVarTuples in argument lists to generic aliases completely (if I've understood right?) seems like too restrictive a solution. I can imagine there might be completely legitimate cases where the ability to do this would be important. For example:

    DType = TypeVar('DType')
    Shape = TypeVarTuple('Shape')
    class Tensor(Generic[DType, *Shape]): ...
    Uint8Tensor = Tensor[uint8, *Shape]
    Unit8BatchTensor = Uint8Tensor[Batch, *Shape]

    Note that the alternative proposition is even more lenient to errors.

    True, but at least it's predictably lenient to errors - I think the repr makes it very clear that "Woah, you're doing something advanced here. You're on your own!" I think it better fits the principle of least astonishment to have something that consistently lets through all errors of a certain class than something that sometimes catches errors and sometimes doesn't.

    @mrahtz
    Copy link
    Mannequin

    mrahtz mannequin commented Mar 21, 2022

    P.s. To be clear, (I think?) these are all substitutions that are computable. We *could* implement the logic to make all these evaluate correctly if we wanted to. It's just a matter of how much complexity we want to allow in typing.py (or in the runtime in general, if we say farmed some of this logic out to a separate module).

    @gvanrossum
    Copy link
    Member

    I'd like to look at this as a case of simplifying something to its simplest canonical form, but no simpler. This is what the existing fixed-typevar expansion does: e.g. tuple[str, T, T][int] becomes tuple[str, int, int].

    I propose that we try to agree on a set of rules for what can be simplified further and what cannot, when we have B = C[...]; A = B[...], (IOW A = C[...][...]), for various shapes of the subscripts to C and B. Note that what's relevant for the second subscript is C[...].__parameters__, so I'll call that "left" below.

    1. Some edge case seems to be that if *tuple[...] is involved on either side we will never simplify. Or perhaps a better rule is that *tuple[...] is never simplified away (but fixed items before and after it may be).

    2. Another edge case is that if neither side has any starred items we will always simplify (since this is the existing behavior in 3.10). This may raise an error if the number of subscripts on the right does not match the number of parameters on the left.

    3. If there's a single *Ts on the left but not on the right, we should be able to simplify, which again may raise an error if there are not enough values on the right, but if there are more than enough, the excess will be consumed by *Ts (in fact that's the only way *Ts is fed).

    4. If there's a *Ts on the right but not on the left, we should _not_ simplify, since whatever we have on the left serves as a constraint for *Ts. (E.g. tuple[int, int][*Ts] constrains *Ts to being (int, int).)

    5. If there's exactly one *Ts on the left and one on the right, we _might__ be able to simplify if the prefix and suffix of the __parameters__ match the prefix and suffix of the subscript on the right. E.g. C[int, T, *Ts, float][str, *Ts] can be simplified to C[int, str, *Ts, float]. OTOH C[int, T, *Ts, float][*Ts] cannot be simplified -- but we cannot flag it as an error either. Note that __parameters__ in this example is (T, Ts); we have to assume that typevartuples in __parameters__ are always used as *Ts (since the PEP recognizes no valid unstarred uses of Ts).

    TBH case 5 is the most complex and I may have overlooked something. I'm more sure of cases 1-4.

    @serhiy-storchaka
    Copy link
    Member

    Alias = C[T, *Ts]
    Alias2 = Alias[*tuple[int, ...]]

    Alias2 should be C[int, *tuple[int, ...]]

    tuple[int, ...] includes also an empty tuple, and in this case there is no value for T.

    Oh, also interesting - I didn't know about this one either. Could you give an example?

    If __origin__, __parameters__, __args__ are a mess, it will definitely break a code which use them.

    We actually deliberately chose not to unpack concrete tuple types - see the description of #30398, under the heading 'Starred tuple types'. (If you see another way around it, though, let me know.)

    You assumed that *tuple[str, bool] in def foo(*args: *tuple[str, bool]) should give foo.__annotations__['args'] = tuple[str, bool], but it should rather give (str, bool). No confusion with tuple[str, bool].

    And one of PEP-646 options is to implement star-syntax only in subscription, not in var-parameter type annotations.

    I'm also not sure about this one; disallowing unpacked TypeVarTuples in argument lists to generic aliases completely (if I've understood right?)

    No, it will only be disallowed in substitution of a VarType. Tuple[T][*Ts] -- error. Tuple[*Ts][*Ts2] -- ok.

    I propose to implement simple and strict rules, and later add support of new cases where it makes sense.

    @serhiy-storchaka
    Copy link
    Member

    1. Some edge case seems to be that if *tuple[...] is involved on either side we will never simplify. Or perhaps a better rule is that *tuple[...] is never simplified away (but fixed items before and after it may be).

    I do not understand this. Do you forbid simplifying of tuple[*Ts, float][str, *tuple[int, ...]] to tuple[str, *tuple[int, ...], float]?

    I think that the rule should be that *tuple[X, ...] cannot split between different variables. Or that it cannot substitute a TypeVar. A more strong variant of rule 4.

    1. ... but we cannot flag it as an error either.

    I think that it will better to flag it as an error now. Later, after all code be merged and all edge cases be handled we can return here and reconsider this.

    There are workarounds for this.

    • You should not use Generic[*Ts] if you require at least one item, but Generic[*Ts, T].
    • Instead of def foo(*args: *Ts) use def foo(*args: *tuple[*Ts, T]).

    These tricks are common in functional programming.

    The rest of the rules match my implementations more or less.

    @mrahtz
    Copy link
    Mannequin

    mrahtz mannequin commented Apr 4, 2022

    Apologies for the slow reply - coming back to this now that the docs and pickling issues are mostly sorted.

    [Serhiy]

    > Alias = C[T, *Ts]
    > Alias2 = Alias[*tuple[int, ...]]
    > # Alias2 should be C[int, *tuple[int, ...]]

    tuple[int, ...] includes also an empty tuple, and in this case there is no value for T.

    This was my initial intuition too, but Pradeep pointed out to me in #31021 (comment) that for tuple[int, ...], Python has chosen the opposite mindset: instead of assuming the worst-case scenario, we assume the best-case scenario. Thus, the following type-checks correctly with mypy (https://mypy-play.net/?mypy=latest&python=3.10&gist=b9ca66fb7d172f939951a741388836a6):

    def return_first(tup: tuple[int, ...]) -> int:
        return tup[0]
    tup: tuple[()] = ()
    return_first(tup)

    > We actually deliberately chose not to unpack concrete tuple types - see the description of #30398, under the heading 'Starred tuple types'. (If you see another way around it, though, let me know.)

    You assumed that *tuple[str, bool] in def foo(*args: *tuple[str, bool]) should give foo.__annotations__['args'] = tuple[str, bool], but it should rather give (str, bool). No confusion with tuple[str, bool].

    Fair point, we could technically distinguish between tuple[str, bool] and (str, bool). But if I was a naive user and I saw foo.__annotations__['args'] == (str, bool), I don't think it'd be immediately obvious to me that the type of args was *tuple[str, bool].

    Also though, there's a second reason mentioned in #30398 why (str, bool) wouldn't be the best choice. We decided that the runtime behaviour of *args: *something should be that we essentially do (*something,)[0]. If we made tuple[int, str] unpack to (int, str), then we'd end up with __annotations__['args'] == (int,).

    And one of PEP-646 options is to implement star-syntax only in subscription, not in var-parameter type annotations.

    As in, we would allow Generic[*Ts], but not *args: *Ts? That'd be a major change to the PEP - not an option I'm willing to consider at this stage in the process.

    > I'm also not sure about this one; disallowing unpacked TypeVarTuples in argument lists to generic aliases completely (if I've understood right?)

    No, it will only be disallowed in substitution of a VarType. Tuple[T][*Ts] -- error. Tuple[*Ts][*Ts2] -- ok.

    Ah, gotcha. My mistake.

    [Guido]

    I ran out of time this evening :) Will reply properly soon.

    @mrahtz
    Copy link
    Mannequin

    mrahtz mannequin commented Apr 5, 2022

    [Guido]

    1. Some edge case seems to be that if *tuple[...] is involved on either side we will never simplify.

    Alright, let me think this through with some examples to get my head round it.

    It would prohibit the following difficult case:

    class C(Generic[*Ts]): ...
    Alias = C[T, *Ts]
    Alias[*tuple[int, ...]]  # Does not simplify; stays C[T, *Ts][*tuple[int, ...]]

    That seems pretty reasonable. It would also prohibit these other relatively simple cases, but I guess that's fine:

    Alias = C[*Ts]
    Alias[*tuple[int, ...]]  # Does not simplify; stays C[*Ts][*tuple[int, ...]]
    
    Alias = C[T, *tuple[int, ...]]
    Alias[str]  # Does not simplify; stays C[T, *tuple[int, ...]][str]

    Or perhaps a better rule is that *tuple[...] is never simplified away (but fixed items before and after it may be).

    Is this to say that we effectively prohibit binding *tuple[...] to anything? If we can simplify without binding *tuple[...] to anything, then we do simplify, but otherwise, we don't simplify? So under this rule, the following WOULD work?

    Alias = C[T, *tuple[int, ...]]
    Alias[str]  # Simplifies to C[str, *tuple[int, ...]], because we didn't have to bind *tuple[int, ...] to do it
    1. Another edge case is that if neither side has any starred items we will always simplify (since this is the existing behavior in 3.10). This may raise an error if the number of subscripts on the right does not match the number of parameters on the left.

    Alright, so this is business as usual.

    1. If there's a single *Ts on the left but not on the right, we should be able to simplify, which again may raise an error if there are not enough values on the right, but if there are more than enough, the excess will be consumed by *Ts (in fact that's the only way *Ts is fed).

    So then:

    class C(Generic[*Ts]): ...
    Alias = C[T, *Ts]
    Alias[()]              # Raises error
    Alias[int]             # Simplifies to C[int, *Ts]
    Alias[int, str]        # Simplifies to C[int, str]
    Alias[int, str, bool]  # Simplifies to C[int, str, bool]

    Yup, seems straightforward.

    1. If there's a *Ts on the right but not on the left, we should _not_ simplify, since whatever we have on the left serves as a constraint for *Ts.

    Ok, so this is about the following situations:

    class C(Generic[*Ts]): ...
    Alias = C[T1, T2]
    Alias[*Ts]  # Does not simplify; stays C[T1, T2][*Ts]

    Yikes - in fact, this is actually super hairy; I hadn't thought about this edge case at all in the PEP.

    Agreed that it seems reasonable not to simplify here.

    E.g. tuple[int, int][*Ts] constrains *Ts to being (int, int).

    Was that a typo? Surely tuple[int, int][*Ts] isn't valid - since tuple[int, int] doesn't have any free parameters?

    1. If there's exactly one *Ts on the left and one on the right, we _might__ be able to simplify if the prefix and suffix of the __parameters__ match the prefix and suffix of the subscript on the right. E.g. C[int, T, *Ts, float][str, *Ts] can be simplified to C[int, str, *Ts, float]. OTOH C[int, T, *Ts, float][*Ts] cannot be simplified -- but we cannot flag it as an error either. Note that __parameters__ in this example is (T, Ts); we have to assume that typevartuples in __parameters__ are always used as *Ts (since the PEP recognizes no valid unstarred uses of Ts).

    Ok, this also makes sense.

    ---

    Still, though, doesn't the point that Serhiy brought up about __origin__, __parameters__ and __args__ still apply? In cases where we *don't* simplify, there'd still be the issue of what we'd set these things to be.

    This evening I'll also revisit the PRs adding tests for substitution to try and make them a comprehensive reference as to what's currently possible.

    @mrahtz
    Copy link
    Mannequin

    mrahtz mannequin commented Apr 5, 2022

    Ok, https://github.com/python/cpython/pull/32341/files is a reference of how the current implementation behaves. Fwiw, it *is* mostly correct - with a few minor tweaks it might be alright for at least the 3.11 release.

    In particular, instead of dealing with the thorny issue of what to do about splitting unpacked arbitrary-length tuples over multiple type variables - e.g. C[T, *Ts][*tuple[int, ...]] - instead either deciding to try and evaluate it properly and living with the complexity, or leaving it unsimplified and living with the __args__, __parameters__ and __origin__ problem - for now, we could just raise an exception for any substitutions which involve an unpacked arbitrary-length tuple, since I'd guess it's going to be an extremely rare use-case.

    @gvanrossum
    Copy link
    Member

    We need to move on this, because the outcome of this discussion is a release blocker for 3.11b1 -- the next release!

    @gvanrossum gvanrossum added release-blocker type-bug An unexpected behavior, bug, or error labels Apr 7, 2022
    @mrahtz
    Copy link
    Contributor

    mrahtz commented Apr 10, 2022

    Copying in correspondence by email while issues were being migrated:

    @mrahtz:

    (Temporarily moving this discussion to email, since my understanding is that the issue tracker will be down for ~24 hours while it's being migrated to GitHub, and it sounds like this might be getting urgent-ish.)

    [Guido]

    We need to move on this, because the outcome of this discussion is a release blocker for 3.11b1 -- the next release!

    Oh yikes, I didn't realise. To be clear, what's the timeframe? I see the release schedule for 3.11 says that 3.11b1 is scheduled for 2022-05-06. Is the point that we need to have this discussion resolved and all the implementation finished by? Or is the very fact that this discussion is still underway blocking other folks right now?

    (And for my general education: is the point of the remaining beta releases that they're supposed to be bugfix-only?)

    @JelleZijlstra:

    Oh yikes, I didn't realise. To be clear, what's the timeframe? I see the release schedule for 3.11 says that 3.11b1 is scheduled for 2022-05-06. Is the point that we need to have this discussion resolved and all the implementation finished by? Or is the very fact that this discussion is still underway blocking other folks right now?

    Yes, we should not be changing any features after the feature freeze in early May.

    (And for my general education: is the point of the remaining beta releases that they're supposed to be bugfix-only?)

    That's right. This should enable people to test without having to worry about new features.

    @mrahtz:

    Alright, by the power invested in me as lead author of the PEP, I say let's go with implementing full substitution support (or as close to full as we can reasonably get it).

    The reasoning is that a) I think we're closer to a working, consistent implementation with full substitution support compared to the "partially-evaluated substitution" approach; and b) Serhiy's point about what to do about args etc has got me worried; a "partially-evaluated substitution" would be a new kind of thing in the typing system, and I think it could easily have further implications we won't have time to discover/work through before 3.11b1. It's true that the logic will be a bit complicated, and that as Jelle says it could complicate implementation of future typing features, but I think the latter is partly an inevitable consequence of the fact that variadic generics simply are complicated, and overall I still think the tradeoff is worth it.

    So unless anyone has a reason to veto this, let's proceed as follows:

    1. Merge Serhiy's C code for substitution in bpo-43224: Implement substitution of unpacked TypeVarTuple in C #31828
    2. Discuss gh-87390: Add tests demonstrating current type variable substitution behaviour #32341 until we're happy with what we think the behaviour should be (there are still a few in there I'm not entirely sure about myself), and use that as a basis for fixing the remaining issues
    3. Reserve the right to raise NotImplementedError for the trickiest cases (e.g. splitting of *tuple[int, ...] across multiple type variables). Ideally it'd be nice to raise a message saying something like "If you think you need this, please leave a comment with your use case at " - is there any precedent for something like this being possible?

    @serhiy-storchaka:

    1. Discuss gh-87390: Add tests demonstrating current type variable substitution behaviour #32341 until we're happy with what we think the behaviour should be (there are still a few in there I'm not entirely sure about myself), and use that as a basis for fixing the remaining issues

    There were many changes in the code related to ParamSpec and Concatenate during the beta stage of 3.10 and even after the release. The current implementation of ParamSpec substitution is based on "analogies" and "reading between lines" rather of a concrete specification.

    1. Reserve the right to raise NotImplementedError for the trickiest cases (e.g. splitting of *tuple[int, ...] across multiple type variables). Ideally it'd be nice to raise a message saying something like "If you think you need this, please leave a comment with your use case at " - is there any precedent for something like this being possible?

    Callable[Concatenate[int, P], str][...] raises a type error because the result cannot be expressed in a form which would not contradict existing PEPs.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @gvanrossum
    Copy link
    Member

    I feel I need to add this same remark here:

    @mrahtz @JelleZijlstra @serhiy-storchaka Is it okay if I unsubscribe from these conversations and let you all come up with a compromise? I feel that while we ought to have a policy formulated and mostly implemented by beta 1 (May 6), tweaks of both the policy and the implementation during the beta period until RC 1 (Aug/Sept?) should be allowable.

    @mrahtz
    Copy link
    Contributor

    mrahtz commented Apr 15, 2022

    Ok, thinking about things more in #32341, I would propose the following spec:

    • In general, we aim to accurately evaluate type variable substitution, supporting as many valid aliases as we can.
    • Exception: if an unpacked arbitrary-length tuple (e.g. *tuple[int, ...]) is used in a generic alias type args list, then:
      • It must be the only type argument
        • Alias[str, *tuple[int, ...]] would not be valid
        • Alias[*tuple[int, ...], *tuple[str, ...]] would not be valid
        • Only Alias[*tuple[int, ...]] would be valid
      • The alias's sole type parameter must be an unpacked TypeVarTuple
        • Alias = tuple[T, *Ts]; Alias[*tuple[int, ...]] would not be valid
        • Alias = tuple[T1, T2]; Alias[*tuple[int, ...]] would not be valid
        • Only Alias = tuple[*Ts]; Alias[*tuple[int, ...]] would be valid

    @mrahtz
    Copy link
    Contributor

    mrahtz commented May 22, 2022

    [Guido]

    I feel that there's something missing from our notation, and that is how to indicate that the number of dimensions is Any (and shouldn't be complained about).

    Assuming that:

    DType = TypeVar('DType')
    Shape = TypeVarTuple('Shape')
    class ArrayShapeOnly(Generic[*Shape]): ...
    class ArrayDTypeAndShape(Generic[DType, *Shape]]): ...

    Doesn't ArrayShapeOnly[*tuple[SomeType, ...]] / ArrayDTypeAndShape[SomeDType, *tuple[SomeType, ...]] address this case?

    Or is your point that there should be some nicer syntax for specifying this? In practice, I'd expect most library authors to cater for this with an alias along the lines of:

    ArrayWithArbitraryNumDimensions = ArrayDTypeAndShape[DType, *tuple[Any, ...]]

    So maybe special syntax wouldn't be necessary?


    This same problem occurs for varargs functions, e.g. this is accepted:

    def f(a: int, *b: int) -> int: ...
    
    t: tuple[int, ...] = ()
    
    f(*t)  # OK in mypy, fails at runtime even though f(*()) is rejected.

    To check that I understand:

    • f(*t) fails at runtime, because there aren't enough elements in t to actually assign to a and b, but is ok in mypy, because mypy "tries to find a way to make it work" by assuming the arbitrary-length tuple is of the right size to proceed
    • f(*()) fails at runtime, but also in mypy, because here mypy doesn't have an arbitrary number of types to play with

    I might just be tired, but could you expand on the connection between this case and the "arbitrary number of dimensions" case?


    OT: While reading these deliberations, am beginning to find the notation Foo[A, *tuple[B, ...], C] pretty tedious. Maybe in a future PEP we can allow simplifying this to Foo[A, B, ..., C]? IIRC we never went there because we worried that there might be other interpretations (like B, ... might mean a B plus zero or more Anys, rather than zero or more Bs), but maybe we should just pick a meaning and stick to it. Users could also be confused by tuple[B, ...] but we've defined it and move on.

    I hear you that it's a bit of a tedious syntax. And yes, you're right - the reason I'm hesitant to use Foo[A, B, ..., C] is that I think we might want to make Foo[A, B, ..., C] mean "A, then B, then an arbitrary number of Any, then C". I continue to think the latter meaning would be much more useful for array typing purposes (and also more intuitive, but I appreciate that's subjective).

    But I don't think we should discuss it yet, because it's a decision that'll impact a lot of future users of array typing who don't exist yet and who therefore can't weigh in on the discussion. Ideally we'd talk about it once, say, NumPy has adopted PEP 646, and people have been using it for NumPy annotations for a good 6 months or so.

    @pradeep90
    Copy link
    Contributor

    [Pradeep]

    Lmk if that makes sense. I'm happy to hop on a VC call this week, if this is something you'd like to discuss further. Might be faster than waiting for each other's replies :)

    For this kind of thing, I think text works better for me - it's helpful to have time to think. Thanks for offering, though :)

    Fine by me!

    class Array(Generic[*Shape]): ...  # I'm including the definition of Array for completeness.
    
    
    y: Array[*Tuple[Any, ...]] = read_from_file()
    
    def expect_variadic_array(
        x: Array[Batch, *Shape]
    ) -> None: ...
    
    expect_variadic_array(y)  # OK

    Isn't Batch here a type, rather than a TypeVar?

    Batch is a TypeVar. The PEP text mentions that "Batch is bound to Any and Shape is bound to Tuple[Any, ...]". Maybe it should be called BatchVar to distinguish from the named dimension :|

    The idea I was getting across was that even if Array is only generic in *Shape, a function could expect y: Array[N1, N2, *Shape, N3]. Now, if someone passes y: Array to the function, we would need to split the unbounded tuple *tuple[Any, ...] across N1, N2, *Shape, N3. That would work.

    But if users tried to define a generic alias MyArray = Array[N1, N2, *Shape, N3] and tried to use y: MyArray[*tuple[Any, ...]], that would fail, even though it's the same splitting as above.

    That is why I was arguing against forbidding this. Since we agree on not forbidding this in the PEP, no worries.

    If the question is why would anyone specify MultiDeviceArray[*tuple[int, ...]] explicitly, we address that in the PEP:

    This allows users to handle dynamic code gracefully while still explicitly marking the code as unsafe (by using y: Array[*Tuple[Any, ...]]). Otherwise, users would face noisy errors from the type checker every time they tried to use the variable y, which would hinder them when migrating a legacy code base to use TypeVarTuple.
    Didn't we write that assuming that Array was generic in only a TypeVarTuple?
    In the case of MultiDeviceArray, if we wanted to explicitly mark it as unsafe, wouldn't we write something like MultiDeviceArray[tf.dtype, *tuple[int, ...]]?

    If we had an alias such as MyArray = Array[N1, N2, *Shape, N3], we would have to write MyArray[int, int, *tuple[int, ...], int] (as per the proposal in this thread). Otherwise, MyArray[*tuple[int, ...] would be a runtime error.

    So, yes, it is always feasible to add type arguments separately for each TypeVar in a generic alias. It would be a bad user experience to get a runtime error first, but I think it's reasonable to punt on the implementation for now.

    I favor option (1). Curious to hear your thoughts, since it's not clear which way you are leaning.

    Ah, sorry if I wasn't explicit enough on this earlier - yeah, for this case, I'm also on board with deferring its implementation at runtime until someone finds a use-case for it - both because it could take a while to implement and test, and because I think Jelle has a remit to try and keep complexity out of typing.py.

    I definitely agree it's not worth banning in the PEP.

    +1. Hope there's nothing else blocking this thread, then.

    @gvanrossum
    Copy link
    Member

    First responding to Pradeep: What does "punting on the implementation" mean in practice? Does it just mean that repr(MyArray[*tuple[int, ...]]) might be Array[N1, N2, *Shape, N3][*tuple[int, ...]] rather than Array[int, int, *tuple[int, ...], int]? If so, I am fine with that.

    Next to Matthew, in reverse order:

    (c) I will happily await discussing the semantics of A[T, ..., S] until there's actual experience with PEP 646 (i.e., well after 3.11 is released).

    (b) Yes, you understand my claim about f(*t) vs. f(*()). The reason I connect vararg variable substitutions with vararg function calls is that in both cases we have a single notation that means "arbitrary number" which is generally understood to mean "zero or more" but which is also acceptable in situations where the requirement is "N or more, for some N larger than zero". (We emphasize that an empty tuple is a valid match for tuple[int, ...].)

    (a) I would be happy with the syntax A[X, *tuple[X, ...]] to indicate "A with 1 or more X parameters". However, we accept some other type whose meaning is "A with 0 or more X parameters" as a valid substitution. So really it appears that as soon as we have a type whose parameter count has no upper bound, we appear to drop the lower bound -- we cannot distinguish between "count >= 0" and "count >= 1". I drew the analogy with function calls because they have the same issue and we seem to be fine with that.

    @pradeep90
    Copy link
    Contributor

    [Guido]

    First responding to Pradeep: What does "punting on the implementation" mean in practice? Does it just mean that repr(MyArray[*tuple[int, ...]]) might be Array[N1, N2, *Shape, N3][*tuple[int, ...]] rather than Array[int, int, *tuple[int, ...], int]? If so, I am fine with that.

    Right now, MyArray[*tuple[int, ...]] gives a runtime error. IIUC Matthew was suggesting that we leave it as such - giving a runtime error - until we get user requests for this form. The reasoning for deferring this was that this needs some more work to implement, and there exist long-form ways to represent the type MyArray[*tuple[int, ...]], i.e., Array[int, int, *tuple[int, ...], int].

    Will defer to Matthew in case he wants to clarify.

    @gvanrossum
    Copy link
    Member

    Leaving it a runtime error does go against the general trend to be more lenient at runtime than in the static checker, though. So if there's another approach that's not too much effort I'd rather not have the runtime error. If we leave it a runtime error in 3.11.0, could we fix it in 3.11.1, or would we have to wait until 3.12? If 3.11.1, that would be acceptable.

    @mrahtz
    Copy link
    Contributor

    mrahtz commented May 23, 2022

    Long thread is long

    The issue of tuple[T, *Ts][*tuple[int, ...]]

    [Pradeep]

    Isn't Batch here a type, rather than a TypeVar?

    Batch is a TypeVar. The PEP text mentions that "Batch is bound to Any and Shape is bound to Tuple[Any, ...]". Maybe it should be called BatchVar to distinguish from the named dimension :|

    Yeah, I was wondering about that. I think we made a typo. In the immediately preceding context, I'm pretty sure we were talking about a function that expected a shape beginning with the Batch type:

    def process_batch_channels(
        x: Array[Batch, *Tuple[Any, ...], Channels]
    ) -> None:
        ...
    
    x: Array[Batch, Height, Width, Channels]
    process_batch_channels(x)  # OK
    y: Array[Batch, Channels]
    process_batch_channels(y)  # OK
    z: Array[Batch]
    process_batch_channels(z)  # Error: Expected Channels.

    Thinking about it some more, I realise that in the example in question...

    y: Array[*Tuple[Any, ...]] = read_from_file()
    
    def expect_variadic_array(
        x: Array[Batch, *Shape]
    ) -> None: ...
    
    expect_variadic_array(y)  # OK

    ...you're right, in that even if we do assume Batch to be a type here, we do in some sense have to 'match up' the Batch with Any. But of course, this is a different thing from type substitution.

    So yeah, I think the current phrasing in the PEP is inaccurate:

    Array[*Tuple[Any, ...]] stands for an array with an arbitrary number of dimensions of type Any. This means that, in the call to expect_variadic_array, Batch is bound to Any and Shape is bound to Tuple[Any, ...]. In the call to expect_precise_array, the variables Batch, Height, Width, and Channels are all bound to Any.

    I think it should be something like:

    Array[*Tuple[Any, ...]] stands for an array with an arbitrary number of dimensions of type Any. This means that, in the call to expect_variadic_array, we're checking the Batch type for compatibility with Any, and binding Shape to Tuple[Any, ...]. In the call to expect_precise_array, we're similarly checking the Batch, Height, Width and Channels types for compatibility with Any.

    What do you reckon?


    [Pradeep]

    The idea I was getting across was that even if Array is only generic in *Shape, a function could expect y: Array[N1, N2, *Shape, N3]. Now, if someone passes y: Array to the function, we would need to split the unbounded tuple *tuple[Any, ...] across N1, N2, *Shape, N3. That would work.

    But if users tried to define a generic alias MyArray = Array[N1, N2, *Shape, N3] and tried to use y: MyArray[*tuple[Any, ...]], that would fail, even though it's the same splitting as above.

    To check whether I understand - I think we're talking about the following:

    Shape = TypeVarTuple('Ts')
    N1 = TypeVar('N1')
    N2 = TypeVar('N2')
    N3 = TypeVar('N3')
    
    class Array(Generic[*Shape]): ...
    
    def foo(y: Array[N1, N2, *Shape, N3]): ...
    
    y1: Array
    # This is fine conceptually, both because we've decreed that plain `Array`
    # should be backwards-compatible with `Array[anything]`, and because it's
    # the same as `Array[*tuple[Any, ...]]`, and we can happily assign `Any` to
    # `N1`, `N2` and `N3`, and `*tuple[Any, ...]` to `Shape`.
    # It's also fine in our current runtime implementation.
    foo(y1)
    
    y2: Array[*tuple[Any, ...]]
    # This is also fine conceptually, because it means the same thing as `y: Array`.
    # It's also fine in our current runtime implementation.
    foo(y2)
    
    MyArray = Array[N1, N2, *Shape, N3]
    # This is the same thing as what happens when we do foo(y2) -
    # in both cases, we're comparing `N1, N2, *Shape, N3` and `*tuple[Any, ...]` -
    # but this one won't work in our current runtime implementation.
    y3: MyArray[*tuple[Any, ...]]

    ...ok, this example has persuaded me. It's true that if a function which expects a generic type with type parameters N1, N2, *Shape, N3 can accept type arguments *Tuple[Any, ...], then a generic alias with type parameters N1, N2, *Shape, N3 should also be able to accept type arguments *Tuple[Any, ...]. The only reason the former works and not the latter in the runtime currently is that in the former case we don't actually need to compute the assignment of types to type parameters explicitly. They're both conceptually sound.

    So I'll work on getting my PR fixed up.

    The issue of tuple[T, *Ts][*tuple[int, ...], str]

    [Pradeep]

    IIUC Matthew was suggesting that we leave it as such - giving a runtime error - until we get user requests for this form. The reasoning for deferring this was that this needs some more work to implement, and there exist long-form ways to represent the type MyArray[*tuple[int, ...]], i.e., Array[int, int, *tuple[int, ...], int].

    Yeah, so I am suggesting that we leave tuple[T, *Ts][*tuple[int, ...], str] as a runtime error for now.

    [Guido]

    Leaving it a runtime error does go against the general trend to be more lenient at runtime than in the static checker, though. So if there's another approach that's not too much effort I'd rather not have the runtime error. If we leave it a runtime error in 3.11.0, could we fix it in 3.11.1, or would we have to wait until 3.12? If 3.11.1, that would be acceptable.

    I agree it's not ideal, but for this case specifically, I'm not sure there's a simple alternative. I don't think the idea of leaving it partially evaluated - such that tuple[T, *Ts][*tuple[int, ...], str] evaluated to tuple[T, *Ts][*tuple[int, ...], str] and nothing simpler - is possible, for reasons that Serhiy pointed out: what would __args__ and __params__ be in this case? What should things that rely on __args__ and __params__ (Serhiy mentioned dataclasses as one such example) do?

    I think we're pretty unlikely to see anyone do this though. It's a super weird thing to do. I wouldn't bet my life on it, but I'd be surprised.

    The issue of what ... should mean

    ...I'll reply to this one in the next few days :)

    @gvanrossum
    Copy link
    Member

    So yeah, I think the current phrasing in the PEP is inaccurate:

    Array[*Tuple[Any, ...]] stands for an array with an arbitrary number of dimensions of type Any. This means that, in the call to expect_variadic_array, Batch is bound to Any and Shape is bound to Tuple[Any, ...]. In the call to expect_precise_array, the variables Batch, Height, Width, and Channels are all bound to Any.

    I think it should be something like:

    Array[*Tuple[Any, ...]] stands for an array with an arbitrary number of dimensions of type Any. This means that, in the call to expect_variadic_array, we're checking the Batch type for compatibility with Any, and binding Shape to Tuple[Any, ...]. In the call to expect_precise_array, we're similarly checking the Batch, Height, Width and Channels types for compatibility with Any.

    What do you reckon?

    Agreed. Batch does not have to be a typevar here for the examples to clarify the issues.

    Regarding punting on the implementation, your proposal is to only punt on the case where there is an extra type (str in your example) in the actual parameters following *tuple[int, ...], right? I can live with that then, though if Serhiy manages to fix it I wouldn't stop him.

    @pradeep90
    Copy link
    Contributor

    ...ok, this example has persuaded me.

    🎉

    Batch is a TypeVar. The PEP text mentions that "Batch is bound to Any and Shape is bound to Tuple[Any, ...]". Maybe it should be called BatchVar to distinguish from the named dimension :|

    Yeah, I was wondering about that. I think we made a typo
    What do you reckon?

    Actually, I meant Batch to be a TypeVar in that example, precisely to demonstrate how unbounded tuples are split across TypeVars and TypeVarTuples. Otherwise, type checker implementers wouldn't have any code snippets showing what each variable is bound to in that use case, which is very common in Tensor code.

    The change would have to be making it BatchVar or just T.

    I'll put up a PR to clarify the code and wording (assuming it's ok to update the PEP, since this is an oversight in the naming).

    @mrahtz
    Copy link
    Contributor

    mrahtz commented May 28, 2022

    [Guido]

    (c) I will happily await discussing the semantics of A[T, ..., S] until there's actual experience with PEP 646 (i.e., well after 3.11 is released).

    Ok, great :)

    Lower bounds on the number of type arguments

    (b) Yes, you understand my claim about f(t) vs. f(()). The reason I connect vararg variable substitutions with vararg function calls is that in both cases we have a single notation that means "arbitrary number" which is generally understood to mean "zero or more" but which is also acceptable in situations where the requirement is "N or more, for some N larger than zero". (We emphasize that an empty tuple is a valid match for tuple[int, ...].)

    (a) I would be happy with the syntax A[X, *tuple[X, ...]] to indicate "A with 1 or more X parameters". However, we accept some other type whose meaning is "A with 0 or more X parameters" as a valid substitution. So really it appears that as soon as we have a type whose parameter count has no upper bound, we appear to drop the lower bound -- we cannot distinguish between "count >= 0" and "count >= 1". I drew the analogy with function calls because they have the same issue and we seem to be fine with that.

    Ok, so if I understand right, you're saying that, regarding whether we should allow...

    T = TypeVar('T')
    Shape = TypeVarTuple('Shape')
    
    class Array(Generic[*Shape]): ...
    def foo(x: Array[int, *tuple[int, ...]): ...
    
    x: Array[*tuple[int, ...]]
    foo(x)

    ...given that we're passing "Zero or more int" to something that seems to require "One or more int", you're arguing that it should be allowed, by analogy with the following, which is fine in mypy...

    def bar(a: int, *b: int): ...
    
    t: tuple[int, ...]
    
    foo(*t)

    ...and furthermore noting that, if we do allow this, one downside is that it prevents us from being able to properly enforce a lower bound of the number of type arguments in cases where we don't have an upper bound on the number of type arguments, like in foo above. Is that right?

    If so - hmm, interesting point. I agree the validity of the bar example suggests we should also be fine with corresponding foo example. But it hadn't occurred to me that this requires us to give up lower bound verification.

    I guess what that means for arrays is that we couldn't catch something like this:

    class Array(Generic[*Shape]): ...
    
    # Argument must have at least one dimension - scalar arrays like Array[()] not allowed!
    def only_accepts_arrays(x: Array[Any, *tuple[Any, ...]]): ...
    
    def returns_scalar_or_array() → Array[*tuple[Any, ...]]: ...
    
    x = returns_scalar_or_array()
    only_accepts_array(x)  # x might be Array[()], so this might not be ok!

    This is mildly annoying, but seems like an ok sacrifice to make in order to enable gradual typing - allowing Array == Array[*tuple[Any, ...]] to be a 'universal' array.

    What we're punting on

    Regarding punting on the implementation, your proposal is to only punt on the case where there is an extra type (str in your example) in the actual parameters following *tuple[int, ...], right? I can live with that then, though if Serhiy manages to fix it I wouldn't stop him.

    Close. There's a similar case where the unpacked arbitrary-length tuple lines up exactly with a TypeVarTuple and all other types line up exactly with TypeVars, which is easy to evaluate, and which the current runtime therefore evaluates fine:

    class Array(Generic[*Ts]): pass
    Alias = Array[*Ts, T]
    Alias[*tuple[int, ...], str]  # Evaluates to Array[*tuple[int, ...], str]

    So I think the actual logic would be something like:

    • If the type argument list consists of a single unpacked arbitrary-length tuple *tuple[int, ...], then we're fine.
    • Else if the type argument list "lines up exactly" with the type arguments - such that the type argument list is the same length as the type parameter list, and the TypeVarTuple in the type parameter list lines up with the unpacked arbitrary-length tuple in the type argument list (and there are no other unpacked arbitrary-length tuples in the type argument list), then we're fine.
    • Else, error.

    To put it concisely: we're punting on the case where it's a valid substitution, but the unpacked arbitrary-length tuple in the arguments doesn't line up with the TypeVarTuple in the parameters.

    @mrahtz
    Copy link
    Contributor

    mrahtz commented May 28, 2022

    [Pradeep]

    Actually, I meant Batch to be a TypeVar in that example, precisely to demonstrate how unbounded tuples are split across TypeVars and TypeVarTuples. Otherwise, type checker implementers wouldn't have any code snippets showing what each variable is bound to in that use case, which is very common in Tensor code.

    Oh! Sorry, I didn't realise you intended Batch to be a TypeVar here. Ok, a PR clarifying this sounds good :)

    @gvanrossum
    Copy link
    Member

    gvanrossum commented May 28, 2022 via email

    serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this issue May 29, 2022
    …able-size tuple
    
    For example:
    
      A[T, *Ts][*tuple[int, ...]] -> A[int, *tuple[int, ...]]
      A[*Ts, T][*tuple[int, ...]] -> A[*tuple[int, ...], int]
    @serhiy-storchaka
    Copy link
    Member

    I have wrote the Python implementation and now working on the C code. Please look whether the Python implementation works as you expect.

    For simplicity, it forbids substitution of multiple unpacked var-tuples, e.g. A[*Ts][*tuple[int, ...], *tuple[str, ...]]. It was forbidden by PEP 646, but accepted at runtime for simplicity. I can allow this again, but it will make the code slightly more complicated.

    @serhiy-storchaka
    Copy link
    Member

    The following examples now work:

    A[T, *Ts][*tuple[int, ...]] -> A[int, *tuple[int, ...]]
    A[*Ts, T][*tuple[int, ...]] -> A[*tuple[int, ...], int]
    A[T, str, *Ts][*tuple[int, ...]] -> A[int, str, *tuple[int, ...]]
    A[*Ts, str, T][*tuple[int, ...]] -> A[*tuple[int, ...], str, int]
    A[list[T], *Ts][*tuple[int, ...]] -> A[list[int], *tuple[int, ...]]
    A[*Ts, list[T]][*tuple[int, ...]] -> A[*tuple[int, ...], list[int]]
    

    @mrahtz
    Copy link
    Contributor

    mrahtz commented May 29, 2022

    Oh no :( I already did a bunch of work on the Python side of this yesterday in #93318. I'm upset that I wasted a Saturday on this. Please check more carefully next time whether someone else is already working on it before starting.

    Edit: ah, sorry, I thought you'd merged it already - I didn't realise it was a WIP PR. Still, unfortunate that we ended up duplicating each other's work here :(

    But yes, the behaviour looks correct. And thanks for implementing the C version. I also looked at this yesterday but got a bit lost, so I appreciate you taking care of it.

    @serhiy-storchaka
    Copy link
    Member

    I am sorry. I promised to work on it almost a month ago, but I only had the time and inspiration to do it last weekend. GitHub does not send notifications about the linked PRs by email, so I was unaware of your work.

    #93330 is now ready for review. I have also another, simpler, version, which moves a lot of the C code to Python, but I need more time to polish it.

    pablogsal pushed a commit to miss-islington/cpython that referenced this issue May 31, 2022
    pablogsal added a commit that referenced this issue Jun 1, 2022
    …es (GH-92335) (#92484)
    
    * gh-91162: Fix substitution of unpacked tuples in generic aliases (GH-92335)
    (cherry picked from commit 9d25db9)
    
    Co-authored-by: Serhiy Storchaka <[email protected]>
    
    * Regenerate ABI file
    
    Co-authored-by: Serhiy Storchaka <[email protected]>
    Co-authored-by: Pablo Galindo <[email protected]>
    @serhiy-storchaka
    Copy link
    Member

    #93412 is an alternative implementation which does complex things in Python and calls the Python code from C. Seems it can also simplify the code of collections.abc.Callable (because the code is more generic now), but I left a clean up to a separate PR.

    @mrahtz
    Copy link
    Contributor

    mrahtz commented Jun 1, 2022

    I am sorry. I promised to work on it almost a month ago, but I only had the time and inspiration to do it last weekend. GitHub does not send notifications about the linked PRs by email, so I was unaware of your work.

    Oh, fair enough. In that case I'll just say: thank you for your continued work on this :)

    serhiy-storchaka added a commit that referenced this issue Jun 12, 2022
    …ypeVar and TypeVarTuple parameters (alt) (GH-93412)
    
    For example:
    
      A[T, *Ts][*tuple[int, ...]] -> A[int, *tuple[int, ...]]
      A[*Ts, T][*tuple[int, ...]] -> A[*tuple[int, ...], int]
    miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 12, 2022
    …over TypeVar and TypeVarTuple parameters (alt) (pythonGH-93412)
    
    For example:
    
      A[T, *Ts][*tuple[int, ...]] -> A[int, *tuple[int, ...]]
      A[*Ts, T][*tuple[int, ...]] -> A[*tuple[int, ...], int]
    (cherry picked from commit 3473817)
    
    Co-authored-by: Serhiy Storchaka <[email protected]>
    serhiy-storchaka added a commit that referenced this issue Jun 14, 2022
    … over TypeVar and TypeVarTuple parameters (alt) (GH-93412) (GH-93746)
    
    For example:
    
      A[T, *Ts][*tuple[int, ...]] -> A[int, *tuple[int, ...]]
      A[*Ts, T][*tuple[int, ...]] -> A[*tuple[int, ...], int]
    (cherry picked from commit 3473817)
    
    Co-authored-by: Serhiy Storchaka <[email protected]>
    serhiy-storchaka added a commit that referenced this issue Jun 26, 2022
    * GH-93444: remove redundant fields from basicblock: b_nofallthrough, b_exit, b_return (GH-93445)
    
    * netrc: Remove unused "import shlex" (#93311)
    
    * gh-92886: Fix test that fails when running with `-O` in `test_imaplib.py` (#93237)
    
    * Fix missing word in sys.float_info docstring (GH-93489)
    
    * [doc] Correct a grammatical error in a docstring. (GH-93441)
    
    * gh-93442: Make C++ version of _Py_CAST work with 0/NULL. (#93500)
    
    Add C++ overloads for _Py_CAST_impl() to handle 0/NULL.  This will allow
    C++ extensions that pass 0 or NULL to macros using _Py_CAST() to
    continue to compile.  Without this, you get an error like:
    
        invalid ‘static_cast’ from type ‘int’ to type ‘_object*’
    
    The modern way to use a NULL value in C++ is to use nullptr.  However,
    we want to not break extensions that do things the old way.
    
    Co-authored-by: serge-sans-paille
    
    * gh-93442: Add test for _Py_CAST(nullptr). (gh-93505)
    
    * gh-90473: wasmtime does not support absolute symlinks (GH-93490)
    
    * gh-89973: Fix re.error in the fnmatch module. (GH-93072)
    
    Character ranges with upper bound less that lower bound (e.g. [c-a])
    are now interpreted as empty ranges, for compatibility with other glob
    pattern implementations. Previously it was re.error.
    
    * Document LOAD_FAST_CHECK opcode (#93498)
    
    * gh-93247: Fix assert function in asyncio locks test (#93248)
    
    * gh-90473: WASI requires proper open(2) flags (GH-93529)
    
    * GH-92308 What's New: list pending removals in 3.13 and future versions (#92562)
    
    * gh-90473: Skip POSIX tests that don't apply to WASI (GH-93536)
    
    * asyncio.Barrier docs: Fix typo (#93371)
    
    taks -> tasks
    
    * gh-83728: Add hmac.new default parameter deprecation (GH-91939)
    
    * gh-90473: Make chmod a dummy on WASI, skip chmod tests (GH-93534)
    
    WASI does not have the ``chmod(2)`` syscall yet.
    
    * Remove action=None kwarg from Barrier docs (GH-93538)
    
    * [docs] fix some asyncio.Barrier.wait docs grammar (GH-93552)
    
    * gh-93475: Expose FICLONE and FICLONERANGE constants in fcntl (#93478)
    
    * gh-89018: Improve documentation of `sqlite3` exceptions (#27645)
    
    - Order exceptions as in PEP 249
    - Reword descriptions, so they match the current behaviour
    
    Co-authored-by: Alex Waygood <[email protected]>
    
    * bpo-42658: Use LCMapStringEx in ntpath.normcase to match OS behaviour for case-folding (GH-32010)
    
    * Fix contributor name in WhatsNew 3.11 (GH-93556)
    
    * Grammar fix to socket error string (GH-93523)
    
    * gh-86986: bump min sphinx version to 3.2 (GH-93337)
    
    * gh-79096: Protect cookie file created by {LWP,Mozilla}CookieJar.save() (GH-93463)
    
    Note: This change is not effective on Microsoft Windows.
    
    Cookies can store sensitive information and should therefore be protected
    against unauthorized third parties. This is also described in issue #79096.
    
    The filesystem permissions are currently set to 644, everyone can read the
    file. This commit changes the permissions to 600, only the creater of the file
    can read and modify it. This improves security, because it reduces the attack
    surface. Now the attacker needs control of the user that created the cookie or
    a ways to circumvent the filesystems permissions.
    
    This change is backwards incompatible. Systems that rely on world-readable
    cookies will breake. However, one could argue that those are misconfigured in
    the first place.
    
    * gh-93162: Add ability to configure QueueHandler/QueueListener together (GH-93269)
    
    Also, provide getHandlerByName() and getHandlerNames() APIs.
    
    Closes #93162.
    
    * gh-57539: Increase calendar test coverage (GH-93468)
    
    Co-authored-by: Sean Fleming
    Co-authored-by: Adam Turner <[email protected]>
    Co-authored-by: Łukasz Langa <[email protected]>
    
    * gh-88831: In docs for asyncio.create_task, explain why strong references to tasks are needed (GH-93258)
    
    Co-authored-by: Łukasz Langa <[email protected]>
    
    * Shrink the LOAD_METHOD cache by one codeunit. (#93537)
    
    * Fix MSVC compiler warnings in ceval.c (#93569)
    
    * gh-93162: test_config_queue_handler requires threading (GH-93572)
    
    * gh-84461: Emscripten's faccessat() does not accept flags (GHß92353)
    
    * gh-92592: Allow logging filters to return a LogRecord. (GH-92591)
    
    * Fix `PurePath.relative_to` links in the pathlib documentation. (GH-93268)
    
    These are currently broken as they refer to :meth:`Path.relative_to` rather than :meth:`PurePath.relative_to`, and `relative_to` is a method on `PurePath`.
    
    * GH-93481: Suppress expected deprecation warning in test_pyclbr (GH-93483)
    
    * gh-93370: Deprecate sqlite3.version and sqlite3.version_info (#93482)
    
    Co-authored-by: Alex Waygood <[email protected]>
    Co-authored-by: Adam Turner <[email protected]>
    Co-authored-by: Erlend E. Aasland <[email protected]>
    
    * GH-93521: For dataclasses, filter out `__weakref__` slot if present in bases (GH-93535)
    
    * gh-93421: Update sqlite3 cursor.rowcount only after SQLITE_DONE (#93526)
    
    * gh-93584: Make all install+tests targets depends on all (GH-93589)
    
    All install targets use the "all" target as synchronization point to
    prevent race conditions with PGO builds. PGO builds use recursive make,
    which can lead to two parallel `./python setup.py build` processes that
    step on each others toes.
    
    "test" targets now correctly compile PGO build in a clean repo.
    
    * gh-87961: Remove outdated notes from functions that aren't in the Limited API (GH-93581)
    
    * Remove outdated notes from functions that aren't in the Limited API
    
    Nowadays everything that *is* in the Limited API has a note added
    automatically.
    These notes could mislead people to think that these functions
    could never be added to the limited API. Remove them.
    
    * Also remove forgotten note on tp_vectorcall_offset not being finalized
    
    * gh-93180: Update os.copy_file_range() documentation (#93182)
    
    * gh-93575: Use correct way to calculate PyUnicode struct sizes (GH-93602)
    
    * gh-93575: Use correct way to calculate PyUnicode struct sizes
    
    * Add comment to keep test_sys and test_unicode in sync
    
    * Fix case code < 256
    
    * gh-90473: Define HOSTRUNNER for WASI (GH-93606)
    
    * gh-79096: Fix/improve http cookiejar tests (GH-93614)
    
    Fixup of GH-93463:
    - remove stray print
    - use proper way to check file mode
    - add working chmod decorator
    
    Co-authored-by: Łukasz Langa <[email protected]>
    
    * gh-93616: Fix env changed issue in test_modulefinder (GH-93617)
    
    * gh-90494: Reject 6th element of the __reduce__() tuple (GH-93609)
    
    copy.copy() and copy.deepcopy() now always raise a TypeError if
    __reduce__() returns a tuple with length 6 instead of silently ignore
    the 6th item or produce incorrect result.
    
    * Doc: Update references and examples of old, unsupported OSes and uarches (GH-92791)
    
    * bpo-45383: Get metaclass from bases in PyType_From* (GH-28748)
    
    This checks the bases of of a type created using the FromSpec
    API to inherit the bases metaclasses.  The metaclass's alloc
    function will be called as is done in `tp_new` for classes
    created in Python.
    
    Co-authored-by: Petr Viktorin <[email protected]>
    Co-authored-by: Erlend Egeberg Aasland <[email protected]>
    
    * Improve logging documentation with example and additional cookbook re… (GH-93644)
    
    * gh-90473: disable user site packages on WASI/Emscripten (GH-93633)
    
    * gh-90473: Skip get_config_h() tests on WASI (GH-93645)
    
    * gh-90549: Fix leak of global named resources using multiprocessing spawn (#30617)
    
    Co-authored-by: XD Trol <[email protected]>
    Co-authored-by: Antoine Pitrou <[email protected]>
    
    * gh-92434: Silence compiler warning in Modules/_sqlite/connection.c on 32-bit systems (#93090)
    
    * gh-90763: Modernise xx template module initialisation (#93078)
    
    Use C APIs such as PyModule_AddType instead of PyModule_AddObject.
    Also remove incorrect module decrefs if module fails to initialise.
    
    * gh-93491: Add support tier detection to configure (GH-93492)
    
    Co-authored-by: Adam Turner <[email protected]>
    Co-authored-by: Steve Dower <[email protected]>
    Co-authored-by: Erlend Egeberg Aasland <[email protected]>
    
    * gh-93466: Document PyType_Spec doesn't accept repeated slot IDs; raise where this was problematic (GH-93471)
    
    * gh-93671: Avoid exponential backtracking in deeply nested sequence patterns in match statements (GH-93680)
    
    Co-authored-by: Łukasz Langa <[email protected]>
    
    * gh-81790: support "UNC" device paths in `ntpath.splitdrive()` (GH-91882)
    
    * GH-93621: reorder code in with/async-with exception exit path to reduce the size of the exception table (GH-93622)
    
    * gh-93461: Invalidate sys.path_importer_cache entries with relative paths (GH-93653)
    
    * gh-91317: Document that Path does not collapse initial `//` (GH-32193)
    
    
    
    Documentation for `pathlib` says:
    
    > Spurious slashes and single dots are collapsed, but double dots ('..') are not, since this would change the meaning of a path in the face of symbolic links:
    
    However, it omits that initial double slashes also aren't collapsed.
    
    Later, in documentation of `PurePath.drive`, `PurePath.root`, and `PurePath.name` it mentions UNC but:
    
    - this abbreviation says nothing to a person who is unaware about existence of UNC (Wikipedia doesn't help either by [giving a disambiguation page](https://en.wikipedia.org/wiki/UNC))
    - it shows up only if a person needs to use a specific property or decides to fully learn what the module provides.
    
    For context, see the BPO entry.
    
    * gh-92886: Fix tests that fail when running with optimizations (`-O`) in `test_zipimport.py` (GH-93236)
    
    * gh-92930: _pickle.c: Acquire strong references before calling save() (GH-92931)
    
    * gh-84461: Use HOSTRUNNER to run regression tests (GH-93694)
    
    Co-authored-by: Brett Cannon <[email protected]>
    
    * gh-90473: Skip test_queue when threading is not available (GH-93712)
    
    * gh-90153:  whatsnew: "z" option in format spec (GH-93624)
    
    Add what's new entry for PEP 682 in Python 3.11.
    
    * gh-86404: [doc] A make sucpicious false positive. (GH-93710)
    
    * Change list to view object (#93661)
    
    * gh-84508: tool to generate cjk traditional chinese mappings (gh-93272)
    
    * Remove usage of _Py_IDENTIFIER from math module (#93739)
    
    * gh-91162: Support splitting of unpacked arbitrary-length tuple over TypeVar and TypeVarTuple parameters (alt) (GH-93412)
    
    For example:
    
      A[T, *Ts][*tuple[int, ...]] -> A[int, *tuple[int, ...]]
      A[*Ts, T][*tuple[int, ...]] -> A[*tuple[int, ...], int]
    
    * gh-93728: fix memory leak in deepfrozen code objects (GH-93729)
    
    * gh-93747: Fix Refleak when handling multiple Py_tp_doc slots (gh-93749)
    
    * GH-90699: use statically allocated strings in typeobject.c (gh-93751)
    
    * Add more FOR_ITER specialization stats (GH-32151)
    
    * gh-89653: PEP 670: Convert PyFunction macros (#93765)
    
    Convert PyFunction macros to static inline functions.
    
    * Remove ANY_VARARGS() macro from the C API (#93764)
    
    The macro was exposed by mistake.
    
    * gh-84623: Remove unused imports in stdlib (#93773)
    
    * gh-91731: Don't define 'static_assert' in C++11 where is a keyword to avoid UB (GH-93700)
    
    * gh-84623: Remove unused imports in tests (#93772)
    
    * gh-93353: Fix importlib.resources._tempfile() finalizer (#93377)
    
    Fix the importlib.resources.as_file() context manager to remove the
    temporary file if destroyed late during Python finalization: keep a
    local reference to the os.remove() function. Patch by Victor Stinner.
    
    * gh-84461: Fix parallel testing on WebAssembly (GH-93768)
    
    * gh-89653: PEP 670: Macros always cast arguments in cpython/ (#93766)
    
    Header files in the Include/cpython/ are only included if
    the Py_LIMITED_API macro is not defined.
    
    * gh-93353: Add test.support.late_deletion() (#93774)
    
    * gh-93741: Add private C API _PyImport_GetModuleAttrString() (GH-93742)
    
    It combines PyImport_ImportModule() and PyObject_GetAttrString()
    and saves 4-6 lines of code on every use.
    
    Add also _PyImport_GetModuleAttr() which takes Python strings as arguments.
    
    * gh-79512: Fixed names and __module__ value of weakref classes (GH-93719)
    
    Classes ReferenceType, ProxyType and CallableProxyType have now correct
    atrtributes __module__, __name__ and __qualname__.
    It makes them (types, not instances) pickleable.
    
    * gh-91810: Fix regression with writing an XML declaration with encoding='unicode' (GH-93426)
    
    Suppress writing an XML declaration in open files in ElementTree.write()
    with encoding='unicode' and xml_declaration=None.
    
    If file patch is passed to ElementTree.write() with encoding='unicode',
    always open a new file in UTF-8.
    
    * gh-93761: Fix test to avoid simple delay when synchronizing. (GH-93779)
    
    * gh-89546: Clean up PyType_FromMetaclass (GH-93686)
    
    
    
    When changing PyType_FromMetaclass recently (GH-93012, GH-93466, GH-28748)
    I found a bunch of opportunities to improve the code. Here they are.
    
    Fixes: #89546
    
    Automerge-Triggered-By: GH:encukou
    
    * gh-91321: Fix compatibility with C++ older than C++11 (#93784)
    
    Fix the compatibility of the Python C API with C++ older than C++11.
    
    _Py_NULL is only defined as nullptr on C++11 and newer.
    
    * GH-93662: Make sure that column offsets are correct in multi-line method calls. (GH-93673)
    
    * GH-93516: Store offset of first traceable instruction in code object (GH-93769)
    
    * gh-90473: Include stdlib dir in wasmtime PYTHONPATH (GH-93797)
    
    * GH-93429: Merge `LOAD_METHOD` back into `LOAD_ATTR` (GH-93430)
    
    * gh-93353: regrtest checks for leaked temporary files (#93776)
    
    When running tests with -jN, create a temporary directory per process
    and mark a test as "environment changed" if a test leaks a temporary
    file or directory.
    
    * gh-79579: Improve DML query detection in sqlite3 (#93623)
    
    The fix involves using pysqlite_check_remaining_sql(), not only to check
    for multiple statements, but now also to strip leading comments and
    whitespace from SQL statements, so we can improve DML query detection.
    
    pysqlite_check_remaining_sql() is renamed lstrip_sql(), to more
    accurately reflect its function, and hardened to handle more SQL comment
    corner cases.
    
    * GH-93678: reduce boilerplate and code repetition in the compiler (GH-93682)
    
    * gh-91877: Fix WriteTransport.get_write_buffer_{limits,size} docs (#92338)
    
    - Amend docs for WriteTransport.get_write_buffer_limits
    - Add docs for WriteTransport.get_write_buffer_size
    
    * GH-93429: Document `LOAD_METHOD` removal (GH-93803)
    
    * Include freelists in allocation total. (GH-93799)
    
    * gh-93795: Use test.support TESTFN/unlink in sqlite3 tests (#93796)
    
    * Remove LOAD_METHOD stats. (GH-93807)
    
    * Rename 'LOAD_METHOD' specialization stat consts to 'ATTR'. (GH-93812)
    
    * gh-93353: Fix regrtest for -jN with N >= 2 (GH-93813)
    
    * [docs] Fix LOAD_ATTR version changed (GH-93816)
    
    * gh-93814: Add infinite test for itertools.chain.from_iterable (GH-93815)
    
    
    
    fix #93814
    
    Automerge-Triggered-By: GH:rhettinger
    
    * gh-93735: Split Docs CI to speed-up the build (GH-93736)
    
    * gh-93183: Adjust wording in socket docs (#93832)
    
    package => packet
    
    Co-authored-by: Victor Norman
    
    * gh-93829: In sqlite3, replace Py_BuildValue with faster APIs (#93830)
    
    - In Modules/_sqlite/connection.c, use PyLong_FromLong
    - In Modules/_sqlite/microprotocols.c, use PyTuple_Pack
    
    * Add test.support.busy_retry() (#93770)
    
    Add busy_retry() and sleeping_retry() functions to test.support.
    
    * gh-87260: Update sqlite3 signature docs to reflect actual implementation (#93840)
    
    Align the docs for the following methods with the actual implementation:
    
    - sqlite3.complete_statement()
    - sqlite3.Connection.create_function()
    - sqlite3.Connection.create_aggregate()
    - sqlite3.Connection.set_progress_handler()
    
    * test_thread uses support.sleeping_retry() (#93849)
    
    test_thread.test_count() now fails if it takes longer than
    LONG_TIMEOUT seconds.
    
    * Use support.sleeping_retry() and support.busy_retry() (#93848)
    
    * Replace time.sleep(0.010) with sleeping_retry() to
      use an exponential sleep.
    * support.wait_process(): reuse sleeping_retry().
    * _test_eintr: remove unused variables.
    
    * Update includes in call.c (GH-93786)
    
    * gh-93857: Fix broken audit-event targets in sqlite3 docs (#93859)
    
    Corrected targets for the following audit-events:
    
    - sqlite3.enable_load_extension => sqlite3.Connection.enable_load_extension
    - sqlite3.load_extension => sqlite3.Connection.load_extension
    
    * GH-93850: Fix test_asyncio exception ignored tracebacks (#93854)
    
    * gh-93824: Reenable installation of shell extension on Windows ARM64 (GH-93825)
    
    * test_asyncio: run_until() implements exponential sleep (#93866)
    
    run_until() of test.test_asyncio.utils now uses an exponential sleep
    delay (max: 1 second), rather than a fixed delay of 1 ms. Similar
    design than support.sleeping_retry() wait strategy that applies
    exponential backoff.
    
    * test_asyncore: Optimize capture_server() (#93867)
    
    Remove time.sleep(0.01) in test_asyncore capture_server(). The sleep
    was redundant and inefficient, since the loop starts with
    select.select() which also implements a sleep (poll for socket data
    with a timeout).
    
    * Tests call sleeping_retry() with SHORT_TIMEOUT (#93870)
    
    Tests now call busy_retry() and sleeping_retry() with SHORT_TIMEOUT
    or LONG_TIMEOUT (of test.support), rather than hardcoded constants.
    
    Add also WAIT_ACTIVE_CHILDREN_TIMEOUT constant to
    _test_multiprocessing.
    
    * gh-84461: Document how to install SDKs manually (GH-93844)
    
    Co-authored-by: Brett Cannon <[email protected]>
    
    * gh-93820: Fix copy() regression in enum.Flag (GH-93876)
    
    
    
    GH-26658 introduced a regression in copy / pickle protocol for combined
    `enum.Flag`s. `copy.copy(re.A | re.I)` would fail with
    `AttributeError: ASCII|IGNORECASE`.
    
    `enum.Flag` now has a `__reduce_ex__()` method that reduces flags by
    combined value, not by combined name.
    
    * Call busy_retry() and sleeping_retry() with error=True (#93871)
    
    Tests no longer call busy_retry() and sleeping_retry() with
    error=False: raise an exception if the loop times out.
    
    * gh-87347: Add parenthesis around PyXXX_Check() arguments (#92815)
    
    * gh-91321: Fix test_cppext for C++03 (#93902)
    
    Don't build _testcppext.cpp with -Wzero-as-null-pointer-constant when
    testing C++03: only use this compiler flag with C++11.
    
    * gh-91577: SharedMemory move imports out of methods (#91579)
    
    SharedMemory.unlink() uses the unregister() function from resource_tracker. Previously it was imported in the method, but this can fail if the method is called during interpreter shutdown, for example when unlink is part of a __del__() method.
    
    Moving the import to the top of the file, means that the unregister() method is available during interpreter shutdown.
    
    The register call in SharedMemory.__init__() can also use this imported resource_tracker.
    
    * gh-92547: Amend What's New (#93872)
    
    * Fix BINARY_SUBSCR_GETITEM stats (GH-93903)
    
    * gh-93847: Fix repr of enum of generic aliases (GH-93885)
    
    * gh-93353: regrtest supports checking tmp files with -j2 (#93909)
    
    regrtest now also implements checking for leaked temporary files and
    directories when using -jN for N >= 2. Use tempfile.mkdtemp() to
    create the temporary directory. Skip this check on WASI.
    
    * GH-91389: Fix dis position information for CACHEs (GH-93663)
    
    * gh-91985: Ensure in-tree builds override platstdlib_dir in every path calculation (GH-93641)
    
    * GH-83658: make multiprocessing.Pool raise an exception if maxtasksperchild is not None or a positive int (GH-93364)
    
    
    
    Closes #83658.
    
    * test_logging: Fix BytesWarning in SysLogHandlerTest (GH-93920)
    
    * gh-91404: Revert "bpo-23689: re module, fix memory leak when a match is terminated by a signal or allocation failure (GH-32283) (#93882)
    
    Revert "bpo-23689: re module, fix memory leak when a match is terminated by a signal or memory allocation failure (GH-32283)"
    
    This reverts commit 6e3eee5.
    
    Manual fixups to increase the MAGIC number and to handle conflicts with
    a couple of changes that landed after that.
    
    Thanks for reviews by Ma Lin and Serhiy Storchaka.
    
    * gh-89745: Avoid exact match when comparing program_name in test_embed on Windows (GH-93888)
    
    * gh-93852: Add test.support.create_unix_domain_name() (#93914)
    
    test_asyncio, test_logging, test_socket and test_socketserver now
    create AF_UNIX domains in the current directory to no longer fail
    with OSError("AF_UNIX path too long") if the temporary directory (the
    TMPDIR environment variable) is too long.
    
    Modify the following tests to use create_unix_domain_name():
    
    * test_asyncio
    * test_logging
    * test_socket
    * test_socketserver
    
    test_asyncio.utils: remove unused time import.
    
    * gh-77782: Py_FdIsInteractive() now uses PyConfig.interactive (#93916)
    
    * gh-74953: Add _PyTime_FromMicrosecondsClamp() function (#93942)
    
    * gh-74953: Fix PyThread_acquire_lock_timed() code recomputing the timeout (#93941)
    
    Set timeout, don't create a local variable with the same name.
    
    * gh-77782: Deprecate global configuration variable (#93943)
    
    Deprecate global configuration variable like
    Py_IgnoreEnvironmentFlag: the Py_InitializeFromConfig() API should be
    instead.
    
    Fix declaration of Py_GETENV(): use PyAPI_FUNC(), not PyAPI_DATA().
    
    * gh-93911: Specialize `LOAD_ATTR_PROPERTY` (GH-93912)
    
    * gh-92888: Fix memoryview bad `__index__` use after free (GH-92946)
    
    Co-authored-by: chilaxan <[email protected]>
    Co-authored-by: Serhiy Storchaka <[email protected]>
    
    * GH-89858: Fix test_embed for out-of-tree builds (GH-93465)
    
    * gh-92611: Add details on replacements for cgi utility funcs (GH-92792)
    
    
    
    Per @brettcannon 's [suggestions on the Discourse thread](https://discuss.python.org/t/pep-594-take-2-removing-dead-batteries-from-the-standard-library/13508/51), discussed in #92611 and as a followup to PR #92612 , this PR add additional specific per-function replacement information for the utility functions in the `cgi` module deprecated by PEP 594 (PEP-594).
    
    @brettcannon , should this be backported (without the `deprecated-removed` , which I would update it accordingly and re-add in my other PR adding that to the others for 3.11+), or just go in 3.11+?
    
    * GH-77403: Fix tests which fail when PYTHONUSERBASE is not normalized (GH-93917)
    
    * gh-91387: Strip trailing slash from tarfile longname directories (GH-32423)
    
    Co-authored-by: Brett Cannon <[email protected]>
    
    * Add jaraco as primary owner of importlib.metadata and importlib.resources. (#93960)
    
    * Add jaraco as primary owner of importlib.metadata and importlib.resources.
    
    * Align indentation.
    
    Co-authored-by: Ezio Melotti <[email protected]>
    
    Co-authored-by: Ezio Melotti <[email protected]>
    
    * gh-84461: Fix circulare dependency on BUILDPYTHON (GH-93977)
    
    * gh-89828: Do not relay the __class__ attribute in GenericAlias (#93754)
    
    list[int].__class__ returned type, and isinstance(list[int], type)
    returned True. It caused numerous problems in code that checks
    isinstance(x, type).
    
    * gh-84461: Fix pydebug Emscripten browser builds (GH-93982)
    
    wasm_assets script did not take the ABIFLAG flag of sysconfigdata into
    account.
    
    * gh-93955: Use unbound methods for slot `__getattr__` and `__getattribute__` (GH-93956)
    
    * gh-91387: Fix tarfile test on WASI (GH-93984)
    
    WASI's rmdir() syscall does not like the trailing slash.
    
    * gh-93975: Nicer error reporting in test_venv (GH-93959)
    
    
    
    - gh-93957: Provide nicer error reporting from subprocesses in test_venv.EnsurePipTest.test_with_pip.
    - Update changelog
    
    This change does three things:
    
    1. Extract a function for trapping output in subprocesses.
    2. Emit both stdout and stderr when encountering an error.
    3. Apply the change to `ensurepip._uninstall` check.
    
    * GH-93990: fix refcounting bug in `add_subclass` in `typeobject.c` (GH-93989)
    
    * What's new in 3.10: fix link to issue (#93968)
    
    * What's new in 3.10: fix link to issue
    
    * What's new in 3.10: fix link to GH issue
    
    Co-authored-by: Ezio Melotti <[email protected]>
    
    Co-authored-by: Ezio Melotti <[email protected]>
    
    * gh-93761: Fix test_logging test_config_queue_handler() race condition (#93952)
    
    Fix a race condition in test_config_queue_handler() of test_logging.
    
    * gh-74953: Reformat PyThread_acquire_lock_timed() (#93947)
    
    Reformat the pthread implementation of PyThread_acquire_lock_timed()
    using a mutex and a conditioinal variable.
    
    * Add goto to avoid multiple indentation levels and exit quickly
    * Use "while(1)" and make the control flow more obvious.
    * PEP 7: Add braces around if blocks.
    
    * gh-93937, C API: Move PyFrame_GetBack() to Python.h (#93938)
    
    Move the follow functions and type from frameobject.h to pyframe.h,
    so the standard <Python.h> provide frame getter functions:
    
    * PyFrame_Check()
    * PyFrame_GetBack()
    * PyFrame_GetBuiltins()
    * PyFrame_GetGenerator()
    * PyFrame_GetGlobals()
    * PyFrame_GetLasti()
    * PyFrame_GetLocals()
    * PyFrame_Type
    
    Remove #include "frameobject.h" from many C files. It's no longer
    needed.
    
    * gh-93991: Use boolean instead of 0/1 for condition check (GH-93992)
    
    
    
    # gh-93991: Use boolean instead of 0/1 for condition check
    
    * gh-84461: Fix Emscripten umask and permission issues (GH-94002)
    
    - Emscripten's default umask is too strict, see
      emscripten-core/emscripten#17269
    - getuid/getgid and geteuid/getegid are stubs that always return 0
      (root). Disable effective uid/gid syscalls and fix tests that use
      chmod() current user.
    - Cannot drop X bit from directory.
    
    * gh-84461: Skip test_unwritable_directory again on Emscripten (GH-94007)
    
    GH-93992 removed geteuid() and enabled the test again on Emscripten.
    
    * gh-93925: Improve clarity of sqlite3 commit/rollback, and close docs (#93926)
    
    Co-authored-by: CAM Gerlach <[email protected]>
    
    * gh-61162: Clarify sqlite3 connection context manager docs (GH-93890)
    
    
    
    Explicitly note that transactions are only closed if there is an open
    transation at `__exit__`, and that transactions are not implicitly
    opened during `__enter__`.
    
    Co-authored-by: CAM Gerlach <[email protected]>
    Co-authored-by: Stanley <[email protected]>
    
    Automerge-Triggered-By: GH:erlend-aasland
    
    * gh-79009: sqlite3.iterdump now correctly handles tables with autoincrement (#9621)
    
    Co-authored-by: Erlend E. Aasland <[email protected]>
    
    * gh-84461: Silence some compiler warnings on WASM (GH-93978)
    
    * GH-93897: Store frame size in code object and de-opt if insufficient space on thread frame stack. (GH-93908)
    
    * GH-93516: Speedup line number checks when tracing. (GH-93763)
    
    * Use a lookup table to reduce overhead of getting line numbers during tracing.
    
    * gh-90539: doc: Expand on what should not go into CFLAGS, LDFLAGS (#92754)
    
    * gh-87347: Add parenthesis around macro arguments (#93915)
    
    Add unit test on Py_MEMBER_SIZE() and some other macros.
    
    * gh-93937: PyOS_StdioReadline() uses PyConfig.legacy_windows_stdio (#94024)
    
    On Windows, PyOS_StdioReadline() now gets
    PyConfig.legacy_windows_stdio from _PyOS_ReadlineTState, rather than
    using the deprecated global Py_LegacyWindowsStdioFlag variable.
    
    Fix also a compiler warning in Py_SetStandardStreamEncoding().
    
    * GH-93249: relax overly strict assertion on bounds->ar_start (GH-93961)
    
    * gh-94021: Address unreachable code warning in specialize code (GH-94022)
    
    * GH-93678: refactor compiler so that optimizer does not need the assembler and compiler structs (GH-93842)
    
    * gh-93839: Move Lib/ctypes/test/ to Lib/test/test_ctypes/ (#94041)
    
    * Move Lib/ctypes/test/ to Lib/test/test_ctypes/
    * Remove Lib/test/test_ctypes.py
    * Update imports and build system.
    
    * gh-93839: Move Lib/unttest/test/ to Lib/test/test_unittest/ (#94043)
    
    * Move Lib/unittest/test/ to Lib/test/test_unittest/
    * Remove Lib/test/test_unittest.py
    * Replace unittest.test with test.test_unittest
    * Remove unittest.load_tests()
    * Rewrite unittest __init__.py and __main__.py
    * Update build system, CODEOWNERS, and wasm_assets.py
    
    * GH-91432: Specialize FOR_ITER (GH-91713)
    
    * Adds FOR_ITER_LIST and FOR_ITER_RANGE specializations.
    
    * Adds _PyLong_AssignValue() internal function to avoid temporary boxing of ints.
    
    * gh-94028: Clear and reset sqlite3 statements properly in cursor iternext (GH-94042)
    
    * gh-94052: Don't re-run failed tests with --python option (#94054)
    
    * gh-93839: Use load_package_tests() for testmock (GH-94055)
    
    
    
    Fixes failing tests on WebAssembly platforms.
    
    Automerge-Triggered-By: GH:tiran
    
    * gh-54781: Move Lib/lib2to3/tests/ to Lib/test/test_lib2to3/ (#94049)
    
    * Move Lib/lib2to3/tests/ to Lib/test/test_lib2to3/.
    * Remove Lib/test/test_lib2to3.py.
    * Update imports.
    * all_project_files(): use different paths and sort files
      to make the tests more reproducible.
    * Update references to tests.
    
    * gh-74953: _PyThread_cond_after() uses _PyTime_t (#94056)
    
    pthread _PyThread_cond_after() implementation now uses the _PyTime_t
    type to handle properly overflow: clamp to the maximum value.
    
    Remove MICROSECONDS_TO_TIMESPEC() function.
    
    * GH-93841: Allow stats to be turned on and off, cleared and dumped at runtime. (GH-93843)
    
    * gh-86986: Drop compatibility support for Sphinx 2 (GH-93737)
    
    * Revert "bpo-42843: Keep Sphinx 1.8 and Sphinx 2 compatibility (GH-24282)"
    
    This reverts commit 5c1f15b
    
    * Revert "bpo-42579: Make workaround for various versions of Sphinx more robust (GH-23662)"
    
    This reverts commit b63a620.
    
    * gh-94068: Remove HVSOCKET_CONTAINER_PASSTHRU constant because it has been removed from Windows (GH-94069)
    
    
    
    Fixes #94068
    
    Automerge-Triggered-By: GH:zware
    
    * Closes gh-94038: Update Release Schedule in README.rst from PEP 664 to PEP 693 (GH-94046)
    
    * gh-93851: Fix all broken links in Doc/ (GH-93853)
    
    * gh-93675: Fix typos in `Doc/` (GH-93676)
    
    Closes #93675
    
    * Minor optimization for Fractions.limit_denominator (GH-93730)
    
    When we construct the upper and lower candidates in limit_denominator,
    the numerator and denominator are already relatively prime (and the
    denominator positive) by construction, so there's no need to go through
    the usual normalisation in the constructor. This saves a couple of
    potentially expensive gcd calls.
    
    Suggested by Michael Scott Asato Cuthbert in GH-93477.
    
    * gh-93240: clarify wording in IO tutorial (GH-93276)
    
    Co-authored-by: Adam Turner <[email protected]>
    
    * Tutorial: specify match cases don't fall through (GH-93615)
    
    * gh-93021: Fix __text_signature__ for __get__ (GH-93023)
    
    Because of the way wrap_descr_get is written, the second argument
    to __get__ methods implemented through the wrapper is always
    optional.
    
    * gh-82927: Update files related to HTML entities. (GH-92504)
    
    * DOC: correct bytesarray -> bytearray in comments (GH-92410)
    
    * gh-87389: Fix an open redirection vulnerability in http.server. (#93879)
    
    Fix an open redirection vulnerability in the `http.server` module when
    an URI path starts with `//` that could produce a 301 Location header
    with a misleading target.  Vulnerability discovered, and logic fix
    proposed, by Hamza Avvan (@hamzaavvan).
    
    Test and comments authored by Gregory P. Smith [Google].
    
    * gh-89336: Remove configparser APIs that were deprecated for 3.12 (#92503)
    
    https://github.com/python/cpython/issue/89336: Remove configparser 3.12 deprecations.
    
    Co-authored-by: Hugo van Kemenade <[email protected]>
    
    * bpo-30535: [doc] state that sys.meta_path is not empty by default (GH-94098)
    
    Co-authored-by: Windson yang <[email protected]>
    
    * gh-88123: Implement new Enum __contains__ (GH-93298)
    
    Co-authored-by: Ethan Furman <[email protected]>
    
    * Stats: Add summary of top instructions for misses and deferred specialization. (GH-94072)
    
    * gh-74696: Do not change the current working directory in shutil.make_archive() if possible (GH-93160)
    
    It is no longer changed when create a zip or tar archive.
    
    It is still changed for custom archivers registered with shutil.register_archive_format()
    if root_dir is not None.
    
    Co-authored-by: Éric <[email protected]>
    Co-authored-by: Łukasz Langa <[email protected]>
    
    * gh-94101 Disallow instantiation of SSLSession objects (GH-94102)
    
    
    
    Fixes #94101
    
    Automerge-Triggered-By: GH:tiran
    
    * Fix typo in _io.TextIOWrapper Clinic input (#94037)
    
    Co-authored-by: Łukasz Langa <[email protected]>
    
    * gh-93951: In test_bdb.StateTestCase.test_skip, avoid including auxiliary importers. (GH-93962)
    
    Co-authored-by: Brett Cannon <[email protected]>
    
    * gh-91172: Create a workflow for verifying bundled pip and setuptools (GH-31885)
    
    Co-authored-by: Hugo van Kemenade <[email protected]>
    Co-authored-by: Adam Turner <[email protected]>
    
    * gh-94114: Remove obsolete reference to python.org mirrors (GH-94115)
    
    
    
    * gh-94114
    
    * gh-84623: Remove unused imports (#94132)
    
    * gh-54781: Move Lib/tkinter/test/test_ttk/ to Lib/test/test_ttk/ (#94070)
    
    * Move Lib/tkinter/test/test_tkinter/ to Lib/test/test_tkinter/.
    * Move Lib/tkinter/test/test_ttk/ to Lib/test/test_ttk/.
    * Add Lib/test/test_ttk/__init__.py based on test_ttk_guionly.py.
    * Add Lib/test/test_tkinter/__init__.py
    * Remove old Lib/test/test_tk.py.
    * Remove old Lib/test/test_ttk_guionly.py.
    * Add __main__ sub-modules.
    * Update imports and update references to rename files.
    
    * gh-84623: Move imports in doctests (#94133)
    
    Move imports in doctests to prevent false alarms in pyflakes.
    
    * Add ABI dump Makefile target (#94136)
    
    * gh-84623: Remove unused imports in idlelib (#94143)
    
    Remove commented code in test_debugger_r.py.
    
    Co-authored-by: Terry Jan Reedy <[email protected]>
    
    * gh-85308: argparse: Use filesystem encoding for arguments file (GH-93277)
    
    * Closes gh-94152: Update pyvideo.org URL (GH-94075)
    
    The URL is now https://pyvideo.org, which uses HTTPS and avoids a redirect.
    
    * gh-91456: [Enum] Deprecate default auto() behavior with mixed value types (GH-91457)
    
    When used with plain Enum, auto() returns the last numeric value assigned, skipping any incompatible member values (such as strings); starting in 3.13 the default auto() for plain Enums will require all the values to be of compatible types, and will return a new value that is 1 higher than any existing value.
    
    Co-authored-by: Ethan Furman <[email protected]>
    
    * gh-84461: Fix test_sqlite for Emscripten/WASI (#94125)
    
    * gh-86404: [doc] Fix missing backtick and double target name. (#94120)
    
    * gh-89121: Keep the number of pending SQLite statements to a minimum (#30379)
    
    Make sure statements that have run to completion or errored are
    reset and cleared off the cursor for all paths in execute() and
    executemany().
    
    * GH-91742: Fix pdb crash after jump  (GH-94171)
    
    * [Enum] fix typo (GH-94158)
    
    * gh-92858: Improve error message for some suites with syntax error before ':' (#92894)
    
    * gh-93771: Clarify how deepfreeze.py is run (#94150)
    
    * gh-91219: Add an index_pages default list and parameter to SimpleHTTPRequestHandler (GH-31985)
    
    * Add an index_pages default list to SimpleHTTPRequestHandler and an
    optional constructor parameter that allows the default indexes pages
    list to be overridden.  This makes it easy to set a new index page name
    without having to override send_head.
    
    * [Enum] Remove automatic docstring generation (GH-94188)
    
    * Add ABI dump script (#94135)
    
    * Add more tests for throwing into yield from (GH-94097)
    
    * gh-94169: Remove deprecated io.OpenWrapper (#94170)
    
    Remove io.OpenWrapper and _pyio.OpenWrapper, deprecated in Python
    3.10: just use :func:`open` instead. The open() (io.open()) function
    is a built-in function. Since Python 3.10, _pyio.open() is also a
    static method.
    
    * gh-94199: Remove ssl.RAND_pseudo_bytes() function (#94202)
    
    Remove the ssl.RAND_pseudo_bytes() function, deprecated in Python
    3.6: use os.urandom() or ssl.RAND_bytes() instead.
    
    * gh-94196: Remove gzip.GzipFile.filename attribute (#94197)
    
    gzip: Remove the filename attribute of gzip.GzipFile,
    deprecated since Python 2.6, use the name attribute instead. In write
    mode, the filename attribute added '.gz' file extension if it was not
    present.
    
    * gh-93692: remove "build finished successfully" message from setup.py (#93693)
    
    The message was only emitted when the build succeeded _and_ there were
    missing modules.
    
    * gh-84461: Fix ctypes and test_ctypes on Emscripten (#94142)
    
    - c_longlong and c_longdouble need experimental WASM bigint.
    - Skip tests that need threading
    - Define ``CTYPES_MAX_ARGCOUNT`` for Emscripten. libffi-emscripten 2022-06-23 supports up to 1000 args.
    
    * gh-94205: Ensures all required DLLs are copied on Windows for underpth tests (GH-94206)
    
    * gh-84461: Build Emscripten with WASM BigInt support (#94219)
    
    * gh-94172: urllib.request avoids deprecated check_hostname (#94193)
    
    The urllib.request no longer uses the deprecated check_hostname
    parameter of the http.client module.
    
    Add private http.client._create_https_context() helper to http.client,
    used by urllib.request.
    
    Remove the now redundant check on check_hostname and verify_mode in
    http.client: the SSLContext.check_hostname setter already implements
    the check.
    
    * IDLE: replace if statement with expression (#94228)
    
    * Docs: Remove `Provides [...]` from `multiprocessing.shared_memory` description (#92761)
    
    * gh-93382: Sync up `co_code` changes with 3.11 (GH-94227)
    
    Sync up co_code changes with 3.11 commit 852b4d4.
    
    * gh-94217: Skip import tests when _testcapi is a builtin (GH-94218)
    
    * gh-85308: Add argparse tests for reading non-ASCII arguments from file (GH-94160)
    
    * bpo-46642: Explicitly disallow subclassing of instaces of TypeVar, ParamSpec, etc (GH-31148)
    
    The existing test covering this case passed only incidentally. We
    explicitly disallow doing this and add a proper error message.
    
    Co-authored-by: Serhiy Storchaka <[email protected]>
    
    * bpo-26253: Add compressionlevel to tarfile stream (GH-2962)
    
    `tarfile` already accepts a compressionlevel argument for creating
    files. This patch adds the same for stream-based tarfile usage.
    The default is 9, the value that was previously hard-coded.
    
    * gh-70441: Fix test_tarfile on systems w/o bz2 (gh-2962) (#94258)
    
    * gh-94199: Remove ssl.match_hostname() function (#94224)
    
    * gh-94207: Fix struct module leak (GH-94239)
    
    Make _struct.Struct a GC type
    
    This fixes a memory leak in the _struct module, where as soon
    as a Struct object is stored in the cache, there's a cycle from
    the _struct module to the cache to Struct objects to the Struct
    type back to the module. If _struct.Struct is not gc-tracked, that
    cycle is never collected.
    
    This PR makes _struct.Struct GC-tracked, and adds a regression test.
    
    * gh-94245: Test pickling and copying of typing.Tuple[()] (GH-94259)
    
    * gh-77560: Report possible errors in restoring builtins at finalization (GH-94255)
    
    Seems in the past the copy of builtins was not made in some scenarios,
    and the error was silenced. Write it now to stderr, so we have a chance
    to see it.
    
    * gh-90016: Reword sqlite3 adapter/converter docs (#93095)
    
    Also add adapters and converter recipes.
    
    Co-authored-by: CAM Gerlach <[email protected]>
    Co-authored-by: Alex Waygood <[email protected]
    
    * bpo-39971: Change examples to be runnable (GH-32172)
    
    * gh-70474: [doc] fix wording of GET_ANEXT doc (GH-94048)
    
    * gh-93259: Validate arg to ``Distribution.from_name``. (GH-94270)
    
    Syncs with importlib_metadata 4.12.0.
    
    Co-authored-by: Irit Katriel <[email protected]>
    Co-authored-by: Ulises Ojeda <[email protected]>
    Co-authored-by: jackh-ncl <[email protected]>
    Co-authored-by: Mark Dickinson <[email protected]>
    Co-authored-by: Colin Delahunty <[email protected]>
    Co-authored-by: Neil Schemenauer <[email protected]>
    Co-authored-by: Christian Heimes <[email protected]>
    Co-authored-by: Dennis Sweeney <[email protected]>
    Co-authored-by: Cyker Way <[email protected]>
    Co-authored-by: Hugo van Kemenade <[email protected]>
    Co-authored-by: Omer Katz <[email protected]>
    Co-authored-by: Stanley <[email protected]>
    Co-authored-by: Thomas Grainger <[email protected]>
    Co-authored-by: Illia Volochii <[email protected]>
    Co-authored-by: Erlend Egeberg Aasland <[email protected]>
    Co-authored-by: Alex Waygood <[email protected]>
    Co-authored-by: AN Long <[email protected]>
    Co-authored-by: Samodya Abeysiriwardane <[email protected]>
    Co-authored-by: Evorage <[email protected]>
    Co-authored-by: Davide Rizzo <[email protected]>
    Co-authored-by: Pascal Wittmann <[email protected]>
    Co-authored-by: Vinay Sajip <[email protected]>
    Co-authored-by: Adam Turner <[email protected]>
    Co-authored-by: Łukasz Langa <[email protected]>
    Co-authored-by: Andreas Grommek <[email protected]>
    Co-authored-by: Mark Shannon <[email protected]>
    Co-authored-by: Ken Jin <[email protected]>
    Co-authored-by: Adrian Garcia Badaracco <[email protected]>
    Co-authored-by: jacksonriley <[email protected]>
    Co-authored-by: Kalyan <[email protected]>
    Co-authored-by: Bluenix <[email protected]>
    Co-authored-by: Petr Viktorin <[email protected]>
    Co-authored-by: CAM Gerlach <[email protected]>
    Co-authored-by: Sebastian Berg <[email protected]>
    Co-authored-by: Leo Trol <[email protected]>
    Co-authored-by: XD Trol <[email protected]>
    Co-authored-by: Antoine Pitrou <[email protected]>
    Co-authored-by: neonene <[email protected]>
    Co-authored-by: Steve Dower <[email protected]>
    Co-authored-by: Pablo Galindo Salgado <[email protected]>
    Co-authored-by: Barney Gale <[email protected]>
    Co-authored-by: Oleg Iarygin <[email protected]>
    Co-authored-by: Brett Cannon <[email protected]>
    Co-authored-by: John Belmonte <[email protected]>
    Co-authored-by: Julien Palard <[email protected]>
    Co-authored-by: Pamela Fox <[email protected]>
    Co-authored-by: Dong-hee Na <[email protected]>
    Co-authored-by: Kumar Aditya <[email protected]>
    Co-authored-by: Victor Stinner <[email protected]>
    Co-authored-by: Sanket Shanbhag <[email protected]>
    Co-authored-by: Jeong YunWon <[email protected]>
    Co-authored-by: Steve Dower <[email protected]>
    Co-authored-by: samtygier <[email protected]>
    Co-authored-by: Ken Jin <[email protected]>
    Co-authored-by: Brandt Bucher <[email protected]>
    Co-authored-by: Gregory P. Smith <[email protected]>
    Co-authored-by: chilaxan <[email protected]>
    Co-authored-by: Serhiy Storchaka <[email protected]>
    Co-authored-by: Chris Fernald <[email protected]>
    Co-authored-by: Jason R. Coombs <[email protected]>
    Co-authored-by: Ezio Melotti <[email protected]>
    Co-authored-by: Lei Zhang <[email protected]>
    Co-authored-by: Erlend Egeberg Aasland <[email protected]>
    Co-authored-by: itssme <[email protected]>
    Co-authored-by: Matthias Köppe <[email protected]>
    Co-authored-by: MilanJuhas <[email protected]>
    Co-authored-by: luzpaz <[email protected]>
    Co-authored-by: paulreece <[email protected]>
    Co-authored-by: max <[email protected]>
    Co-authored-by: Jelle Zijlstra <[email protected]>
    Co-authored-by: Thomas A Caswell <[email protected]>
    Co-authored-by: Windson yang <[email protected]>
    Co-authored-by: Carl Bordum Hansen <[email protected]>
    Co-authored-by: Ethan Furman <[email protected]>
    Co-authored-by: Éric <[email protected]>
    Co-authored-by: chgnrdv <[email protected]>
    Co-authored-by: fikotta <[email protected]>
    Co-authored-by: partev <[email protected]>
    Co-authored-by: Terry Jan Reedy <[email protected]>
    Co-authored-by: Inada Naoki <[email protected]>
    Co-authored-by: Oscar R <[email protected]>
    Co-authored-by: wookie184 <[email protected]>
    Co-authored-by: Guido van Rossum <[email protected]>
    Co-authored-by: Myron Walker <[email protected]>
    Co-authored-by: Sam Ezeh <[email protected]>
    Co-authored-by: Ken Jin <[email protected]>
    Co-authored-by: Gregory Beauregard <[email protected]>
    Co-authored-by: Yaron de Leeuw <[email protected]>
    Co-authored-by: Mark Dickinson <[email protected]>
    @JelleZijlstra
    Copy link
    Member Author

    I think we're done here, thanks everyone for all the hard work!

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.11 only security fixes topic-typing type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    7 participants