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 586: Literal Types #928

Merged
merged 18 commits into from
Mar 15, 2019
Merged

PEP 586: Literal Types #928

merged 18 commits into from
Mar 15, 2019

Conversation

Michael0x2a
Copy link
Contributor

This is a pull request for a new PEP proposal for adding a new category of types to the PEP 484 typing ecosystem -- Literal types.

Some procedural things:

  1. Although this PEP was not discussed in python-ideas, it has been discussed in the typing-sig mailing list and in my draft pull request over the past few months. I'm submitting this PEP now so it can start going through the standard acceptance process (whenever it starts).
  2. We've implemented the bulk of this PEP in mypy. The only things currently missing is support for Enum Literals and some of the more complex inference suggestions in this PEP. We plan on adding in those missing gaps over the next month or so.
  3. One of the co-authors (Ivan Levkivskyi) is a core Python developer. I understand that means it's ok to leave out the "Sponsor" field?

…erals

This commit:

1. Performs a bunch of cleanup suggested by Ivan
2. Adds a note clarifying that negative numbers are *allowed*
3. Adds a note reiterating that PEP 484 expects type checkers to
   understand enum values when performing type inference (and
   suggests this can be implemented by treating enums as roughly
   equal to the union of their types)
4. Moves "nested literals" into the "supported" category -- as I
   discovered in python/mypy#5947,
   implementing support for this is not as bad as I thought.
5. Adds an explicit warning to the "literals and generics" section.
6. Modifies some text to become more firm about disallowing
   'Literal[Any]' and related constructs.
7. Deletes discussion about TypeScript's "index types" and "keyof"
   operator -- I mostly included that only because I got some feedback
   earlier to discuss TypeScript. It felt pretty shoehorned in,
   anyways.
@Michael0x2a
Copy link
Contributor Author

@gvanrossum -- I took 586, as you suggested.

pep-0586.rst Outdated Show resolved Hide resolved
pep-0586.rst Outdated Show resolved Hide resolved
pep-0586.rst Outdated Show resolved Hide resolved
@gvanrossum gvanrossum merged commit b870ad2 into python:master Mar 15, 2019
@gvanrossum
Copy link
Member

Hi Michael, as a PEP editor I've merged your PR. This just means that the PEP conforms to the procedural and formatting requirements. If you have updates, just send another PR and one of the PEP editors will merge them. (PEP editors don't judge a PEP by its contents, only by its form.)

The process to acceptance is then roughly as follows:

  1. Start a debate on typing-sig.
  2. Once there's rough consensus, send a formal request for approval. I believe that should just go to python-dev. (We're not actually very formal about this. :-)
  3. The Steering Council will then assign a BDFL-Delegate. (I'll probably volunteer.)
  4. The BDFL-Delegate will guide you through the remaining process. (If the typing-sig debate ends with clear consensus there's not much more to do at this point.)

Good luck!

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.

5 participants