[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