thanks for writing all of this down and composing a PEP.
On 28.10.2016 10:30, Nick Coghlan wrote:
- 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.
- 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).
- 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. :)