[Python-ideas] PEP 531: Existence checking operators

[Ryan Birmingham]

I certainly like the concept, but I worry that use of  __exists__() could
generalize it a bit beyond what you're intending in practice. It seems like
this should only check if an object exists, and that adding the magic
method would only lead to confusion.

-Ryan Birmingham

On 28 October 2016 at 04:30, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Hi folks,
>
> After the recent discussions of PEP 505's null-coalescing operator
> (and the significant confusion around why anyone would ever want a
> feature like that), I was inspired to put together a competing
> proposal that focuses more on defining a new "existence checking"
> protocol that generalises the current practicises of:
>
> * obj is not None (many different use cases)
> * obj is not Ellipsis (in multi-dimensional slicing)
> * obj is not NotImplemented (in operand coercion)
> * math.isnan(value)
> * cmath.isnan(value)
> * decimal.getcontext().is_nan(value)
>
> Given that protocol as a basis, it then proceeds to define "?then" and
> "?else" as existence checking counterparts to the truth-checking "and"
> and "or", as well as "?.", "?[]" and "?=" as abbreviations for
> particular idiomatic uses of "?then" and "?else".
>
> I think this approach frames the discussion in a more productive way,
> as it gives us a series of questions to consider in order where a
> collective answer of "No" at any point would be enough to kill this
> particular proposal (or parts of it), but precisely *where* we say
> "No" will determine which future alternatives might be worth
> considering:
>
> 1. Do we collectively agree that "existence checking" is a useful
> general concept that exists in software development and is distinct
> from the concept of "truth checking"?
> 2. Do we collectively agree that the Python ecosystem would benefit
> from an existence checking protocol that permits generalisation of
> algorithms (especially short circuiting ones) across different "data
> missing" indicators, including those defined in the language
> definition, the standard library, and custom user code?
> 3. Do we collectively agree that it would be easier to use such a
> protocol effectively if existence-checking equivalents to the
> truth-checking "and" and "or" control flow operators were available?
>
> Only if we have at least some level of consensus on the above
> questions regarding whether or not this is a conceptual modeling
> problem worth addressing at the language level does it then make sense
> to move on to the more detailed questions regarding the specific
> proposed *solution* to the problem in the PEP:
>
> 4. Do we collectively agree that "?then" and "?else" would be
> reasonable spellings for such operators?
> 5a. Do we collectively agree that "access this attribute only if the
> object exists" would be a particularly common use case for such
> operators?
> 5b. Do we collectively agree that "access this subscript only if the
> object exists" would be a particularly common use case for such
> operators?
> 5c. Do we collectively agree that "bind this value to this target only
> if the value currently bound to the target nominally doesn't exist"
> would be a particularly common use case for such operators?
> 6a. Do we collectively agree that 'obj?.attr' would be a reasonable
> spelling for "access this attribute only if the object exists"?
> 6b. Do we collectively agree that 'obj?[expr]' would be a reasonable
> spelling for "access this subscript only if the object exists"?
> 6c. Do we collectively agree that 'target ?= expr' would be a
> reasonable spelling for "bind this value to this target only if the
> value currently bound to the target nominally doesn't exist"?
>
> To be clear, this would be a *really* big addition to the language
> that would have significant long term ramifications for how the
> language gets taught to new developers.
>
> At the same time, asking whether or not an object represents an
> absence of data rather than the truth of a proposition seems to me
> like a sufficiently common problem in a wide enough variety of domains
> that it may be worth elevating to the level of giving it dedicated
> syntactic support.
>
> Regards,
> Nick.
>
> Rendered HTML version: https://www.python.org/dev/peps/pep-0531/
> ===============================
>
> PEP: 531
> Title: Existence checking operators
> Version: $Revision$
> Last-Modified: $Date$
> Author: Nick Coghlan <ncoghlan at gmail.com>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 25-Oct-2016
> Python-Version: 3.7
> Post-History: 28-Oct-2016
>
> Abstract
> ========
>
> Inspired by PEP 505 and the related discussions, this PEP proposes the
> addition
> of two new control flow operators to Python:
>
> * Existence-checking precondition ("exists-then"): ``expr1 ?then expr2``
> * Existence-checking fallback ("exists-else"): ``expr1 ?else expr2``
>
> as well as the following abbreviations for common existence checking
> expressions and statements:
>
> * Existence-checking attribute access:
>   ``obj?.attr`` (for ``obj ?then obj.attr``)
> * Existence-checking subscripting:
>   ``obj?[expr]`` (for ``obj ?then obj[expr]``)
> * Existence-checking assignment:
>   ``value ?= expr`` (for ``value = value ?else expr``)
>
> The common ``?`` symbol in these new operator definitions indicates that
> they
> use a new "existence checking" protocol rather than the established
> truth-checking protocol used by if statements, while loops, comprehensions,
> generator expressions, conditional expressions, logical conjunction, and
> logical disjunction.
>
> This new protocol would be made available as ``operator.exists``, with the
> following characteristics:
>
> * types can define a new ``__exists__`` magic method (Python) or
>   ``tp_exists`` slot (C) to override the default behaviour. This optional
>   method has the same signature and possible return values as ``__bool__``.
> * ``operator.exists(None)`` returns ``False``
> * ``operator.exists(NotImplemented)`` returns ``False``
> * ``operator.exists(Ellipsis)`` returns ``False``
> * ``float``, ``complex`` and ``decimal.Decimal`` will override the
> existence
>   check such that ``NaN`` values return ``False`` and other values
> (including
>   zero values) return ``True``
> * for any other type, ``operator.exists(obj)`` returns True by default.
> Most
>   importantly, values that evaluate to False in a truth checking context
>   (zeroes, empty containers) will still evaluate to True in an existence
>   checking context
>
>
> Relationship with other PEPs
> ============================
>
> While this PEP was inspired by and builds on Mark Haase's excellent work in
> putting together PEP 505, it ultimately competes with that PEP due to
> significant differences in the specifics of the proposed syntax and
> semantics
> for the feature.
>
> It also presents a different perspective on the rationale for the change by
> focusing on the benefits to existing Python users as the typical demands of
> application and service development activities are genuinely changing. It
> isn't an accident that similar features are now appearing in multiple
> programming languages, and while it's a good idea for us to learn from how
> other
> language designers are handling the problem, precedents being set elsewhere
> are more relevant to *how* we would go about tackling this problem than
> they
> are to whether or not we think it's a problem we should address in the
> first
> place.
>
>
> Rationale
> =========
>
> Existence checking expressions
> ------------------------------
>
> An increasingly common requirement in modern software development is the
> need
> to work with "semi-structured data": data where the structure of the data
> is
> known in advance, but pieces of it may be missing at runtime, and the
> software
> manipulating that data is expected to degrade gracefully (e.g. by omitting
> results that depend on the missing data) rather than failing outright.
>
> Some particularly common cases where this issue arises are:
>
> * handling optional application configuration settings and function
> parameters
> * handling external service failures in distributed systems
> * handling data sets that include some partial records
>
> It is the latter two cases that are the primary motivation for this PEP -
> while
> needing to deal with optional configuration settings and parameters is a
> design
> requirement at least as old as Python itself, the rise of public cloud
> infrastructure, the development of software systems as collaborative
> networks
> of distributed services, and the availability of large public and private
> data
> sets for analysis means that the ability to degrade operations gracefully
> in
> the face of partial service failures or partial data availability is
> becoming
> an essential feature of modern programming environments.
>
> At the moment, writing such software in Python can be genuinely awkward, as
> your code ends up littered with expressions like:
>
> * ``value1 = expr1.field.of.interest if expr1 is not None else None``
> * ``value2 = expr2["field"]["of"]["interest"] if expr2 is not None else
> None``
> * ``value3 = expr3 if expr3 is not None else expr4 if expr4 is not
> None else expr5``
>
> If these are only occasional, then expanding out to full statement forms
> may
> help improve readability, but if you have 4 or 5 of them in a row (which
> is a
> fairly common situation in data transformation pipelines), then replacing
> them
> with 16 or 20 lines of conditional logic really doesn't help matters.
>
> Expanding the three examples above that way hopefully helps illustrate
> that::
>
>     _expr1 = expr1
>     if _expr1 is not None:
>         value1 = _expr1.field.of.interest
>     else:
>         value1 = None
>     _expr2 = expr2
>     if _expr2 is not None:
>         value2 = _expr2["field"]["of"]["interest"]
>     else:
>         value2 = None
>     _expr3 = expr3
>     if _expr3 is not None:
>         value3 = _expr3
>     else:
>         _expr4 = expr4
>         if _expr4 is not None:
>             value3 = _expr4
>         else:
>             value3 = expr5
>
> The combined impact of the proposals in this PEP is to allow the above
> sample
> expressions to instead be written as:
>
> * ``value1 = expr1?.field.of.interest``
> * ``value2 = expr2?["field"]["of"]["interest"]``
> * ``value3 = expr3 ?else expr4 ?else expr5``
>
> In these forms, almost all of the information presented to the reader is
> immediately relevant to the question "What does this code do?", while the
> boilerplate code to handle missing data by passing it through to the output
> or falling back to an alternative input, has shrunk to two uses of the
> ``?``
> symbol and two uses of the ``?else`` keyword.
>
> In the first two examples, the 31 character boilerplate clause
> `` if exprN is not None else None`` (minimally 27 characters for a single
> letter
> variable name) has been replaced by a single ``?`` character, substantially
> improving the signal-to-pattern-noise ratio of the lines (especially if it
> encourages the use of more meaningful variable and field names rather than
> making them shorter purely for the sake of expression brevity).
>
> In the last example, two instances of the 21 character boilerplate,
> `` if exprN is not None`` (minimally 17 characters) are replaced with
> single
> characters, again substantially improving the signal-to-pattern-noise
> ratio.
>
> Furthermore, each of our 5 "subexpressions of potential interest" is
> included
> exactly once, rather than 4 of them needing to be duplicated or pulled out
> to a named variable in order to first check if they exist.
>
> The existence checking precondition operator is mainly defined to provide a
> clear conceptual basis for the existence checking attribute access and
> subscripting operators:
>
> * ``obj?.attr`` is roughly equivalent to ``obj ?then obj.attr``
> * ``obj?[expr]``is roughly equivalent to ``obj ?then obj[expr]``
>
> The main semantic difference between the shorthand forms and their expanded
> equivalents is that the common subexpression to the left of the existence
> checking operator is evaluated only once in the shorthand form (similar to
> the benefit offered by augmented assignment statements).
>
>
> Existence checking assignment
> -----------------------------
>
> Existence-checking assignment is proposed as a relatively straightforward
> expansion of the concepts in this PEP to also cover the common
> configuration
> handling idiom:
>
> * ``value = value if value is not None else expensive_default()``
>
> by allowing that to instead be abbreviated as:
>
> * ``value ?= expensive_default()``
>
> This is mainly beneficial when the target is a subscript operation or
> subattribute, as even without this specific change, the PEP would still
> permit this idiom to be updated to:
>
> * ``value = value ?else expensive_default()``
>
> The main argument *against* adding this form is that it's arguably
> ambiguous
> and could mean either:
>
> * ``value = value ?else expensive_default()``; or
> * ``value = value ?then value.subfield.of.interest``
>
> The second form isn't at all useful, but if this concern was deemed
> significant
> enough to address while still keeping the augmented assignment feature,
> the full keyword could be included in the syntax:
>
> * ``value ?else= expensive_default()``
>
> Alternatively, augmented assignment could just be dropped from the current
> proposal entirely and potentially reconsidered at a later date.
>
>
> Existence checking protocol
> ---------------------------
>
> The existence checking protocol is including in this proposal primarily to
> allow for proxy objects (e.g. local representations of remote resources)
> and
> mock objects used in testing to correctly indicate non-existence of target
> resources, even though the proxy or mock object itself is not None.
>
> However, with that protocol defined, it then seems natural to expand it to
> provide a type independent way of checking for ``NaN`` values in numeric
> types
> - at the moment you need to be aware of the exact data type you're working
> with
> (e.g. builtin floats, builtin complex numbers, the decimal module) and use
> the
> appropriate operation (e.g. ``math.isnan``, ``cmath.isnan``,
> ``decimal.getcontext().is_nan()``, respectively)
>
> Similarly, it seems reasonable to declare that the other placeholder
> builtin
> singletons, ``Ellipsis`` and ``NotImplemented``, also qualify as objects
> that
> represent the absence of data moreso than they represent data.
>
>
> Proposed symbolic notation
> --------------------------
>
> Python has historically only had one kind of implied boolean context: truth
> checking, which can be invoked directly via the ``bool()`` builtin. As
> this PEP
> proposes a new kind of control flow operation based on existence checking
> rather
> than truth checking, it is considered valuable to have a reminder directly
> in the code when existence checking is being used rather than truth
> checking.
>
> The mathematical symbol for existence assertions is U+2203 'THERE EXISTS':
> ``∃``
>
> Accordingly, one possible approach to the syntactic additions proposed in
> this
> PEP would be to use that already defined mathematical notation:
>
> * ``expr1 ∃then expr2``
> * ``expr1 ∃else expr2``
> * ``obj∃.attr``
> * ``obj∃[expr]``
> * ``target ∃= expr``
>
> However, there are two major problems with that approach, one practical,
> and
> one pedagogical.
>
> The practical problem is the usual one that most keyboards don't offer any
> easy
> way of entering mathematical symbols other than those used in basic
> arithmetic
> (even the symbols appearing in this PEP were ultimately copied & pasted
> from [3]_ rather than being entered directly).
>
> The pedagogical problem is that the symbols for existence assertions
> (``∃``)
> and universal assertions (``∀``) aren't going to be familiar to most people
> the way basic arithmetic operators are, so we wouldn't actually be making
> the
> proposed syntax easier to understand by adopting ``∃``.
>
> By contrast, ``?`` is one of the few remaining unused ASCII punctuation
> characters in Python's syntax, making it available as a candidate syntactic
> marker for "this control flow operation is based on an existence check,
> not a
> truth check".
>
> Taking that path would also have the advantage of aligning Python's syntax
> with corresponding syntax in other languages that offer similar features.
>
> Drawing from the existing summary in PEP 505 and the Wikipedia articles on
> the "safe navigation operator [1]_ and the "null coalescing operator" [2]_,
> we see:
>
> * The ``?.`` existence checking attribute access syntax precisely aligns
> with:
>
>   * the "safe navigation" attribute access operator in C# (``?.``)
>   * the "optional chaining" operator in Swift (``?.``)
>   * the "safe navigation" attribute access operator in Groovy (``?.``)
>   * the "conditional member access" operator in Dart (``?.``)
>
> * The ``?[]`` existence checking attribute access syntax precisely aligns
> with:
>
>   * the "safe navigation" subscript operator in C# (``?[]``)
>   * the "optional subscript" operator in Swift (``?[].``)
>
> * The ``?else`` existence checking fallback syntax semantically aligns
> with:
>
>   * the "null-coalescing" operator in C# (``??``)
>   * the "null-coalescing" operator in PHP (``??``)
>   * the "nil-coalescing" operator in Swift (``??``)
>
> To be clear, these aren't the only spelling of these operators used in
> other
> languages, but they're the most common ones, and the ``?`` symbol is the
> most
> common syntactic marker by far (presumably prompted by the use of ``?`` to
> introduce the "then" clause in C-style conditional expressions, which many
> of these languages also offer).
>
>
> Proposed keywords
> -----------------
>
> Given the symbolic marker ``?``, it would be syntactically unambiguous to
> spell
> the existence checking precondition and fallback operations using the same
> keywords as their truth checking counterparts:
>
> * ``expr1 ?and expr2`` (instead of ``expr1 ?then expr2``)
> * ``expr1 ?or expr2`` (instead of ``expr1 ?else expr2``)
>
> However, while syntactically unambiguous when written, this approach makes
> the code incredibly hard to *pronounce* (What's the pronunciation of "?"?)
> and
> also hard to *describe* (given reused keywords, there's no obvious
> shorthand
> terms for "existence checking precondition (?and)" and "existence checking
> fallback (?or)" that would distinguish them from "logical conjunction
> (and)"
> and "logical disjunction (or)").
>
> We could try to encourage folks to pronounce the ``?`` symbol as "exists",
> making the shorthand names the "exists-and expression" and the
> "exists-or expression", but there'd be no way of guessing those names
> purely
> from seeing them written in a piece of code.
>
> Instead, this PEP takes advantage of the proposed symbolic syntax to
> introduce
> a new keyword (``?then``) and borrow an existing one (``?else``) in a way
> that allows people to refer to "then expressions" and "else expressions"
> without ambiguity.
>
> These keywords also align well with the conditional expressions that are
> semantically equivalent to the proposed expressions.
>
> For ``?else`` expressions, ``expr1 ?else expr2`` is equivalent to::
>
>     _lhs_result = expr1
>     _lhs_result if operator.exists(_lhs_result) else expr2
>
> Here the parallel is clear, since the ``else expr2`` appears at the end of
> both the abbreviated and expanded forms.
>
> For ``?then`` expressions, ``expr1 ?then expr2`` is equivalent to::
>
>     _lhs_result = expr1
>     expr2 if operator.exists(_lhs_result) else _lhs_result
>
> Here the parallel isn't as immediately obvious due to Python's
> traditionally
> anonymous "then" clauses (introduced by ``:`` in ``if`` statements and
> suffixed
> by ``if`` in conditional expressions), but it's still reasonably clear as
> long
> as you're already familiar with the "if-then-else" explanation of
> conditional
> control flow.
>
>
> Risks and concerns
> ==================
>
> Readability
> -----------
>
> Learning to read and write the new syntax effectively mainly requires
> internalising two concepts:
>
> * expressions containing ``?`` include an existence check and may short
> circuit
> * if ``None`` or another "non-existent" value is an expected input, and the
>   correct handling is to propagate that to the result, then the existence
>   checking operators are likely what you want
>
> Currently, these concepts aren't explicitly represented at the language
> level,
> so it's a matter of learning to recognise and use the various idiomatic
> patterns based on conditional expressions and statements.
>
>
> Magic syntax
> ------------
>
> There's nothing about ``?`` as a syntactic element that inherently suggests
> ``is not None`` or ``operator.exists``. The main current use of ``?`` as a
> symbol in Python code is as a trailing suffix in IPython environments to
> request help information for the result of the preceding expression.
>
> However, the notion of existence checking really does benefit from a
> pervasive
> visual marker that distinguishes it from truth checking, and that calls for
> a single-character symbolic syntax if we're going to do it at all.
>
>
> Conceptual complexity
> ---------------------
>
> This proposal takes the currently ad hoc and informal concept of "existence
> checking" and elevates it to the status of being a syntactic language
> feature
> with a clearly defined operator protocol.
>
> In many ways, this should actually *reduce* the overall conceptual
> complexity
> of the language, as many more expectations will map correctly between truth
> checking with ``bool(expr)`` and existence checking with
> ``operator.exists(expr)`` than currently map between truth checking and
> existence checking with ``expr is not None`` (or ``expr is not
> NotImplemented``
> in the context of operand coercion, or the various NaN-checking operations
> in mathematical libraries).
>
> As a simple example of the new parallels introduced by this PEP, compare::
>
>     all_are_true = all(map(bool, iterable))
>     at_least_one_is_true = any(map(bool, iterable))
>     all_exist = all(map(operator.exists, iterable))
>     at_least_one_exists = any(map(operator.exists, iterable))
>
>
> Design Discussion
> =================
>
> Subtleties in chaining existence checking expressions
> -----------------------------------------------------
>
> Similar subtleties arise in chaining existence checking expressions as
> already
> exist in chaining logical operators: the behaviour can be surprising if the
> right hand side of one of the expressions in the chain itself returns a
> value that doesn't exist.
>
> As a result, ``value = arg1 ?then f(arg1) ?else default()`` would be
> dubious for
> essentially the same reason that ``value = cond and expr1 or expr2`` is
> dubious:
> the former will evaluate ``default()`` if ``f(arg1)`` returns ``None``,
> just
> as the latter will evaluate ``expr2`` if ``expr1`` evaluates to ``False``
> in
> a boolean context.
>
>
> Ambiguous interaction with conditional expressions
> --------------------------------------------------
>
> In the proposal as currently written, the following is a syntax error:
>
> * ``value = f(arg) if arg ?else default``
>
> While the following is a valid operation that checks a second condition if
> the
> first doesn't exist rather than merely being false:
>
> * ``value = expr1 if cond1 ?else cond2 else expr2``
>
> The expression chaining problem described above means that the argument
> can be
> made that the first operation should instead be equivalent to:
>
> * ``value = f(arg) if operator.exists(arg) else default``
>
> requiring the second to be written in the arguably clearer form:
>
> * ``value = expr1 if (cond1 ?else cond2) else expr2``
>
> Alternatively, the first form could remain a syntax error, and the
> existence
> checking symbol could instead be attached to the ``if`` keyword:
>
> * ``value = expr1 if? cond else expr2``
>
>
> Existence checking in other truth-checking contexts
> ---------------------------------------------------
>
> The truth-checking protocol is currently used in the following syntactic
> constructs:
>
> * logical conjunction (and-expressions)
> * logical disjunction (or-expressions)
> * conditional expressions (if-else expressions)
> * if statements
> * while loops
> * filter clauses in comprehensions and generator expressions
>
> In the current PEP, switching from truth-checking with ``and`` and ``or``
> to
> existence-checking is a matter of substituting in the new keywords,
> ``?then``
> and ``?else`` in the appropriate places.
>
> For other truth-checking contexts, it proposes either importing and
> using the ``operator.exists`` API, or else continuing with the current
> idiom
> of checking specifically for ``expr is not None`` (or the context
> appropriate
> equivalent).
>
> The simplest possible enhancement in that regard would be to elevate the
> proposed ``exists()`` API from an operator module function to a new builtin
> function.
>
> Alternatively, the ``?`` existence checking symbol could be supported as a
> modifier on the ``if`` and ``while`` keywords to indicate the use of an
> existence check rather than a truth check.
>
> However, it isn't at all clear that the potential consistency benefits
> gained
> for either suggestion would justify the additional disruption, so they've
> currently been omitted from the proposal.
>
>
> Defining expected invariant relations between ``__bool__`` and
> ``__exists__``
> ------------------------------------------------------------
> -----------------
>
> The PEP currently leaves the definition of ``__bool__`` on all existing
> types
> unmodified, which ensures the entire proposal remains backwards compatible,
> but results in the following cases where ``bool(obj)`` returns ``True``,
> but
> the proposed ``operator.exists(obj)`` would return ``False``:
>
> * ``NaN`` values for ``float``, ``complex``, and ``decimal.Decimal``
> * ``Ellipsis``
> * ``NotImplemented``
>
> The main argument for potentially changing these is that it becomes easier
> to
> reason about potential code behaviour if we have a recommended invariant in
> place saying that values which indicate they don't exist in an existence
> checking context should also report themselves as being ``False`` in a
> truth
> checking context.
>
> Failing to define such an invariant would lead to arguably odd outcomes
> like
> ``float("NaN") ?else 0.0`` returning ``0.0`` while ``float("NaN") or 0.0``
> returns ``NaN``.
>
>
> Limitations
> ===========
>
> Arbitrary sentinel objects
> --------------------------
>
> This proposal doesn't attempt to provide syntactic support for the
> "sentinel
> object" idiom, where ``None`` is a permitted explicit value, so a
> separate sentinel object is defined to indicate missing values::
>
>     _SENTINEL = object()
>     def f(obj=_SENTINEL):
>         return obj if obj is not _SENTINEL else default_value()
>
> This could potentially be supported at the expense of making the existence
> protocol definition significantly more complex, both to define and to use:
>
> * at the Python layer, ``operator.exists`` and ``__exists__``
> implementations
>   would return the empty tuple to indicate non-existence, and otherwise
> return
>   a singleton tuple containing a reference to the object to be used as the
>   result of the existence check
> * at the C layer, ``tp_exists`` implementations would return NULL to
> indicate
>   non-existence, and otherwise return a `PyObject *` pointer as the
>   result of the existence check
>
> Given that change, the sentinel object idiom could be rewritten as::
>
>     class Maybe:
>       SENTINEL = object()
>       def __init__(self, value):
>           self._result = (value,) is value is not self.SENTINEL else ()
>       def __exists__(self):
>           return self._result
>
>     def f(obj=Maybe.SENTINEL):
>         return Maybe(obj) ?else default_value()
>
> However, I don't think cases where the 3 proposed standard sentinel values
> (i.e.
> ``None``, ``Ellipsis`` and ``NotImplemented``) can't be used are going to
> be
> anywhere near common enough for the additional protocol complexity and the
> loss
> of symmetry between ``__bool__`` and ``__exists__`` to be worth it.
>
>
> Specification
> =============
>
> The Abstract already gives the gist of the proposal and the Rationale gives
> some specific examples. If there's enough interest in the basic idea, then
> a
> full specification will need to provide a precise correspondence between
> the
> proposed syntactic sugar and the underlying conditional expressions that is
> sufficient to guide the creation of a reference implementation.
>
> ...TBD...
>
>
> Implementation
> ==============
>
> As with PEP 505, actual implementation has been deferred pending
> in-principle
> interest in the idea of adding these operators - the implementation isn't
> the hard part of these proposals, the hard part is deciding whether or not
> this is a change where the long term benefits for new and existing Python
> users
> outweigh the short term costs involved in the wider ecosystem (including
> developers of other implementations, language curriculum developers, and
> authors of other Python related educational material) adjusting to the
> change.
>
> ...TBD...
>
>
> References
> ==========
>
> .. [1] Wikipedia: Safe navigation operator
>    (https://en.wikipedia.org/wiki/Safe_navigation_operator)
>
> .. [2] Wikipedia: Null coalescing operator
>    (https://en.wikipedia.org/wiki/Null_coalescing_operator)
>
> .. [3] FileFormat.info: Unicode Character 'THERE EXISTS' (U+2203)
>    (http://www.fileformat.info/info/unicode/char/2203/index.htm)
>
>
> Copyright
> =========
>
> This document has been placed in the public domain under the terms of the
> CC0 1.0 license: https://creativecommons.org/publicdomain/zero/1.0/
>
>
> ..
>    Local Variables:
>    mode: indented-text
>    indent-tabs-mode: nil
>    sentence-end-double-space: t
>    fill-column: 70
>    coding: utf-8
>    End:
>
>
>
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161028/55c95a43/attachment-0001.html>