On Monday, July 23, 2018 at 8:24:45 AM UTC+2, Nicholas Cole wrote:
And that leads to a simple question: how many times does this actually > occur in real-world by python code? -- i.e. how many times do I want > to check the value of an existing label, and, finding it is None (and > None specifically), then assign it a value? > The PEP present a few examples. I think the compactness and clarity is really gained when doing a descent into an "attribute tree", where any (or selected) members can be None, like getting back to the example by Steven (spell-corrected, and expanded): meal = obj?.spam?.eggs.tomato?.cheese ?? "Mozzarella" Where, to put the proposal in even better light, I have assumed that eggs instances always have a tomato attributes (i.e. are never None). This is indeed much more compact that the current version, and arguably more readable (it's easier to parse once you know the syntax...but you have to know the special syntax that will be used for this kind of stuff only). The more you deepen the attribute access, the more you gain, but of course deep attribute access is not so common. The new operators may make deep attribute hierarchies (or deeply nested dicts/lists) slightly more common, and there also I do not think it's a good thing. For me the issue is that you gain little, each operator is very limited in scope, but at the same it's a operator, and those are introduced very carefully in Python (the resistance to line noise is high, it's one of the defining aspect of Python since forever). Each of them do not do enough IMHO, it's too special case and do not unlock especially powerfull/elegant/generalization reuse of other part of Python syntax. If you add something, it should play nice with the existing feature and solve nagging issues that broaden its appeal, or be powerful/general enough to justify it's existence on its own, or be so self-evident for a python user that it feels it's solving a bug. It's not the case for ?? and friends imho, far from it. Also, what happen if you want to modify your deep nested tree, not only access it? obj?.spam?.eggs.tomato?.cheese = "Mozzarella" will not work, and the proposal will not really help there (Or will it? I am not the proposer, I am strongly against it, so I could easily miss capabilities). If it's not possible, you lose a kind of symmetry, and that I do not like (orthogonality and symmetries are really nice in in a computer language, it helps quickly remembering the syntax as you are not cluttered by special cases and exceptions) Steven wrote: The Python community has always been conservative and resistant to change, but the level of conservativeness is now pushing towards fear of change rather than justifiable caution about adding new features that cannot easily be reverted. That's probably because you like this proposal. Really, compared to the 2.0 days, it seems that Python has became much less resistant to change. You have resistance even when proposing changes in standard library, or even the C interpreter internal, unseen in the Python layer, and imho it's often justified (what can be discussed is how arbitrary the actual selection of change is, but a general resistance is not a bad thing) It is a little bit optimistic to expect ?? and friends will be a walk in the park, especially after := ...
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/