Re: [Python-ideas] PEP 531: Existence checking operators

[David Mertz]

On Sat, Oct 29, 2016 at 11:44 PM, Stephan Hoyer  wrote:

> I'm have more mixed fillings on testing for NaNs. NaNs propagate, so
> explicit testing is rarely needed. Also, in numerical computing we usually
> work with arrays of NaN, so operator.exists() and all this nice syntax
> would not be a substitute for numpy.isnan or pandas.isnull.
>

NaN's *usually* propagate.  The NaN domain isn't actually closed under IEEE
754.

>>> nan, inf = float('nan'), float('inf')
>>> import math
>>> nan**0
1.0
>>> math.hypot(nan, inf)
inf
>>> min(1, nan)
1

The last one isn't really mandated by IEEE 754, and is weird when you
consider `min(nan, 1)`.


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Nick Coghlan]

On 29 October 2016 at 21:44, Steven D'Aprano  wrote:
> On Fri, Oct 28, 2016 at 06:30:05PM +1000, Nick Coghlan wrote:
>
> [...]
>> 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"?
>
> Not speaking for "we", only for myself: of course.
>
>
>> 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?
>
> Maybe, but probably not.
>
> Checking for "data missing" or other sentinels is clearly an important
> thing to do, but it remains to be seen whether (1) it should be
> generalised and (2) there is a benefit to making it a protocol.
>
> My sense so far is that generalising beyond None is YAGNI. None of the
> other examples you give strike me as common enough to justify special
> syntax, or even a protocol. I'm not *against* the idea, I just remain
> unconvinced.

I considered this the weakest link in the proposal when I wrote it,
and the discussion on the list has persuaded me that it's not just a
weak link, it's a fatal flaw. Accordingly, I've withdrawn the PEP, and
explained why with references back to this discussion:
https://github.com/python/peps/commit/9a70e511ada63b976699bbab9da142379340758c

However, as noted there, I find the possible link back to the rejected
boolean operator overloading proposal in PEP 335 interesting, so I'm
going to invest some time in writing that up to the same level as I
did the existence checking one (i.e. Abstract, Rationale & design
discussion, without a full specification or reference implementation
yet).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Ryan Gonzalez]

On Oct 28, 2016 3:30 AM, "Nick Coghlan"  wrote:
> *snip*
>
> 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"?

I'd hope so!

> 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?

I {%think_string if think_string is not None else 'think'%} so.

> *snip*
> 4. Do we collectively agree that "?then" and "?else" would be
> reasonable spellings for such operators?

Personally, I find that kind of ugly. What's wrong with just ? instead of
?else?

> 5a. Do we collectively agree that "access this attribute only if the
> object exists" would be a particularly common use case for such
> operators?

Pretty sure I've done this like a zillion times.

> 5b. Do we collectively agree that "access this subscript only if the
> object exists" would be a particularly common use case for such
> operators?

I haven't really ever had to do this exactly, but it makes sense.

> 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?

Yes. I see stuff like this a lot:

if x is not None:
x = []

> 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"?
>

' '.join(['Yes!']*3)

> 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 
> 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 

Re: [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  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 
> 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 

Re: [Python-ideas] PEP 531: Existence checking operators

[Steven D'Aprano]

On Fri, Oct 28, 2016 at 06:30:05PM +1000, Nick Coghlan wrote:

[...]
> 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"?

Not speaking for "we", only for myself: of course.


> 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?

Maybe, but probably not.

Checking for "data missing" or other sentinels is clearly an important 
thing to do, but it remains to be seen whether (1) it should be 
generalised and (2) there is a benefit to making it a protocol.

My sense so far is that generalising beyond None is YAGNI. None of the 
other examples you give strike me as common enough to justify special 
syntax, or even a protocol. I'm not *against* the idea, I just remain 
unconvinced.

But in particular, I *don't* think it is useful to introduce a concept 
similar to "truthiness" for existence. Duck-typing truthiness is useful: 
most of the time, I don't care which truthy value I have, only that it 
is truthy. But I'm having difficulty seeing when I would want to extend 
that to existence checking. The existence singletons are not generally 
interchangeable:

- operator dunder methods don't allow you to pass None instead
  NotImplemented, nor should they;

- (1 + nan) returns a nan, but (1 + Ellipsis) is an error;

- array[...] and array[NotImplemented] probably mean different things;

etc. More on this below.



> 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?

I'm not sure about this one.

[...]
> 4. Do we collectively agree that "?then" and "?else" would be
> reasonable spellings for such operators?

As in...

spam ?then eggs

meaning (conceptually):

if (spam is None or spam is NotImplemented 
or spam is Ellipsis or isnan(spam)):
return eggs
else:
return spam


I don't know... I can't see myself ever not caring which "missing" value 
I have, only that it is "missingly" (by analogy with "truthy").

If I'm writing an operator dunder method, I want to treat NotImplemented 
as "missing", but anything else (None, Ellipsis, NAN) would be a regular 
value. If I'm writing a maths function that supports NANs, I'd probably 
want to treat None, Ellipsis and NotImplemented as errors.

While I agree that "existence checking" is a concept, I don't think 
existence generalises in the same way Truth generalises to truthiness.


> 5a. Do we collectively agree that "access this attribute only if the
> object exists" would be a particularly common use case for such
> operators?

Yes, but only for the "object is not None" case. 

Note that NANs ought to support the same attributes as other 
floats. If they don't, I'd call it an error:

py> nan = float('nan')
py> nan.imag
0.0
py> nan.real
nan

So I shouldn't have to write:

y = x if x.isnan() else x.attr

I should be able to just write:

y = x.attr

and have NANs do the right thing. But if we have a separate, dedicated 
NA/Missing value, like R's NA, things may be different.



> 5b. Do we collectively agree that "access this subscript only if the
> object exists" would be a particularly common use case for such
> operators?

I'd be surprised if it were very common, but it might be "not uncommon".


> 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?

You mean a short-cut for:

if obj is None:
obj = spam


Sure, that's very common. But:

if (obj is None or obj is NotImplemented 
or obj is Ellipsis or isnan(obj)):
obj = spam


not so much.


> 6a. Do we collectively agree that 'obj?.attr' would be a reasonable
> spelling for "access this attribute only if the object exists"?

I like that syntax.


> 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"?

I don't hate either of those.


Thanks for writing the PEP!


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Steven D'Aprano]

On Sat, Oct 29, 2016 at 02:52:42PM +1000, Nick Coghlan wrote:
> On 29 October 2016 at 04:08, Mark Dickinson  wrote:
> > On Fri, Oct 28, 2016 at 9:30 AM, Nick Coghlan  wrote:
> >> [...] the current practicises of:
> >>
> >> * obj is not None (many different use cases)
> >> * obj is not Ellipsis (in multi-dimensional slicing)
> >
> > Can you elaborate on this one? I don't think I've ever seen an `is not
> > Ellipsis` check in real code.
> 
> It's more often checked the other way around: "if Ellipsis is passed
> in, then work out the multi-dimensional slice from the underlying
> object"
> 
> And that reflects the problem Paul and David highlighted: in any
> *specific* context, there's typically either only one sentinel we want
> to either propagate or else replace with a calculated value, or else
> we want to handle different sentinel values differently, which makes
> the entire concept of a unifying duck-typing protocol pragmatically
> dubious, and hence calls into question the idea of introducing new
> syntax for working with it.
> 
> On the other hand, if you try to do this as an "only None is special"
> kind of syntax, then any of the *other* missing data sentinels (of
> which we have 4 in the builtins alone, and 5 when you add the decimal
> module) end up being on much the same level as "arbitrary sentinel
> objects" in the draft PEP 531, which I would consider to be an
> incredibly poor outcome for a change as invasive as adding new syntax:
> https://www.python.org/dev/peps/pep-0531/#arbitrary-sentinel-objects

Hmmm. I see your point, but honestly, None *is* special. Even for 
special objects, None is even more special. Here are your examples 
again:

* 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)


Aside from the first, the rest are quite unusual:

- Testing for Ellipsis occurs in __getitem__, and not even
  always then.

- Testing for NotImplemented occurs in operator dunders,
  rarely if ever outside those methods. (You probably
  should never see NotImplemented except in an operator
  dunder.)

In both cases, this will be a useful feature for the writer of the 
class, not the user of the class.

- Testing for NAN is really only something of interest to 
  those writing heavily numeric code and not even always
  then.

You can go a LONG way with numeric code by just assuming that x is a 
regular number, and leaving NANs for "version 2". Especially in Python, 
which typically raises an exception where it could return a NAN. In 
other words, its quite hard to generate an unexpected NAN in Python.

So these examples are all quite special and of very limited 
applicability and quite marginal utility. My guess is that the majority 
of programmers will never care about these cases, and of those who do, 
they'll only need it quite rarely. (We use classes far more often than 
we write classes.)

But None is different. My guess is that every Python programmer, from 
the newest novice to the most experienced guru, will need to check for 
None, and likely frequently.

So my sense is that of all the use-cases for existence checking divide 
into two categories:

- checking for None (> 95%)
- everything else (< 5%)


I did a very rough search of the Python code on my system and found 
this:

is [not] None: 10955

is [not] Ellipsis: 13

is [not] NotImplemented: 285

is_nan( / isnan( : 470

which is not far from my guess.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Steven D'Aprano]

On Sat, Oct 29, 2016 at 03:03:22PM +1000, Nick Coghlan wrote:
> On 29 October 2016 at 01:46, Ryan Gonzalez  wrote:
> > On Oct 28, 2016 3:30 AM, "Nick Coghlan"  wrote:
> >> *snip*
> >> 4. Do we collectively agree that "?then" and "?else" would be
> >> reasonable spellings for such operators?
> >
> > Personally, I find that kind of ugly. What's wrong with just ? instead of
> > ?else?
> 
> When you see the expression "LHS ? RHS", there's zero indication of
> how to read it other than naming the symbol: "LHS question mark RHS".

/insert tongue firmly in cheek

We already have hash # bang ! splat * wack / and twiddle ~ so I suggest:

LHS huh? RHS



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Paul Moore]

On 29 October 2016 at 07:21, Nick Coghlan  wrote:
> A short-circuiting if-else protocol for arbitrary "THEN if COND else
> ELSE" expressions could then look like this:
>
> _condition = COND
> if _condition:
> _then = THEN
> if hasattr(_condition, "__then__"):
> return _condition.__then__(_then)
> return _then
> else:
> _else = ELSE
> if hasattr(_condition, "__else__"):
> return _condition.__else__(_else)
> return _else
>
> "and" and "or" would then be simplified versions of that, where the
> condition expression was re-used as either the "THEN" subexpression
> ("or") or the "ELSE" subexpression ("and").
>
> The reason I think this is potentially interesting in the context of
> PEPs 505 and 531 is that with that protocol defined, the
> null-coalescing "operator" wouldn't need to be a new operator, it
> could just be a new builtin that defined the appropriate underlying
> control flow:

This seems to have some potential to me. It doesn't seem massively
intrusive (there's a risk that it might be considered a step too far
in "making the language mutable", but otherwise it's just a new
extension protocol around an existing construct). The biggest downside
I see is that it could be seen as simply generalisation for the sake
of it. But with the null-coalescing / sentinel checking use case, plus
Greg's examples from the motivation section of PEP 335, there may well
be enough potential uses to warrant such a change.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Nick Coghlan]

On 29 October 2016 at 01:46, Ryan Gonzalez  wrote:
> On Oct 28, 2016 3:30 AM, "Nick Coghlan"  wrote:
>> *snip*
>> 4. Do we collectively agree that "?then" and "?else" would be
>> reasonable spellings for such operators?
>
> Personally, I find that kind of ugly. What's wrong with just ? instead of
> ?else?

When you see the expression "LHS ? RHS", there's zero indication of
how to read it other than naming the symbol: "LHS question mark RHS".

By contrast, "LHS ?then RHS" and "LHS ?else RHS" suggest the
pronunciations "LHS then RHS" and "LHS else RHS", which in turn are
potentially useful mnemonics for the full expansions "if LHS exists
then RHS else LHS" and "LHS if LHS exists else RHS". (Knowing that "?"
indicates an existence check is still something you'd have to learn,
but even without knowing that, the keywords could get you quite some
way towards correctly understanding what the construct means)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Sven R. Kunze]

Hi Nick,

thanks for writing all of this down and composing a PEP.

On 28.10.2016 10:30, Nick Coghlan wrote:

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"?


Right to your first question:

If I were to answer this in a world of black and white, I need to say 
yes. In the real-world it's more probably more like: you can map 
existence-checking to truth checking in most practical cases without any 
harm. So, it's usefulness and distinctness is quite reduced.




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?


I cannot speak for stdlib.

For custom user code, I may repeat what I already said: it might be 
useful the outer code working on the boundaries of systems as incoming 
data is hardly perfect. It might harm inner working of software if bad 
datastructure design permeates it and requires constant checking for 
existence (or other things).


Language definition-wise, I would say that if we can curb the issue 
described in the former paragraph, we'll be fine. Then it will shine 
through to all user code and the stdlib as well.


However, I don't think we are going to achieve this. The current 
language design does indeed favor clean datastructure design since messy 
datastructures are hard to handle in current Python. So, this naturally 
minimizes the usage of messy datastructures which is not a bad thing IMHO.


From my experience, clean datastructure design leads to easy-to-read 
clean code naturally. If people get their datastructures right in the 
inner parts of their software that's the most important step. If they 
subsequently would like to provide some convenience to their consumers 
(API, UI, etc.), that's a good cause. Still, it keeps the mess/checking 
in check plus it keeps it in a small amount of places (the boundary 
code). And it guides consumers also to clean usage (which is also not a 
bad thing IMHO).




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?


It's "just" shortcuts. So, yes.

However, as truth checking already is available, it might even increase 
confusion of what checking is to use. I think most developers need less 
but powerful tools to achieve their full potential.




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:


All in one, you can imagine that I am -1 on this.



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"?


I know, I don't need to mention this because question 1 to 3 are already 
problematic, but just my two cents here. To me it's unclear what the ? 
would refer to anyway: is it the obj that needs checking or is it the 
attribute/subscript access? I get the feeling that this is totally 
unclear from the syntax (also confirmed by Paul's post).



Still, thanks a lot for your work, Nice. :)

Regards,
Sven

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Mark Dickinson]

On Fri, Oct 28, 2016 at 9:30 AM, Nick Coghlan  wrote:
> [...] the current practicises of:
>
> * obj is not None (many different use cases)
> * obj is not Ellipsis (in multi-dimensional slicing)

Can you elaborate on this one? I don't think I've ever seen an `is not
Ellipsis` check in real code.

--
Mark
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[David Mertz]

On Fri, Oct 28, 2016 at 11:17 AM, Paul Moore  wrote:

> On 28 October 2016 at 15:40, Nick Coghlan  wrote:
> > I also don't think the idea is sufficiently general to be worthy of
> > dedicated syntax if it's limited specifically to "is not None" checks
> > - None's definitely special, but it's not *that* special. Unifying
> > None, NaN, NotImplemented and Ellipsis into a meta-category of objects
> > that indicate the absence of information rather than a specific value,
> > though?
>

First thing is that I definitely DO NOT want new SYNTAX to do this.  I
wouldn't mind having a new built-in function for this purpose if we could
get the call signature right.  Maybe it would be called 'exists()', but
actually something like 'valued()' feels like a better fit.

For the unusual case where the "null-coalescing" operation is what I'd
want, I definitely wouldn't mind something like Barry's proposal of
processing a string version of the expression.  Sure, *some* code editors
might not highlight it as much, but it's a corner case at most, to my
mind.  For that, I can type 'valued("x.y.z[w]", coalesce=ALL)' or whatever.


> However, I'm not convinced by your proposal that we can unify None, NaN,
> NotImplemented and Ellipsis in the way you suggest. I wouldn't expect
> a[1, None, 2] to mean the same as a[1, ..., 2], so why should an
> operator that tested for "Ellipsis or None" be useful?


I *especially* think None and nan have very different meanings.  A list of
[1.1, nan, 3.3] means that I have several floating point numbers, but one
came from a calculation that escaped the real domain.  A list with [1.1,
None, 3.3] means that I have already calculated three values, but am
marking the fact I need later to perform a calculation to figure out the
middle one.  These are both valid and important use cases, but they are
completely different from each other.

Yours, David...

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Paul Moore]

On 28 October 2016 at 15:40, Nick Coghlan  wrote:
> I also don't think the idea is sufficiently general to be worthy of
> dedicated syntax if it's limited specifically to "is not None" checks
> - None's definitely special, but it's not *that* special. Unifying
> None, NaN, NotImplemented and Ellipsis into a meta-category of objects
> that indicate the absence of information rather than a specific value,
> though? And also allowing developers to emulate the protocol for
> testing purposes? That's enough to pique my interest.

I think that's the key for me - new syntax for "is not None" types of
test seems of limited value (sure, other languages have such things,
but that's not compelling - the contexts are different). However, I'm
not convinced by your proposal that we can unify None, NaN,
NotImplemented and Ellipsis in the way you suggest. I wouldn't expect
a[1, None, 2] to mean the same as a[1, ..., 2], so why should an
operator that tested for "Ellipsis or None" be useful? Same for
NotImplemented - we're not proposing to allow rich comparison
operators to return None rather than NotImplemented. The nearest to
plausible is NaN vs None - but even there I don't see the two as the
same.

So, to answer your initial questions, in my opinion:

1. The concept of "checking for existence" is valid.
2. I don't see merging domain-specific values under a common "does not
exist" banner as useful. Specifically, because I wouldn't want the
"does not exist" values to become interchangeable.
3. I don't think there's much value in specific existence-checking
syntax, precisely because I don't view it as a good thing to merge
multiple domain-specific "does not exist", and therefore the benefit
is limited to a shorter way of saying "is not None".

As you noted, given my answers to 1-3, there's not much point in
considering the remaining questions. However, I do think that there's
another concept tied up in the proposals here, that of "short
circuiting attribute access / indexing". The call was for something
that said roughly "a.b if a is not None, otherwise None". But this is
only one form of this pattern - there's a similar pattern, "a.b if a
has an attribute b, otherwise None". And that's been spelled
"getattr(a, 'b', None)" for a long time now. The existence of getattr,
and the fact that no-one is crying out for it to be replaced with
syntax, implies to me that before leaping to a syntax solution we
should be looking at a normal function (possibly a builtin, but maybe
even just a helper). I'd like to see a justification for why "a.b if a
is not None, else None" deserves syntax when "a.b if a has attribute
b, else None" doesn't.

IMO, there's no need for syntax here. There *might* be some benefit in
some helper functions, though. The cynic in me wonders how much of
this debate is rooted in the fact that it's simply more fun to propose
new syntax, than to just write a quick helper and get on with coding
your application...

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 531: Existence checking operators

[Nick Coghlan]

On 28 October 2016 at 23:35, Ryan Birmingham  wrote:
> 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.

The same can be said of using __bool__, __nonzero__ and __len__ to
influence normal condition checks, and folks have proven to be pretty
responsible using those in practice (or, more accurately, when they're
used in problematic ways, users object, and they either eventually get
fixed, or folks move on to using other APIs that they consider better
behaved).

I also don't think the idea is sufficiently general to be worthy of
dedicated syntax if it's limited specifically to "is not None" checks
- None's definitely special, but it's not *that* special. Unifying
None, NaN, NotImplemented and Ellipsis into a meta-category of objects
that indicate the absence of information rather than a specific value,
though? And also allowing developers to emulate the protocol for
testing purposes? That's enough to pique my interest.

That's why these are my first two questions on the list - if we don't
agree on the core premise that there's a general concept here worth
modeling as an abstract protocol, I'm -1 on the whole idea.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] PEP 531: Existence checking operators

[Nick Coghlan]

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 
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.