no, it is not necessary in a strict sense of the word. The instantiation of a
BaseList2D (i.e. a tag, an object, a shader, etc.) can fail when your computer runs out of memory. In that case the symbol of the node will reference
None. You handling this case or not only makes a difference in with what error message your program will stop (this hold true for all exception handling). But it is easier to debug code if you get a message that specially gives you a reason why the program did stop, rather than your code failing because an object (in the pythonic sense) is not what the code assumes it to be (e.g. Python would raise something like
AttributeError: NoneType has no attribute InsertTag when the node instantiation did fail).
The practice to state something like
if something is None: return makes sense if you design a function which specifically includes returning
None in its signature. But it is often also used like shown here in your code, to irregularly stop a program when something is going wrong. While this usage is not specifically wrong, most style guides advise against it, because it makes it hard to understand why the program did stop and also that it did stop irregularly in the first place. Use exceptions and be verbose instead. So for your code this would be something like.
if obj is None:
raise MemoryError("Could not instantiate object.")
Finally, if you say
if not obj: or
if obj is None: makes no real difference in this case (the literal
None will evaluate as
False and a node instance will evaluate as
True). However, the first one is sometimes is considered to be bad style, because it lacks the verbosity and makes the code harder to read. It also might proof treacherous if you are not aware of the truth testing behaviour of the the Python object you are testing - for integer literals the value
0 evaluates as
False for example.