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/
