if isinstance(a, (list, some, other, types, i, accept)) and not a:
do_stuff
which was voted -1. I'm not sure if that's because readers objected to the strategy or thought the answer wasn't helpful as presented. I'll pretend it was the latter, since---whatever counts as "pythonic"---this is the correct strategy. Unless you've already ruled out, or are prepared to handle cases where a is, for example, False, you need a test more restrictive than just if not a:. You could use something like this:
if isinstance(a, numpy.ndarray) and not a.size:
do_stuff
elif isinstance(a, collections.Sized) and not a:
do_stuff
the first test is in response to @Mike's answer, above. The third line could also be replaced with:
elif isinstance(a, (list, tuple)) and not a:
if you only want to accept instances of particular types (and their subtypes), or with:
elif isinstance(a, (list, tuple)) and not len(a):
You can get away without the explicit type check, but only if the surrounding context already assures you that a is a value of the types you're prepared to handle, or if you're sure that types you're not prepared to handle are going to raise errors (e.g., a TypeError if you call len on a value for which it's undefined) that you're prepared to handle. In general, the "pythonic" conventions seem to go this last way. Squeeze it like a duck and let it raise a DuckError if it doesn't know how to quack. You still have to think about what type assumptions you're making, though, and whether the cases you're not prepared to handle properly really are going to error out in the right places. The Numpy arrays are a good example where just blindly relying on len or the boolean typecast may not do precisely what you're expecting.
Look at the following code executed on Python interactive terminal.
>>> a = []
>>> if a:
... print "List is not empty";
... else:
... print "List is empty"
...
List is empty
>>>
>>> a = [1, 4, 9]
>>> if a:
... print "List is not empty";
... else:
... print "List is empty"
...
List is not empty
>>>
I had written:
which was voted -1. I'm not sure if that's because readers objected to the strategy or thought the answer wasn't helpful as presented. I'll pretend it was the latter, since---whatever counts as "pythonic"---this is the correct strategy. Unless you've already ruled out, or are prepared to handle cases where
a
is, for example,False
, you need a test more restrictive than justif not a:
. You could use something like this:the first test is in response to @Mike's answer, above. The third line could also be replaced with:
if you only want to accept instances of particular types (and their subtypes), or with:
You can get away without the explicit type check, but only if the surrounding context already assures you that
a
is a value of the types you're prepared to handle, or if you're sure that types you're not prepared to handle are going to raise errors (e.g., aTypeError
if you calllen
on a value for which it's undefined) that you're prepared to handle. In general, the "pythonic" conventions seem to go this last way. Squeeze it like a duck and let it raise a DuckError if it doesn't know how to quack. You still have to think about what type assumptions you're making, though, and whether the cases you're not prepared to handle properly really are going to error out in the right places. The Numpy arrays are a good example where just blindly relying onlen
or the boolean typecast may not do precisely what you're expecting.Simple way is checking the length is equal zero.
Another simple way could be
Look at the following code executed on Python interactive terminal.
The pythonic way to do it is from the PEP 8 style guide (where Yes means “recommended” and No means “not recommended”):
You can check if the length of the array is zero (or not.) If the length of the array is zero, then it is empty. try the following: