Not coalescing around None-aware
Not coalescing around None-aware
Posted Dec 23, 2022 9:17 UTC (Fri) by ceplm (subscriber, #41334)In reply to: Not coalescing around None-aware by shironeko
Parent article: Not coalescing around None-aware
My problem with these operators (and a lot of what already happened to Python in the last few releases) is that it is similar to the Java discussion on the checked exceptions: it is completely dominated by people who didn’t understand the problem and they are trying to get rid of something which they consider just an annoyance.
For me all those if foo is None are code smell: a sign of poorly created API (perhaps unavoidable, because introduced from an external library). Similarly to the checked exceptions, when you start to look for improved syntax which would get rid of if is None then reconsider whole code around the problem and you may find that you need restructure it to express your algorithm better.
Posted Dec 23, 2022 11:05 UTC (Fri)
by adobriyan (subscriber, #30858)
[Link] (1 responses)
class X:
x1 = X()
results in
[] []
so passing None as default value in constructor is obvious solution. I'm not sure how often this is seen in practice but not code smell for sure.
Posted Dec 23, 2022 11:49 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Well, "language smell" then – as there really should be a way to instantiate the default option(s) at the time they are needed, not when the "def" statement is compiled.
Attempts to add a way to do this to Python have not succeeded so far.
Not coalescing around None-aware
l = []
x2 = X()
print(x1.l, x2.l)
x1.l.append(1)
print(x1.l, x2.l)
[1] [1]
Not coalescing around None-aware