Not coalescing around None-aware

Posted Dec 23, 2022 14:46 UTC (Fri) by shironeko (subscriber, #159952)
In reply to: Not coalescing around None-aware by rrolls
Parent article: Not coalescing around None-aware

if setting variables to a default value once beforehand is already untrackably messy, how would the programmer have any hope of tracking everywhere the variable is used and "may" be none? the first approach clearly have less or equal things to track than the second approach.

Not coalescing around None-aware

Posted Dec 23, 2022 17:44 UTC (Fri) by rrolls (subscriber, #151126) [Link] (5 responses)

Naturally if you're referring to it more than once you'd resolve the defaults separately beforehand.

There are plenty of examples in the PEP that demonstrate where ?? would be useful far better than I could.

Not coalescing around None-aware

Posted Dec 23, 2022 19:30 UTC (Fri) by shironeko (subscriber, #159952) [Link] (4 responses)

yes I've gone through all the examples in the PEP, pretty much all of them can be solved by not using none and improving the language some other way.

One common example in there is the practice of foo(optional=None) and then assigning a default value to optional right afterwards. clearly this calls for improving the default value syntax not the none operator because it'll still be ugly, just shorter. Maybe the default syntax should accept function call, then we get the added benefit of having the function signature more self documenting than just None and have to figure out what that means.

Not coalescing around None-aware

Posted Dec 24, 2022 6:35 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (3 responses)

> One common example in there is the practice of foo(optional=None) and then assigning a default value to optional right afterwards. clearly this calls for improving the default value syntax not the none operator because it'll still be ugly, just shorter. Maybe the default syntax should accept function call, then we get the added benefit of having the function signature more self documenting than just None and have to figure out what that means.

Improving the default syntax has been discussed endlessly, but it's probably never going to happen, because both of the obvious approaches are non-starters:

1. You can't introduce a new default syntax, because then you would have two default syntaxes, and that has generally been regarded as inferior to the status quo.
2. You can't modify the semantics of the existing syntax, both because it would break backwards compatibility, and also because there is an actual use case for eager evaluation of default values (namely, forcing a closure to eagerly evaluate its closed-over variables) and so you would need to provide an alternative for that. The total amount of ugliness in the language would probably increase.

Not coalescing around None-aware

Posted Dec 24, 2022 6:42 UTC (Sat) by shironeko (subscriber, #159952) [Link] (2 responses)

I'm not quite sure how this could be not backwards compatible because it's allowing something that was not valid python before. I think I'm probably misunderstanding something, can you give an example on how this would cause existing code to break?

Not coalescing around None-aware

Posted Dec 24, 2022 9:12 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

My interpretation of your comment is that you want to allow us to write an arbitrary expression as the default value, and lazily evaluate that expression when the function is called. It is already legal Python syntax to put arbitrary expressions as the default value, so this example will demonstrate the backwards incompatibility of the second half (lazy evaluation) only:

lazy = []
eager = []
for i in range(5):
    lazy.append(lambda: i)
    eager.append(lambda x=i: x)

print(lazy[2]())  # Prints 4
print(eager[2]())  # Prints 2

If you make x=i evaluate lazily, then both versions would print 4. This is backwards incompatible, and it also leaves us with no obvious way to get the 2 behavior instead of the 4 behavior. (Of course, it can be done, but it requires additional boilerplate that nobody should have to write.)

On the other hand, if you are proposing some new syntax that doesn't look like a "regular" Python expression (or somehow "decorates" the default value to indicate that it should be evaluated lazily)... nobody wants to deal with two different default value syntaxes in the same language. That way lies madness.

Not coalescing around None-aware

Posted Dec 24, 2022 9:14 UTC (Sat) by smurf (subscriber, #17840) [Link]

Umm, we're talking about default values to procedure/method arguments here. Of course they're valid Python. They just have semantics that are sub-optimal in THIS case.

Personally I'd just re-purpose the Walrus operator to do lazy evaluation when you (ab)use it in a "def" declaration, though that's probably a non-starter given the past contentious discussion on that topic.