Hi, On Wed, Oct 20, 2021 at 2:33 AM Michael Selik <mike@quantami.com> wrote:
In case it saves anyone a couple clicks: https://www.python.org/dev/peps/pep-0463/
I also prefer more syntactic help with exceptions, rather than more syntax emphasizing None's uniqueness.
Me too, but could you provide me an example where try-except approach is more readable when trying to chain attribute lookups (like in the database book-publisher-owner example I have provided before).
None and its ilk often conflate too many qualities. For example, is it missing because it doesn't exist, it never existed, or because we never received a value, despite knowing it must exist?
I think that a code where those three qualities happen all at once is in fact a bad code design. But the truth is that None has been and will be used to denote each of those qualities when writing a code because of its ease of use in a normal workflow, where time constraints are tight.
The languages SAS and R support at least 27 varieties of NA, allowing un-tagged, and tagged with the letters A-Z to help someone create distinctions between different kinds of nothingness. IEEE-754 allows about 16 million possible NaNs, which I believe was intended to allow floating point instructions to pass error messages along.
If the motivation for this operator is chained lookups, how about adding a feature to the operator module, first? It seems natural to add a keyword-only argument to `attrgetter`, and it's a lighter touch than implementing a new operator. If use becomes widespread, that gives more weight to PEP 505.
def attrgetter(*attrs, none_aware=False)
https://docs.python.org/3/library/operator.html#operator.attrgetter
Apologies if attrgetter has already been discussed. I didn't see mention of it in PEP 505.
I remember using inhouse solution like this at a certain workplace - a method accepting list of string arguments and an object, returning the value being the result of chained attribute access. And it worked all right. The problem I have with such approaches is that the name of the attrs are passed as strings. This makes it less practical in day-to-day situations when writing code. Automated class refactors, available in most of the IDEs also seem to not be able to support such field renames, whereas attribute lookup via `.` is properly detected. The same goes with context help available in most IDEs - you'll get no useful information when writing a string (IDE does not know if you are trying to write a name of the class' field), whereas when using the dot this works. And it'll probably be implemented for maybe-dot operator in no time looking at other languages' support.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/R5NO5H5B... Code of Conduct: http://python.org/psf/codeofconduct/