Keep programming in python long enough and you'll see it eventually. It might be hard to recognize at first.

On the python bug tracker somewhere a while back there was a guy who wrote "if time_variable:" which resolved to false but only when it was called at midnight. It was initally resolved as wontfix.

(midnight being the datetime's conceptual equivalent to empty string, 0, empty list, etc.)

The most common case is when people use `if not s` to test for None in an otherwise string value (e.g. from JSON) without realizing that empty strings are also false.

... thank you for informing me that the code I wrote the other day is buggy. This sort of BS is exactly why I avoid JS. Truly one of the worst convenience "features" ever.

We need a unary "truthy" operator so that code remains compact and readable without the surprising behavior.

The "truthy" operator is bool(); the problem here is that empty strings are falsy.

For myself, I settled on these patterns for various kinds of tests:

  # check for None
  if x is not None: ...

  # check for empty string
  if x != "": ...

  # check for empty collection other than string
  if not len(x): ...

In this last case I rely on 0 being falsy to make this idiom distinct from checking length for a specific value via equality. So that when I'm scanning the code later and I see "not len", I know right away it's an empty check specifically.

But, of course, this only works if you're doing it consistently. And since the language doesn't enforce it, and there's no idiomatic Python standard for it, the footgun remains...

Those seem like opinionated rules that are easily added to ruff or other checkers to beat you over the head about. I know there are a bunch of truthiness opinions in ruff's catalog already that help me catch goofs.

bool( thing ) is overly verbose. It would be nice to have a unary operator.

I don't think the problem is that empty strings are falsy per say (although that might not be to your personal preference). Rather I think the problem is the implicit coercion to bool, hence my desire for a unary operator.

I think this is yet another entry in the (extremely) long list of examples of why implicit type conversions are a bad thing.

> I don't think the problem is that empty strings are falsy per say (although that might not be to your personal preference).

Let me correct that. The problem isn't so much that they are falsy per se, but rather that they share this property with so many unrelated things - and this is then combined with dynamic typing, so any given `x` can be any of those things. None/'' in particular is exceedingly common because None is the standard way to report absence of a value in Python.

As far as having a symbolic unary operator for such checks, I think that would go stylistically contrary to the overall feel of Python syntax - I mean, this is a language in which you have to spell out things like "not", and len() is also a function unlike say Lua. It feels like the most Pythonic interface for this would be as an instance property with a descriptive name.