- propose specific Grammar changes
- rename potential boolean circuit breakers so they read
better when using them to explain and/or behaviour
- operator.logical_or -> operator.true
- operator.logical_and -> operator.false
- discuss a problem Guido raised regarding inconsistency
between the proposed operator and conditional expressions
(I think it's fixable, but fixing it would have some
pretty significant consequences for the overall language)
- add today to Post-History
- if-else, and, or are now left alone
- else is introduced as a new short-circuiting binary operator
- "circuit breaking" is introduced as the operator and protocol name
- exists() builtin checks for existence
- missing() builtin checks for non-existence
- "not exists" gives a missing instance and vice-versa
- chained comparison is adjusted to use the new protocol when available
First draft of a proposal that blends PEP 335's concept of allowing
overloading of the logical binary operators with PEP 531's notion
of improved native support for tolerating missing data values.
* Replace emoji with C# spelling for operators.
* Remove some unnecessary alternative spellings.
* Add proper python code blocks.
* Other miscellany.
*Commit to a specific syntax*
I've removed all of the alternative syntax discussion and the
community poll. I expanded the reasoning for picking the spellings
that I did.
- proposed precondition operator is now "?then"
- discusses the possible use of mathematical existence notation
- discusses some of the implications of different design decisions
- assorted other fixes and clarifications
Based on the last round of PEP 505 discussions, I'm seeing a
lot more merit in the general idea, but have some strong opinions
on how to describe the concepts to current and new Python users.
Those opinions are different enough from what's currently in PEP
505 that I think writing a competing PEP is the most useful way to
articulate them.
Fixes https://github.com/python/typing/issues/303.
See also https://github.com/python/mypy/pull/2302 (which removes the restriction from mypy).
As a motivation, in Python one always can substitute expressions, so that if ``IntNode = Node[int]; IntNode()`` works, then it is reasonable to also allow ``Node[int]``, but say that the first way is preferred.
Ned Deily
Eric V. Smith
Brett Cannon
Yury Selivanov
Steve Dower
Ivan Levkivskyi
Nathaniel J. Smith
Nick Coghlan
Guido van Rossum
Andrew Svetlov
INADA Naoki
Mark E. Haase
JimJJewett
Fabian Neundorf
Mariatta
Barry Warsaw