On Wed, 4 May 2022 at 13:29, 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?
Well, there are at least two libraries on PyPI, and at least one of them (glom) has been around for some time, but neither is particularly well known. This suggests to me that this isn't an issue that people are routinely asking "how do I solve this problem?" (or if they are, their requirements are sufficiently different that no one solution has emerged as "the obvious one"). So I struggle to imagine that there's a significant group of users who are all waiting for a solution in the stdlib, and for whom installing a library from PyPI is a problem. > 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). Well, that's not the *only* other way to solve the problem. Using a library from PyPI is an entirely reasonable solution as well. You seem to be discounting that as an option. Can you explain what's wrong with using a library off PyPI? Just to be clear, I'm one of the stronger supporters of having an extensive stdlib, so when I say this, I'm *not* saying that everything should be on PyPI. But it would be good if you could articulate your reasons for why this specific functionality is less usable as an external library, that justify it being in the stdlib. > 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. I agree with you somewhat on this point, I don't think anyone has successfully demonstrated that library-based solutions aren't sufficient here. But library-based doesn't necessarily mean "in the stdlib". Paul _______________________________________________ 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/UA5CWF2Z4ZKYO35CZGRGZWQFGGL6AQ2W/ Code of Conduct: http://python.org/psf/codeofconduct/
