Commit Graph

8055 Commits

Author SHA1 Message Date
Donald Stufft 1e8f07b877
PEP 592: Typo fixes & restructuring (#1043) 2019-05-10 11:37:42 -04:00
Donald Stufft 8ac1ec8fe6
592 Clarifications (#1042) 2019-05-10 10:52:33 -04:00
Nick Coghlan 363d67baae
PEP 457: Better distinguish this PEP from PEP 570 (#920)
This PEP: shorthand notation to describe positional-only arguments
PEP 570: Elevating that notation to actual Python syntax
2019-05-09 17:59:35 -04:00
Hugo 2663c13a28 PEP 503: Update PyPI's base URL for Warehouse (#1036) 2019-05-09 14:27:52 -07:00
Dominik Gabi 3e293e68e9 [pep-0591] clarify that type checkers may not allow `Final` in loops (#1033) 2019-05-08 17:36:02 -04:00
Petr Viktorin 7fc318e844
PEP 590: Update (GH-1035)
Intermediate result of discussions from:

* https://github.com/python/peps/pull/1028
* https://github.com/python/peps/pull/1035

Co-Authored By: Jeroen Demeyer <J.Demeyer@UGent.be>
2019-05-08 15:32:35 -04:00
Antoine Pitrou 60d8b08e39 PEP 574: Mark accepted (#1031) 2019-05-08 11:56:00 -04:00
Donald Stufft 543cece82e
Clarifications to PEP 592 (#1034) 2019-05-08 11:00:46 -04:00
Donald Stufft 01b3a01495
PEP 592: Support for "Yanked" Files on the Simple API (#1032) 2019-05-07 20:55:00 -04:00
Christian Heimes 6769551f66 PEP 578: mark as accepted (#1030)
Signed-off-by: Christian Heimes <christian@python.org>
2019-05-07 16:51:11 -04:00
Nick Coghlan cb033869fc
PEP 517: Clarify expected front end handling of setup.py based trees (#1029)
The previous wording could be taken as suggesting that frontends should opt
out of their PEP 517 processing entirely if build-backend was not defined,
whereas it's actually fine to just use the setuptools provided backend that
implements the legacy build semantics.
2019-05-07 15:37:29 -04:00
Steve Dower 4ab33c63f1 PEP 578: Update with feedback (#1023)
* Note about naming style
* Add note about using package name
* Avoid embedding null characters
* Add socket event argument to socket events
2019-05-07 15:36:45 -04:00
Mark Shannon fd54e6e509 PEP 590: Swap tp_vectorcall_offset and tp_vectorcall slots. (GH-1026)
PEP 590: Swap tp_vectorcall_offset and tp_vectorcall slots to allow Cython to use vectorcall in versions before 3.8.
2019-05-07 09:54:57 -04:00
Petr Viktorin 7dc58a6307
Reject PEP 580 in favor of PEP 590 (GH-1027) 2019-05-07 09:54:15 -04:00
Łukasz Langa 2ff689ff08
Update release dates of 3.8a4 and 3.8b1 2019-05-06 22:23:09 +02:00
Logan Jones 6a705de78e Update PEP-572 for f-strings (see bpo-36798) (#1024)
See bpo-36798.

This update specifies the interplay between f-strings and
the assignment operator. Specifically, it attempts to
clarify how to use assignment operators inside of f-strings.
2019-05-06 11:30:23 -05:00
Victor Stinner ad68d00ba1 PEP 587: fix typo 2019-05-02 16:45:44 -04:00
Victor Stinner 8763930784
PEP 587: Init API v2 (#1018) 2019-05-02 15:14:06 -04:00
Guido van Rossum 7519d3280b Mariatta prefers to be just Mariatta (#1020) 2019-05-02 09:14:33 -04:00
Matthias Bussonnier 24757f9af8 stry backquote (#1021) 2019-05-01 22:46:24 -05:00
Guido van Rossum 5f0630a5f8 PEP 588: Use Mariatta's full name (as in PEP 581) 2019-05-01 15:49:19 -04:00
Brett Cannon b1184ab11a
Specify how long votes should be held (#1000)
Voting on this change passed with 85% of the vote: https://discuss.python.org/t/vote-on-pep-13-change-to-specify-voting-time-frames/1510.
2019-05-01 12:27:09 -07:00
Brett Cannon 924e3b3064
Mark PEP 482 final (#1019)
OK'ed by Łukasz in-person.
2019-05-01 07:40:01 -07:00
Barry Warsaw b393d4bbfd Split GitHub migration rationale and plan into two separate PEPs (#1013) 2019-04-30 19:51:45 -04:00
Antoine Pitrou 969ccb255e PEP 574: Final updates (#1017)
Reconcile the PEP contents with the current implementation.
2019-04-29 21:20:45 -07:00
Eric Snow 95774abc13
PEP 554: Defer adding support for "inheriting" settings. (gh-1016) 2019-04-27 09:49:25 -06:00
Eric Snow b2537c9af1
[PEP 554] Change target version to 3.9. (gh-1015)
There is too little time left before the 3.8 release and I don't want Antoine to feel rushed to pronounce. The implementation is mostly complete, so we could land it for 3.8. However, the experience in 3.8 wouldn't be nearly as good, in part because we're still sharing the GIL. Plus, we need more confidence that extension modules won't be severely impacted by the wide-spread use of subinterpreters. Waiting for 3.9 will allow us to address both issues, as well improve performance (especially startup).
2019-04-27 09:15:34 -06:00
Nick Coghlan 6042e3287d
PEP 573: Stefan Behnel has accepted the BDFL-Delegate role (#1011) 2019-04-25 15:20:39 +10:00
Mark Shannon d0b3fc8288 PEP 590: Remove unnecessary PyObject_VectorCall function. Rename PyObject_VectorCallWithCallable to PyObject_VectorCall. Correct note about use of PY_VECTORCALL_ARGUMENTS_OFFSET in PyObject_VectorCall. Correct grammar in section on internal CPython changes. (GH-992) 2019-04-24 14:05:47 -04:00
Nick Coghlan 1b5d22cf78
PEP 558: Appoint BDFL-Delegate and other updates (#1008)
Also adds a link to the in-development reference implementation,
and makes the dynamic frame.f_locals behaviour an open question.
2019-04-24 09:04:37 +10:00
Mariatta 89616deb28 PEP 557: Data Classes - Mark as Final (#1007)
Shipped in Python 3.7
2019-04-22 02:01:41 +10:00
Nick Coghlan 2793eb9ef5
PEP 467: Defer, and update open questions (#1005)
- consistently use "discourage" instead of "deprecate" for the zero-fill
  behaviour in the existing constructors
- make the implied assumption of positional-only parameters explicit
2019-04-22 01:59:45 +10:00
Petr Viktorin a81fa94825 PEP 573: Defer to Python 3.9 (#1006) 2019-04-21 15:03:51 +10: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
Brett Cannon 0e90d579b3
Make Brett Cannon the BD for PEP 487 on behalf of the steering council (#1003) 2019-04-17 16:56:08 -07:00
Brett Cannon 48fbd24d5f
Make Brett Cannon the BD for PEP 387 on behalf of the SC (#1002) 2019-04-17 16:47:45 -07:00
Barry Warsaw 391c743cf2
Antoine volunteers to be the BDFL-Delegate 2019-04-17 13:58:40 -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
Barry Warsaw c1f8c85e6a
Christian has agreed to be the BDFL-Delegate 2019-04-17 12:15:36 -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
Nick Coghlan 1b0e8221be
PEP 432: Update based on the extracted PEP 587 API (#965)
The overall PEP 432 design is still a work in progress,
but the parts that Victor extracted out to PEP 587 should
be pretty solid at this point.
2019-04-16 23:58:12 +10:00
Guido van Rossum 7a0b6e7ef0
PEP 586: Small wording changes from review (#993) 2019-04-15 19:03:35 -07:00
Michael J. Sullivan c4c4bd7b9c PEP 591: some minor cleanups (#994)
- Fix some typos
 - Clarify that @final can't be used on non-method functions
2019-04-15 16:57:52 -07:00
Guido van Rossum 5165c953e6
Minor typo/grammar/wording/markup fixes (#991) 2019-04-15 07:50:48 -07:00
Petr Viktorin bb386b9b89 PEP 590: Add "Vectorcall" and "fastcall" keywords (#984)
- Add "Vectorcall" to the PEP title to make it easier to reference
- Mention "fastcall" in the abstract, for people familiar with the term
2019-04-14 10:51:37 +01:00
Michael J. Sullivan f3b44fbe4d PEP 591: Adding a final qualifier to typing (#990) 2019-04-12 17:17:52 -07:00
Sebastian Rittau 696664643d PEP 484: Add @type_check_only (#858)
Per discussion in python/typing#597.
2019-04-12 15:31:37 -07:00