* PEP 646: Simplify based on typing-sig discussions
Feature removals:
* Remove `Map` (to be added in a separate PEP)
* Remove support for all forms of concatenation other than simply prefixing of a single `TypeVarTuple` (fancier forms of concatenation to also be added in a separate PEP)
Semantic changes:
* Try switching `Ts` back to mean the 'unpacked' version (such that `Ts = int, str; Tuple[Ts] = Tuple[int, str]`) to see whether everything still works. (Might revert this, pending future discussion in typing-sig.)
* PEP 646: Clarify that prefixing is not allowed in Callable
* Update PEP 646 based on discussions in typing-sig
Semantic changes:
* Switch back to `Ts` meaning types packed in a `Tuple`
* Disallow unpacked usages of `Ts`
* Unparameterised `Tensor` behaves like `Tensor[Any, ...]`
Clarifications:
* `TypeVarTuple`s are invariant
* `TypeVarTuple`s can not be bound to unknown-length types (e.g. `Tuple[int, ...]`
* `TypeVarTuple`s can not be bound to unions of types
* Empty `*args` behaves like `Tuple[()]`
* `TypeVarTuple`s can not appear in slices
Readability changes:
* Reorder some sections for better flow
* Update PEP 646 with Eric's suggestions and other tweaks
Semantic changes:
* Revert to `*args: *Ts` for new behaviour, and `*args: Tuple[*Ts]` for old behaviour
Fixes:
* Unpacking in Aliases/Ideal Array Type sections
* Various typo/grammar fixes
Other:
* State explicitly that TypeVarTuples can be used in callback protocols
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.
The initial version of the PEP entrenched the tracing mode distinction,
and was worded accordingly.
Now that tracing mode is only relevant as a historical artifact that is
being eliminated, the wording should make that clear.
Also removes a stale mention of Python 3.9.
* PEP 12: Clean up and modernize guidelines.
The peps@python.org list has been shut down, and everything is done via
GitHub pull requests. Also, we no longer need some of the older steps,
and it's easier to read if some of the obscure/unusual options are
buried away in parentheses.
Open to discussion, can split this up if it's controversial.
* PEP 12: Describe number allocation system
* Derp, best to lead people correctly! Thanks Brett
Co-authored-by: Brett Cannon <brett@python.org>
* Don't exclude non-mailing-list discussion targets
Thanks Brett
Co-authored-by: Brett Cannon <brett@python.org>
* PEP 12: Be inclusive of non-mailing-list forums again
* PEP 12: Recommend the use of GitHub's issue tracker for questions
Co-authored-by: Brett Cannon <brett@python.org>
* requires that all uses of bare names be qualified with the user's intent
* ensures that all name binding operations in patterns use the as keyword
* drops alignment with iterable unpacking syntax (always requires square brackets)
* drops alignment with class instantiation syntax (defines a new dedicated instance attribute matching syntax instead)
Naming:
* Rename Tuple
* Rename Tensor -> Array (it's less jargony, and I think it's the more general term)
* Rename Expand -> Unpack (to be consistent with the terminology for normal tuples)
* Rename ArgTs -> Ts, ReturnT -> R
* Rename 'type tuple variable' -> 'type variable tuple'
Semantic:
* Explicitly state that a TypeVarTuple can hold *zero* or more types
* Explicitly state that TypeVarTuple doesn't support variance or bound yet
* Support Union[*Ts]
* Support concatenating multiple unpacked TypeVarTuple when there's no ambiguity
* Support aliases
* Remove support for class overloads; replace with overloads of individual methods
Pedagogical:
* Reorder introductory material to make it clearer how TypeVarTuples behave when not unpacked, and to make it clearer that using them without unpacking them is a perfectly valid thing to do
* Remove example of unpacking being used with a regular Tuple rather than a TypeVarTuple (my main reason for wanting to include it was to emphasise that a TypeVarTuple behaves like a Tuple, but I think this is emphasised better in previous sections now, and since I don't think it has any use cases, it seems better to remove it to keep things shorter and more to the point)
* Replace Tuple[*Ts] with just Ts (now that we've settled on Ts definitely meaning "A Tuple filled with types", writing Tuple[*Ts] is redundant - it's exactly the same as Ts, but with more keystrokes)
* State explicitly that TypeVarTuple can be used with Callable
* Changes args_to_tuples example to args_to_lists (so it's clearer where the Tuple comes from)
* Show more examples of where Map can be used
* Move section on nesting Map to the 'Rationale and Rejected Ideas' section (it's complicated enough to be too distracting if it were in the main section, and since there isn't an obvious use-case, we leave it as an optional feature)
* Add section on a full example of an array type
* Remove ideas for future PEPs (to reduce length)
* Add more detail on the range of type concatenations that are allowable
Other:
* Add Pradeep to the authors list, since he's contributed so much :)
* Add Eric Traut in the acknowledgements
* Update Post-History
* Fix some references
* Fix first Array example to remove the need for a cast
* Various wording tweaks
Matthew Rahtz
Brett Cannon
Stefano Borini
Hugo van Kemenade
Inada Naoki
Barry Warsaw
Dustin Ingram
Marti Raudsepp
Pablo Galindo
Kevin P. Fleming
Christopher Wilcox
Mario Corchero
Nick Coghlan
Pradyun Gedam
Steve Dower
Mark Shannon
Guido van Rossum
Ken Jin
Eric Traut
Chris Angelico
Mario Corchero
Larry Hastings
Ned Deily
방성범 (Bang Seongbeom)