PEP XXX: None-aware access operators [DRAFT]

[cdce8p]

Preview: https://cdce8p-python-peps--1.org.readthedocs.build/pep-0999/

[Dutcho]

In Motivation / Nested objects

• I don’t understand what you mean by “Would for example Machine overwrite __eq__ to return False”? Should that be __bool__ perhaps?
• The various examples are not equivalents for emails == [], which is falsey but not None; the first snippet handles that correctly, the is not None variants don’t, the try variant does (thanks to IndexError), the match does by list unpacking), but the ?. version doesn’t. For understanding I recommend consistency
• The “IDE” remark only became clear after some thinking. Suggest rephrasing to “would be able to help with identifying potentially None valued fields”

[Dutcho]

In Motivation / Other

• I suggest “plain sight”
• Presented pairs often aren’t exact equivalents
  • a and a.b == val: a might be a class instance with a __bool__ method returning False and val could be None
  • a and a.b and a.b.c: a could be falsey
  • d: dict | None

[picnixz]

I think this should mention what has changed since PEP-505. For instance, the rejected ideas are just copied from PEP-505. So I think you should contact past authors to ask them if you can just C/C their text.

[cdce8p]

Thanks for the review @Dutcho! I've addressed your comments in 092e36f.

The various examples are not equivalents for emails == [], which is falsey but not None

That's absolutely correct and I believe something which contributed to the confusion especially regarding the ?[ ] operator. I believe in order to avoid additional confusion, it makes sense to specify that emails is either None or a list with at least one item. That way we can ignore the IndexError for now. Yes, some of the examples would either knowingly or unknowingly work for it, e.g. match, but that's not the point in the motivation section. I've added a Note block to the draft to make this clear.

Presented pairs often aren’t exact equivalents

Yes, though that is by design. Something I'd like to point out with this section is that these patterns often hide in plain sight and while not identical, using ?. or ?[ ] is actually the intended logic behind these. The None-aware access operators just make it more clear / obvious what is going to happen. I've added another Note block to point that out.

[cdce8p]

I think this should mention what has changed since PEP-505. For instance, the rejected ideas are just copied from PEP-505. So I think you should contact past authors to ask them if you can just C/C their text.

Yes, some parts form the rejected ideas sections, are more or less identical to PEP 505. I've chosen to omit mentioning the original authors (e.g. in an Acknowledgements section) as he has changed his mind since writing PEP 505 so I'm not sure he'd want to be associated with a followup PEP.

His opinion if I understand it correctly, boils down to the Proliferation of None in code bases argument I listed in the Common objections section.

The link to his response regarding the status of PEP 505 at EuroPython 2022: https://youtu.be/0m2Cy5X6lcE?t=1521

[cdce8p]

I've open the PR in the python/peps repo. Going to close this one now.

• PEP 823: None-aware access operators python/peps#4798