create boolean

F

Fencer

Hi, I need a boolean b to be true if the variable n is not None and not
an empty list, otherwise b should be false.
I ended up with:
b = n is not None and not not n
which seems to work but is that normally how you would do it?
It can be assumed that n is always None or a list that might be empty

- Fencer
 
L

Lie Ryan

Fencer said:
Hi, I need a boolean b to be true if the variable n is not None and not
an empty list, otherwise b should be false.
I ended up with:
b = n is not None and not not n
which seems to work but is that normally how you would do it?
It can be assumed that n is always None or a list that might be empty

- Fencer

The literal translation of that would be:

if n is not None and n != []:
b = True
else:
b = False

it is a bit verbose, so one might want to find something shorter

b = True if n is not None and n != [] else False

I always feel if and in-line if to be easier and more readable than
short-circuited operations.
 
P

Paul Rubin

Fencer said:
Hi, I need a boolean b to be true if the variable n is not None and
not an empty list, otherwise b should be false....
It can be assumed that n is always None or a list that might be empty

b = bool(n)
 
A

Andre Engels

Putting in the second comparison in makes the code match the
stated requirement.  Otherwise you have to start making
assumptions about what n might be besides None or the empty
list.

But the stated requirement already assumes that n is either None or a
list. The outcome is simply undefined when used on something that is
not None or a list. And it feels more in line with Python philosophy,
in particular with duck typing, to have 'list-like objects' (like sets
or tuples) behave like lists.
 
L

Lie Ryan

Scott said:
Lie said:
Fencer wrote:
The literal translation of that would be:
if n is not None and n != []:
b = True
else:
b = False
it is a bit verbose, so one might want to find something shorter
b = True if n is not None and n != [] else False
I always feel if and in-line if to be easier and more readable than
short-circuited operations.

How about:
b = None is not n != []

It is amazing to think about how rarely we consider is / is not as
a comparison operator. Also, and more reasonably, we often don't
consider "chaining" comparisons that are intransitive.

The fact that chaining operator is possible doesn't mean it must be
used. The only place I would use chained operator is for comparing
ranges of integer: 5 < x < 10, other than that, its use often reduce
readability.
 
A

Andre Engels

I didn't say that he hadn't authorized that assumption.  I just
said that the code does rely on such an assumption.  In my
experience, assumptions like that result broken code down the
road.

And assumptions like "when assumptions fail, it is save to go by the
letter of the requirement" don't?
 

Ask a Question

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.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top