this post was submitted on 24 Apr 2025
60 points (94.1% liked)

Python

7045 readers
54 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

πŸ“… Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
πŸ’“ Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 2 years ago
MODERATORS
jnovinger
erlingur
norambna
60
Python Performance: Why 'if not list' is 2x Faster Than Using len() (blog.codingconfessions.com)
submitted 2 days ago by jnovinger to c/python
52 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 1 day ago (1 children)

I do web dev

Theirs ur problem.

But in all seriousness I think if u def some_func(*args, kwarg=[]) Is a more explicit form of def some_func(*args, kwarg=None)

[–] [email protected] 3 points 20 hours ago* (last edited 20 hours ago) (1 children)

def some_func(*args, kwarg=[])

Don't do this:

def fun(l=[]):
    l.append(len(l))
    return l

fun()  # [0]
fun()  # [0, 1]
fun(l=[])  # [0]
fun()  # [0, 1, 2]
fun(l=None)  # raise AttributeError or TypeError if len(l) comes first

This can be downright cryptic if you're passing things dynamically, such as:

def caller(*args, **kwargs):
    fun(*args, **kwargs)

It's much safer to do a simple check at the beginning:

if not l: 
    l = []
[–] [email protected] 1 points 19 hours ago (2 children)

I like the exception being raised their is no reason I should be passing in None to the function it means I've fucked up the value of whatever I'm passing in at some point.

[–] logging_strict 2 points 2 hours ago (1 children)

Oh no a stray None! Take cover ...

Robust codebase should never fail from a stray None

Chaos testing is specifically geared towards bullet proofing code against unexpected param types including None.

The only exception is for private support function for type specific checking functions. Where it's obviously only for one type ever.

We live in clownworld, i'm a clown and keep the company of shit throwing monkeys.

[–] [email protected] 1 points 1 hour ago

Ur function args if fucked up should always throw an error that's the entire point of python type hints

[–] [email protected] 2 points 18 hours ago

Then make it explicit:

if l is None:
    raise ValueError("Must provide a valid value for...")

Having an attribute or type error rarely provides the right amount of context to immediately recognize the error, especially if it's deep inside the application. A lot of our old code makes stupid errors like TypeError: operator - not defined on types NoneType and float, because someone screwed up somewhere and wasn't strict on checks. Don't reply on implicit exceptions, explicitly raise them so you can add context, because sometimes stacktraces get lost and all you have is the error message.

But in my experience, the practical difference between [] and None is essentially zero, except in a few cases, and those should stand out. I have a few places with logic like this:

if l is None:
    raise MyCustomInvalidException("Must provide a list")
if not l: 
    # nothing to do
    return

For example, if I make a task runner, an empty list could validly mean no arguments, while a null list means the caller screwed up somewhere and probably forgot to provide them.

Explicit is better than implicit, and simple is better than complex.