Hi, On Wed, Oct 20, 2021 at 2:33 AM Michael Selik <m...@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-le...@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/R5NO5H5BCEIGEUCLPRE7WW5AEG5MRX3Q/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/7YUEB6KNXARSN6ULNULF7S7NTWJ73PW3/ Code of Conduct: http://python.org/psf/codeofconduct/
