Commit Graph

15 Commits

Author SHA1 Message Date
Jelle Zijlstra 83b976da18
Add Typing Topic (#2670)
Co-authored-by: CAM Gerlach <CAM.Gerlach@Gerlach.CAM>
2022-10-06 17:36:39 -07:00
Adam Turner 42f88f1ce2
Display list names in Resolution and Discussions-To headers (#2361) 2022-02-27 14:46:36 -08:00
Adam Turner 113e490701
Several PEPs: Use explicit `:pep:` and `:rfc:` roles (#2209) 2022-01-21 11:03:51 +00:00
Marti Raudsepp 9b64c6ea75
Various typo/grammar/style fixes (#1789)
Changes detected by Topy (https://github.com/intgr/topy), all changes
verified by hand, false positives have been omitted.

These range from straight-out misspellings to debatable hyphen placement.
The hyphen changes are supported by grammar manuals of style.
2021-02-03 06:06:23 -08:00
Michael Lee f990bd97a7 Fix 'Created' date for PEP 586 (#1149)
PEP 586 was actually authored in March 2019, not March 2018 -- see the
[commit log history](https://github.com/python/peps/commits/master/pep-0586.rst).
2019-08-21 23:40:11 +01:00
Ivan Levkivskyi a6c96caf46
Mark PEPs 544, 586, 589, and 591 as accepted for Python 3.8 (#1088) 2019-05-26 10:58:57 +01:00
Michael Lee 2cb7fa99ce PEP 586: Rewrite sections regarding enum (#997)
This commit adjusts two sections of this PEP that are related to enums.

First, it removes the sections regarding the interaction between enums,
imports, and Any. I wasn't aware that the import behavior described in
that section was mypy-only and isn't codified in PEP 484. So, I decided
to just remove that section entirely -- it didn't feel there was much I
could salvage there.

Instead, I opted to adjust the "invalid parameters" section to explain
in a little more detail why `Literal[Any]` is not allowed.

Second, I split up the section about type narrowing into two.

The first new section is a reminder that PEP 484 requires type checkers
to support certain kinds of exhaustibility checks when working with enums.
To make this more clear, I adjusted the example to be more closer to what
is used in the spec and removed any mention of reachability -- it felt
like a distraction.

The second section focuses back on some neat tricks using Literals that
type checkers may optionally implement. I also tweaked some of the
examples here as suggested in https://github.com/python/peps/pull/993.
2019-04-17 20:19:09 -07:00
Guido van Rossum bb83c95b19
PEP 586, PEP 589, PEP 591: Make Guido BDFL-Delegate of typing PEPs (#1001) 2019-04-17 13:45:01 -07:00
Michael Lee 9f34665cf1 PEP 586: Make backwards compatibility best-effort (#995)
This pull request relaxes PEP 586 so that type checkers are now expected
to maintain backwards compatibility on a best-effort basis, rather than
a mandatory basis.

It also rearranges the order in which information is presented: the
section now opens with and focuses on an example of what a too-disruptive
inference strategy would look like.
2019-04-17 10:53:13 -07:00
Vincent Poulailleau 44e0178891 typo: MAy -> May (#999) 2019-04-17 08:14:35 -07:00
Michael Lee 6d205a43fa PEP 586: Add section about Final (#996)
This commit adds a section discussion how Literal types interact with
Final from PEP 591, if both PEPs are accepted. In short, it states
that type checkers are expected to understand that assignment statements
of the form `var: Final = value` are a way of declaring `var` to
effectively be of type `Literal[value]` in certain cases.
2019-04-16 09:41:35 -07:00
Serhiy Storchaka ad7f2b2f6c Remove trailing spaces from many PEPs (#983) 2019-04-16 07:50:15 -07:00
Guido van Rossum 7a0b6e7ef0
PEP 586: Small wording changes from review (#993) 2019-04-15 19:03:35 -07:00
Michael Lee 7370df1f00 PEP 586: Fix typos and tighten wording (#929)
This pull request fixes one or two typos in PEP 586.

It also slightly adjusts the wording of the section on
type inference as suggested here:
https://github.com/Michael0x2a/peps/pull/1#discussion_r265795433
2019-03-14 18:42:08 -07:00
Michael Lee b870ad2a45 PEP 586: Literal Types (#928) 2019-03-14 17:29:08 -07:00