On Wed, 4 May 2022 at 22:32, Dr. Guta Gábor <gabor.g...@proinbox.com> wrote: > > > I'm not sure there's enough need for this that it should be in the > > stdlib. And I'm certain it isn't sufficiently common to justify being > > a builtin. > How 'enough need' can be measured? The other way to solve this problem is to > have null-conditional access operators ?. and ?[] like in C# (i.e. a.b.c can > be written to a?.b?.c to be prone to None values). I don't think that > null-conditional operators are Pythonic, but I guess if an other language has > a complete set of operators around a problem, it could be something that > interest lots of people. >
You may find PEP 505 interesting, then. https://peps.python.org/pep-0505/ Also possibly of interest is PEP 463 for another approach, where you just let the exception happen where it happens, then catch it and provide a value: https://peps.python.org/pep-0463/ For the simple case of "here's a series of attribute/item lookups, if you ever get AttributeError/LookupError, return this default", it's not too hard to make your own function. "Enough need" can be measured in a few places, but here are some questions that might guide that measurement: 1) How frequently do people write (some version of) this function? 1a) Can all variants of the function be cleanly provided by a single stdlib function? 2) Does the feature have subtleties that are easy to get wrong, and thus people write buggy versions of it without realising it? 3) Does the lack of the feature cause code to be significantly less readable? 4) Is code less secure and/or does it suffer from encapsulation breakage when this is done manually? (See, for instance, f-strings vs .format_map().) In this particular case, I've certainly made versions of this function before. But they often have slightly different rules, like "if not found, insert an empty dict at that point and keep going", or "after making any change, save everything to a JSON file" etc. So it has some weak justification on point 1, but loses part of that on 1a. Overall, I think this is something that has enough variations to be best done as a personal toolkit function, and it doesn't need any special syntax or anything. The broader (and also narrower) proposals in PEP 505 and 463 have stronger justifications, but also greater consequences. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FGGGJMCNJ3LXDTQE4QTVDALPPQZAWUC3/ Code of Conduct: http://python.org/psf/codeofconduct/
