this post was submitted on 24 Apr 2025
52 points (93.3% liked)
Python
7044 readers
68 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well, it certainly wouldn't be the first time that I call some code unnecessarily hard to read and others call it pythonic.
I understand that truthiness has an advantage when you don't have static types, because it deals somewhat reasonably with most types, and then that is why many experienced Python programmers tend to use it. But I maintain the position that it therefore necessarily also makes it harder to read the code, because you necessarily provide the reader with fewer hints as to what is actually in that variable. It is very much like code using lots of generics in statically typed code.
As for
if Enum.empty?(var)
, I actually prefer that to checking the length. That syntax in particular, I find a bit too complex β my preferred version isif var.is_empty()
β but I still think it makes it easier to read than a length check.Of course, there's the nuance that it's more syntax to remember for actually writing the code. And in particular in dynamically typed languages, your editor may not be able to auto-complete that, so I can understand just not bothering with the extra syntax and doing
len == 0
instead. It's fine.Then make it explicit. I much prefer this:
This one communicates to me that the function only makes sense with a non-empty list.
To this:
This just tells me
bar
is something that has a length (list, dict, str, etc).And this is way worse:
This tells me we want an exception if
bar
isNone
, which I think is bad style, given that we're explicitly allowingNone
here. If we remove the| None
and get an exception, than the code is broken because I shouldn't be able to get that value in that context.If I care about the difference between
None
and empty, then I'll make that explicit:In any case, I just do not like
if len(bar) == 0
because that looks like a mistake (i.e. did the dev know it could throw an error if it's not a list? Was that intentional?).