C
contact.trigon
if (a, b) != (None, None):
or
if a != None != b:
Preference? Pros? Cons? Alternatives?
or
if a != None != b:
Preference? Pros? Cons? Alternatives?
if (a, b) != (None, None):
or
if a != None != b:
Preference? Pros? Cons? Alternatives?
equal None, or do you want to check for objects which are None?
if not (a is b is None): ...
if a is not b is not None: ...
FalseSteven D'Aprano said:if not (a is b is None): ...
Or if you prefer:
if a is not b is not None: ...
Johannes Bauer said:Is this an obfuscated coding contest? Why do you opt for a solution that
one has to at least think 2 seconds about when the simplest solution:
if (a is not None) or (b is not None):
is immediately understandable by everyone?
if (a, b) != (None, None):
if (a is not None) or (b is not None):
if a is not b is not None: ...
I agree with that. But
seems pretty straight-forward to me too. In fact, if anything, it seems
easier to understand than
Ah, der neueste und bis heute genialste Streich unsere großenI certainly agree that things like
belong in an obfuscated coding contest. Code gets read a lot more often
than it get written. Make it dead-ass simple to understand, and future
generations of programmers who inherit your code will thank you for it.
Absolutely.
Cheers,
Johannes
Roy Smith said:I agree with that. But
seems pretty straight-forward to me too. In fact, if anything, it seems
easier to understand than
I certainly agree that things like
belong in an obfuscated coding contest. Code gets read a lot more often
than it get written. Make it dead-ass simple to understand, and future
generations of programmers who inherit your code will thank you for it.
Yes, probably. I liked the original, too. If I were writing the code,
I'd probably try to aim to invert the condition though and simply do
if (a is None) and (b is None)
Which is pretty easy to understand for even a rookie programmer.
Ah, der neueste und bis heute genialste Streich unsere großenZumindest nicht öffentlich!
I agree with that. But
seems pretty straight-forward to me too. In fact, if anything, it
seems easier to understand than
And for cases where you have more than one or two things to test for
None-itude, you could use
if all(x is None for x in [a, b, c, d]):
do_something_if_theyre_all_None()
And for cases where you have more than one or two things to test
for None-itude, you could use
if all(x is None for x in [a, b, c, d]):
do_something_if_theyre_all_None()
I might have written that as:
if set([a, b, c, d]) == set(None)
That's even clearer if you happen to already have the items in an
iterable:
if set(conditions) == set(None)
Tim Chase said:And for cases where you have more than one or two things to test
for None-itude, you could use
if all(x is None for x in [a, b, c, d]):
do_something_if_theyre_all_None()
I might have written that as:
if set([a, b, c, d]) == set(None)
That's even clearer if you happen to already have the items in an
iterable:
if set(conditions) == set(None)
Though am I correct that your iteration tests for equality, while
mine tests for identity?
Also, my version bails early in the event
quitting early is possible. That's particularly useful in the case
of doing something like
if all(x() is None for x in [func1, func2, func3, costly_func]):
do_something()
if (a, b) != (None, None):
or
if a != None != b:
Preference? Pros? Cons? Alternatives?
Though am I correct that your iteration tests for equality, while
mine tests for identity? Also, my version bails early in the event
quitting early is possible. That's particularly useful in the case
of doing something like
if all(x() is None for x in [func1, func2, func3, costly_func]):
do_something()
Dave Angel:
...we'll find that two of the alternatives are not even equivalent.
Is this an obfuscated coding contest? Why do you opt for a solution that
one has to at least think 2 seconds about when the simplest solution:
if (a is not None) or (b is not None):
is immediately understandable by everyone?
Though am I correct that your iteration tests for equality, while
mine tests for identity? Also, my version bails early in the
event quitting early is possible. That's particularly useful in
the case of doing something like
if all(x() is None for x in [func1, func2, func3, costly_func]): ^^^
do_something()
Presumably you mean to actually call those functions, as checking
the identity of a costly function is still cheap
Though am I correct that your iteration tests for equality, while
mine tests for identity? Also, my version bails early in the
event quitting early is possible. That's particularly useful in
the case of doing something like
if all(x() is None for x in [func1, func2, func3, costly_func]): ^^^
do_something()
Presumably you mean to actually call those functions, as checking
the identity of a costly function is still cheap
Which is what I do...calling only those necessary until the all/any
condition has been met.
If you create the list of things to iterate over by calling them as
you create the list, then you don't save much of anything. If you
only call until one of them breaks the any/all construct, you save
all the subsequent function calls.
I certainly agree that things like
belong in an obfuscated coding contest.
Apart from the fact that I got it wrong (that's what happens when I post
at 6am after being up all night, thanks for the correction Lele), if you
consider chained comparisons to be "obfuscated", I think you're not
really fluent at Python. The OP even suggested `a != None != b` so I
think that (s)he at least understands chained comparisons.
However, I agree with Johannes that inverted conditions (using "not") are
sometimes harder to reason about than "regular" conditions.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.