Skip to content

bpo-32226: PEP 560: improve typing module #4906

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

Merged
merged 88 commits into from
Jan 20, 2018

Conversation

ilevkivskyi
Copy link
Member

@ilevkivskyi ilevkivskyi commented Dec 16, 2017

This is not ready for a detailed review, but updates to tests can be already discussed. You can also play with the new implementation but some minor details can change.

Here is the summary of changes in tests (two first are mentioned in the PEP):

  • issublcass(List[int], List) etc. raise TypeError instead of returning True as before.
  • repr() for unsubscripted generics coincides with repr() for normal (non-generic) classes, like
    <class '__main__.MyGeneric'>. However all things in typing that are not class objects and all subscripted generics use existing "fancy" repr(), like typing.List[__main__.C[int]].
  • In view of PEP 563 I propose to remove leading underscore from ForwardRef, on the contrary, I add underscore to _Protocol until PEP 544 is accepted and the "real" Protocol is added to typing.
  • I removed most pieces of code that existed for backwards compatibility, since this version is only for Python 3.7

An important question is how will we keep stdlib version and the backport on PyPI in sync? One possible option is just manually copy useful updates/test between them.

cc: @gvanrossum

https://bugs.python.org/issue32226

@gvanrossum
Copy link
Member

I'm afraid I won't be able to look at this in time for 3.7b1. I trust Serhiy, so I think it's between the two of you.

As to which repo should be fixed first, I propose to do the CPython master branch first, backporting to 3.6 if appropriate, and only to the typing repo if it's relevant for Python 2.7. For 3.5 and 3.6 the typing repo isn't used anyways (except by people who set $PYTHONPATH), and 3.4 is no longer supported (may it rest in peace).

I assume that even Python 2.7 support will be minimal, but we should at least try to keep Protocol support up to date there, and perhaps other new features for which it makes sense. If we didn't have Python 2.7, I'd propose to just close the repo like we did for asyncio -- but I think we can't do that until the Python 2.7 EOL date of 1/1/2020.

This could even mean that we could sanitize the typing repo, removing the Python 3 support code. Though I'm not sure what to do with the issue tracker. Should we continue to point people there for fundamental discussions about the type system?

@gvanrossum
Copy link
Member

For the other issues (including Union simplification) I would be happy to see small PRs, one per issue or feature.

@ilevkivskyi
Copy link
Member Author

OK, @serhiy-storchaka would you like to make another pass of review? Note that one of the goals of this PR is to simplify the code, so that it is easier to understand, so it would be a good test. If there are some particularly tricky places in code, then you can just flag them, so that I will add comments there. Or you will not have time today/tomorrow then maybe we can just merge as is, to unblock other things that depend on this PR?

@ilevkivskyi
Copy link
Member Author

@serhiy-storchaka If you don't have time to review this now, then I think we shouldn't wait more. I am going to merge this in an hour or so. Please let me know if you still want to review this.

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know too small about this module for making deep review, but at surface I don't see anything wrong. If there are some problems, I think they can be resolved at the beta stage in separate issues.

@ilevkivskyi
Copy link
Member Author

OK.

@eirrgang
Copy link
Contributor

This change did not update Doc/library/typing.rst but the note that "The metaclass used by :class:Generic is a subclass of :class:abc.ABCMeta." is no longer true, is it?

@ilevkivskyi
Copy link
Member Author

@eirrgang You are right, there is no more metaclass for Generic (i.e. its metaclass is just type). Would you like to make a PR?

eirrgang added a commit to eirrgang/cpython that referenced this pull request Oct 8, 2019
PR python#4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
@eirrgang
Copy link
Contributor

eirrgang commented Oct 8, 2019

@eirrgang You are right, there is no more metaclass for Generic (i.e. its metaclass is just type). Would you like to make a PR?

Uploaded #16646

eirrgang added a commit to eirrgang/cpython that referenced this pull request Oct 8, 2019
PR python#4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
ilevkivskyi pushed a commit that referenced this pull request Oct 10, 2019
PR #4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Oct 10, 2019
PR pythonGH-4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
(cherry picked from commit d47f0dd)

Co-authored-by: M. Eric Irrgang <mei2n@virginia.edu>
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Oct 10, 2019
PR pythonGH-4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
(cherry picked from commit d47f0dd)

Co-authored-by: M. Eric Irrgang <mei2n@virginia.edu>
miss-islington added a commit that referenced this pull request Oct 10, 2019
PR GH-4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
(cherry picked from commit d47f0dd)

Co-authored-by: M. Eric Irrgang <mei2n@virginia.edu>
miss-islington added a commit that referenced this pull request Oct 10, 2019
PR GH-4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
(cherry picked from commit d47f0dd)

Co-authored-by: M. Eric Irrgang <mei2n@virginia.edu>
ned-deily pushed a commit to ned-deily/cpython that referenced this pull request Oct 14, 2019
PR pythonGH-4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
(cherry picked from commit d47f0dd)

Co-authored-by: M. Eric Irrgang <mei2n@virginia.edu>
jacobneiltaylor pushed a commit to jacobneiltaylor/cpython that referenced this pull request Dec 5, 2019
PR python#4906 changed the typing.Generic class hierarchy, leaving an
outdated comment in the library reference. User-defined Generic ABCs now
must get a abc.ABCMeta metaclass from something other than typing.Generic
inheritance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants