this post was submitted on 01 Apr 2026
25 points (90.3% liked)
Python
7863 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
IMO, using id() as a key would never be a good idea under any circumstance.
Two different (and even unequal) objects can have the same id():
Note - a dictionary lookup already looks up the key by id() first as a shortcut (under-the-hood), so there's no need to try doing this as an optimization.
Edit: in case it wasn't clear above, the object with the same id()s don't all exist at the same time; but if you store their ids as a key, you'd have to ensure the object lifetimes are identical to be sure the ids could identify the same stored value. The dictionary does this for you when you use the key object, but it's not automatic when using the id of the key.
Other Note - Since you phrased it as "all ints below a fixed limit share the same id() result", I'd suggest a better way to semantically think of it is that certain constant objects are pre-allocated, and thus are kinda like singletons. There is usually only one
int(1)object, and the language keeps a pre-allocated pool of these common small ints (since they are used so often for indexing anyway).Similarly, many short string constants are 'interned' in a similar way; they aren't pre-created at startup, but once they are created by the user declaring a string constant when the code is run, it saves memory to check and only keep one copy of those string objects, as the string constants can be checked at byte-compile time. But if you construct the string with code, it doesn't bother to check all the strings to see if there exists an identical one. So for example:
But you can force it to make this check; it's something they made more tedious to do in Python3 since it's really an implementation detail:
Sorry for the verbose reply; hope it helped.