I think the explicitness of checking length is worth the performance cost. If ur writing code for speed ur not using python.
this post was submitted on 24 Apr 2025
1 points (100.0% liked)
Python
7869 readers
1 users here now
Welcome to the Python community on the programming.dev Lemmy instance!
π Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django π¬)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
π Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
π Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
β¨ Python Ecosystem:
π Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- PythΓΆrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
founded 2 years ago
MODERATORS
In complex cases where speed is less important than maintainability, I tend to agree.
In this case, a simple comment would suffice. And in fact nothing at all would be okay for any half-competent Python coder, as testing if lists are empty with if not is super-standard.
Why? not x means x is None or len(x) == 0 for lists. len(x) == 0 will raise an exception if x is None. In most cases, the distinction between None and [] isn't important, and if it is, I'd expect separate checks for those (again, for explicitness) since you'd presumably handle each case differently.
In short:
- if the distinction between
Noneand[]is important, have separate checks - if not,
not xshould be your default, since that way it's a common pattern for all types
I try to avoid having the same variable with different types I find it is often the cause of difficult to debug bugs. I struggle to think of a case where u would be performing a check that could be an empty list or None where both are expected possible values.
Really? I get that all the time. I do web dev, and our APIs have a lot of optional fields.
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)
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 = []
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.
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.
Ur function args if fucked up should always throw an error that's the entire point of python type hints
I'd argue that if it's strict explicitness you want, python is the wrong language. if not var is a standard pattern in python. You would be making your code slower for no good reason.
You always want explicitness when programming. Not everyone reading your code will be deep into Python and relying on falsiness makes it harder to understand.
Containers being "truthy" is quite basic Python and you will find this idiom used in nearly every Python code base in my experience
Yeah, I'm talking less deep than that. Plenty programming beginners will be reading Python code. And personally, I'm a fulltime software engineer, but just don't do much Python, so while I had it in the back of my mind that Python does truthiness, I would have still thought that var must be a boolean, because it's being negated. Obviously, a different variable name might've given me more of a clue, but it really doesn't reduce mental complexity when I can't be sure what's actually in a variable.
But if those beginners want to stop being beginners, then they must learn the basics of the language. It makes no more sense to demand that everyone who programs in Python caters to beginners, than it makes to demand that everyone writing in English write at a 3rd grade reading level for the sake of English language learners
I don't know about others ... but I'm not using Python for execution speed.
Typically the biggest problem in a program is not 100 million calls of len(x) == 0. If it was, the interpreter could just translate that expression during parsing.
This. I rarely boot up Python for the tasks I need to do, and if they are, they are one of the following:
- Assistant code for other coding language
- Throwaway script
- Prototype before using a faster language
Assuming an equivalent package is produced, what's the maintenance cost (factoring in coder availability) difference between the Python vs faster language implementations?
^^ therein lies the rub
Reminds of the expression, premature optimization is the root of all evil
if not swimming in funding, might be a darwinic move to choose the faster language and have to code everything yourself from scratch
Makes perfect sense. If you're checking if a collection is empty you don't need to know its exact size. Getting the size can be very inefficient in collections like linked lists or trees, if you have to follow all nodes. To check if it's empty, all you need fo know if at least one item exists. If one does, there's no point counting the rest.
People who don't understand the difference will probably not understand the difference between passing a list and passing an literator/generator to any() .