# create boolean

Discussion in 'Python' started by Fencer, Mar 6, 2009.

1. ### FencerGuest

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

Fencer, Mar 6, 2009

2. ### Lie RyanGuest

Fencer wrote:
> 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.

Lie Ryan, Mar 7, 2009

3. ### Paul RubinGuest

Fencer <> writes:
> 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)

Paul Rubin, Mar 7, 2009
4. ### Andre EngelsGuest

On Sat, Mar 7, 2009 at 6:03 AM, Grant Edwards <> wrote:

> 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.

--

Andre Engels, Mar 7, 2009
5. ### Lie RyanGuest

Scott David Daniels wrote:
> Lie Ryan wrote:
>> 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.

>
> 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

Lie Ryan, Mar 8, 2009
6. ### Andre EngelsGuest

On Mon, Mar 9, 2009 at 12:48 AM, Grant Edwards <> wrote:

> 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

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

--