isn’t the expected behaviour exactly identical on any object that has len defined:

“By default, an object is considered true unless its class defines either a bool() method that returns False or a len() method that returns zero, when called with the object.”

ps: well your objection is I guess that we cant know in advance if that said object has len defined such as being a collection so this question does not really apply to your post I guess.

type safe python is a myth

Sure, but type hints provide a ton of value in documenting for your users what the code expects. I use type hints everywhere, and it’s fantastic! Yes, there’s no guarantee that the types are correct, but with static analysis and the assumption that your users want their code to work correctly, there’s a very high chance that the types are correct.

That said, I lie about types all the time. For example, if my function accepts a class instance as an argument, the intention is that the code accept any class that implements the same methods as the one I’ve defined in the parameter list, and you don’t necessarily have to pass an instance of that class in (or one of its sub-classes). But I feel like putting something reasonable in there makes a lot more sense than nothing, and I can clarify in the docstring that I really just need something that looks like that object. One of these days I’ll get around to switching that to Protocol classes to reduce type errors.

That said, I don’t type hint everything. A lot of private methods and private functions don’t have types, because they’re usually short and aren’t used outside the class/file anyway, so what’s the point?

else: # not my list, it is ourlist

Honestly most people use Python because it has fantastic libraries. They optimize it because the language is middling, but the libraries are gorgeous

ETA: This might double post because my Internet sucks right now, will fix when I have a chance

You may want to beneficiate from little performance boost even though you mostly don’t need it and still need python’s advantages. Being interested in performance isnt always looking for the very best performance there is out of any language, it can also be using little tips to go a tiny bit faster when you can.

This is my two cents as someone in the industry.

Because, while you don’t want to nitpick on each instruction cycle, sometimes the code runs millions of times and each microsecond adds up.

Keep in mind that people use this kind of things for work, serving real world customers who are doing their work.

Yes, the language itself is not optimal even by design, but its easy to work with, so they are making it worth a while. There’s no shortage of people who can work with it. It is easy to develop and maintain stuff with it, cutting development cost. Yes, we’re talking real businesses with real resource constraints.

Yes, Python is the wrong choice if performance is your top priority.

But here’s another perspective: why leave easy performance wins on the table? Especially if the cost is simpler code that works as you probably wanted anyway with both None and []?

Python is great if you want a really fast development cycle, because the code is generally quite simple and it’s “fast enough.” Any wins for “fast enough” is appreciated, because it delays me needing to actually look into little performance issues. It’s pretty easy for me to write a simple regex to fix this cose (s/if len\((\w+)\) == 0:/if not \1:/), and my codebase will be slightly faster. That’s awesome! I could even write up a quick pylint or ruff rule to catch these cases for developers going forward (if there isn’t one already).

If I’m actively tweaking things in my Python code to get a little better performance, you’re right, I should probably just use something else (writing a native module is probably a better use of time). But the author isn’t arguing that you should do that, just that, in this case, if not foo is preferred over if len(foo) == 0 for technical reasons, and I’ll add that it makes a ton of sense for readability reasons as well.

Here are some other simple wins:

• [] and {} instead of list() and dict() - the former copy constants, whereas the latter actually constructs things; oh, and you save a few chars
• use list comprehensions instead of regular loops - list comprehensions seem to be faster due to not needing to call append (and less code)
• use built-ins when you can - they’re often implemented in native code

I consider each of those cleaner Python code anyway, because they’re less code, just as explicit, and use built-in language features instead of reinventing the wheel.

It comes down to the question “Is YOUR C++ code faster than Python?” (and of course the reverse).

I’ve built a SCADA from scratch and performance requirements are low to begin with, seeing as it’s all network bound and real world objects take time to react, but I’m finding everything is very timely.

A colleague used SQLAlchemy for a similar task and got abysmal performance. No wonder, it’s constantly querying the DB for single results.

Alternatively, why wait twice as long for your python code to execute as you have to?

I’ve worked on a library that’s Python because the users of said library are used to Python.

The original version of the project made heavy use of numpy, so the actual performance sensitive code was effectively C++ and fourtran, which is what numpy is under the hood.

We eventually replaced the performance sensitive part of the code with Rust (and still some fourtran because BLAS) which ended up being about 10x faster.

The outermost layer of code is still Python though.

yeah I got angry just looking at it

I think there’s a good chance of that:

• -2x instead of ~2x - a human is unlikely to make that mistake
• no space here: ==0 - there’s a space every other time it’s done, including the screenshot
• the numbers are wrong - the screenshot has different data than the image
• why are there three bars? A naive approach would have two.

Strongly disagree that not x implies to programmers that x is a bool.

That’s why we use type-hinting at my company:

def do_work(foo: list | None):
    if not foo:
        return
    ...

Boom, self-documenting, faster, and very simple.

len(foo) == 0 also doesn’t imply it’s a list, it could be a dict or any other type that implements the __len__. That matters a lot in most cases, so I highly recommend using type hints instead of relying on assumptions like len(foo) == 0 is probably a list operation.

I really dislike using boolean operators on anything that is not a boolean. I recently made an esception to my rule and got punished… Yeah it is skill issue on my part that I tried to check that a variable equal to 0 was not None using “if variable…”. But many programming rules are there to avoid bugs caused by this kind of inattention.

if you’re worried about readability you can leave a comment.

I think it was supposed to be a ~, since they use that in a paragraph below the image.

Maybe they mean up to?

There’s probably an “import * from relativity” in there somewhere.

So… it has to iterate over the whole empty list is what you’re saying? like once for every of the zero items in the list?

Then please be less lazy next time.