[s_kilk]

Not really, the empty list, None, and False are distinct values in Python.

    In [1]: [] is None
    Out[1]: False

    In [2]: [] is False
    Out[2]: False

    In [3]: [] == False
    Out[3]: False

    In [4]: [] == None
    Out[4]: False

    In [5]: False is None
    Out[5]: False

    In [6]: False == None
    Out[6]: False

This kind of relatively fine-grained distinction between different types of data is essential for operation in a world where other systems presume that you can handle these distinctions.

[kleiba]

However:

    if not []:
        print("looks boolean to me...")

[rtpg]

Python code rarely looks like this

For things like optional arguments you usually use None with an "if l is None" parameter

Meanwhile you can't iterate over None, so [x for x in None] blows up

Closure (to my understanding) allows a null value in the place of any empty seq. This seems like a major bug swallower to me

[yen223]

> Python code rarely looks like this

Using implicit truthiness to test for empty sequences is idiomatic Python, for better or worse.

[rtpg]

Sorry, you're actually very right. I think I misread this in the case of a default argument example (which at least for codebases I work with are diligent about doing None tests for ) but if you know that the value is set to a sequence then the boolean test is common

[s_kilk]

Can't win em all I suppose :P

My point is that, for me, Common Lisp is particularly defficient in this regard, in a way that means I can't really consider using Common Lisp for development work today.

[kazinator]

Different programming languages play different games with booleans, empties, undefinedness and such. In all of them, people are able to Get Stuff Done, correctly handling inputs from the world.

In the POSIX shell, a failed termination status of a command is a false condition. Storing false as a datum is usually represented by an empty or unset variable.

Yet, people are able to write robust shell scripts to boot systems, build programs and so on.

Everything you wrote is based on a guess; not even anecdotal experience. That is below the expected level of discussion on HN.

The nil/empty/false thing is an excellent tradeoff in code that manipulates lists, rendering it succinct. For instance an expression like (when attributes (do-this ...)) means, (do-this ...) when attributes are present; i.e. the list of attributes is not empty. All the default nil return values that occur are automatically empty lists, which is very convenient. For instance a two-clause if (if condition then) returns nil if condition is false. If the caller expects a list, then that is perfect; it's the empty list. All these little conveniences dove-tail together to clarify the code.

The empty/false conflation doesn't do anything in code that doesn't manipulate lists. For instance, if you're manipulating numbers, or strings, there is no ambiguity: nil isn't a number and it isn't a string. It is distinct from 0, 0.0, and "".

You cannot have a meaningful opinion about this that anyone should take seriously unless you have experience with it: having experienced both the convenience in writing list manipulation code (particularly code-writing code) and the situations in which the ambiguity between nil (the atom) and nil (the empty list) was actually a problem.

[s_kilk]

(Nice to see the Lisp Defence Force out in strength.)