I disagree with a couple of the states benefits.
I find code which allows for nulls (Nones in Python) harder to read at a higher level. Now I have to consider many values may be null, instead of just the type they are in the positive case.
Consider the following:
a = b?.c?.d?.e
If a is null, was b, c, d or e null? I have run across this many times in JavaScript/Typescript (JS/TS), meaning I have to inspect each value to see which caused the null, ending up with the very if-statements this proposals tries to replace.
I find code with more nulls flying around less safe, with types more fluid. After years of use of both languages, JS/TS feel less reliable to me due to this, whereas Python I have more confidence in the type (or shape, when I’m duck-typing).
Making nulls more ubiquitous means every value must be considered as possibly null unless explicitly guarded. I find Python’s current idiom where shapes are stronger to be safer.
I don’t think the use of question mark ? is a problem in this proposal, as other languages have already applied it for this use, and the character evokes feelings of “maybe”.
In the case of ORMs having data-classes with optional attributes, I prefer to use ternaries or if-statements as they’re more explicit and readable, and short-circuiting for use:
if outfit.shirt:
print(outfit.shirt.colour)
main_colour = (outfit.shirt or Shirt.default()).colour or Colour.default()
PS: sorry if I’m rehashing points already made in the previous discussions: no one has responded in this topic to all of the criticisms of the proposals in those discussions, so I don’t know if they’ve been considered.
One thing that has changed since those discussions is the maturity of the operator in JS/TS, meaning we can gather knowledge from there.