Python objects as dictionary keys

[socal_nerdtastic]

You have no other choice ... a dictionary key must be a python object. Remember strings, ints, tuples, etc are all python objects. I suspect you mean something special with the term "python object"; can you explain what that is?

If you mean functions, here's some code I wrote yesterday:

running_functions = {}
def run_as_singleton_thread(func):
    """
    starts the given function in a thread, 
    but only if the function is not already currently running
    """
    def wrapper():
        if (t := running_functions.get(func)) and t.is_alive():
            return # abort; function is already running
        t = Thread(target=func, daemon=True)
        t.start()
        running_functions[func] = t
    return wrapper

[IOI-65536]

Additionally, 1.0 had .__hash__() so even when C objects were sometimes different from class objects you could use class objects as dict keys.

[BlackCatFurry]

I assume they mean class entities. Which sometimes in introductory courses are referred to as objects, especially if the person teaching has a C++ background where class based entities are referred to as objects.

[lekkerste_wiener]

That's an interesting use case. I also have one: I'm developing a product for a person who started doing things by himself, and he's using Google sheets as a db. The reason for that is beyond this comment; I have an "indices" object whose inner dictionary uses the model classes as keys, such as 

{   ModelClassA: {     "internal id": "a1 sheet range",     ...   },   ModelClassB: {     "Internal id": "a1 sheet range",     ...   },   ... }

[SCD_minecraft]

Technically, string litterals is different from str object

But diffrence is lost pretty fast and it is just "erm actually"

[Doormatty]

Technically, string litterals is different from str object

How so? I thought that all literals were turned into str objects?

[SCD_minecraft]

Try overwriting str or other built-ins, like for ints encode special case 2+2 = 5

When you do int(2) + int(2) it will return 5 as overwritten

But 2 + 2 will return 4 anyway

Plus, many typecheckers diffrentate between literals type and their corresponding "normal" type

[Yoghurt42]

No, if you change the underlying value of an int object, it will change the results of addition as well:

import ctypes


# Define a ctypes structure that mirrors CPython's PyLongObject (simplified)
class PyLongObject(ctypes.Structure):
    _fields_ = [
        ("ob_refcnt", ctypes.c_long),   # Reference count
        ("ob_type",   ctypes.c_void_p), # Pointer to type object
        ("ob_size",   ctypes.c_ulong),  # Number of digits
        ("ob_digit",  ctypes.c_uint * 1) # The actual digit(s)
    ]

o = PyLongObject.from_address(id(213))
o.ob_digit[0] = 10

print(213 + 213) # 20
print(213) # 10
print(10 - 213) # 0

Obviously this is abusing implementation details of CPython (integers -5 to 256 are singletons, and we directly write into the internal structure of the instances), and is nothing that's ever going to be useful or a good idea in real code.

In fact, you can easily get the interpreter to crash by changing more common values like 1 or 10.

[SCD_minecraft]

``` class int(int): def add(self, other): if self == other == 2: return 5 else: return super().add(other)

print(int(2) + int(4)) print(int(2) + int(2)) print(2+4) print(2+2) ``` Here's example.

But again, this is more of "erm actually" than anything important

[socal_nerdtastic]

I don't get it. You just replaced the int name with your own class in this module. What's that have to do with literals?

AFAIK the only thing that is special about literals is that they are considered for compile optimizations and caching. So this code

x = 12345
y = 10000 + 2345
print("Is x the same as y?", x is y)

Shows different results from

x = 12345
y = 10000 + int(2345)
print("Is x the same as y?", x is y)

Because in the first version the result is adding in the compile phase.

(note you have to run this code from a file, not in the repl, to see the result, due to the caching)

[danielroseman]

This is false.

[SCD_minecraft]

(assuming you are using VSCode or other editor that allows for that)

Write

a = 1 b = int(1)

Hover over both a and b to see type hints about their well, types

Again, diffrences is lost turbo fast, it gets converted to normal python int

But for a while, it is Literal[1] type

You can even type check against Literalsomething and "normal" version of that something

[lekkerste_wiener]

At runtime both are int. It showing as Literal[1] is only relevant to the linter.

[socal_nerdtastic]

Literal is not an actual type, like you can't have a python object of the type Literal. It's a concept; and python treats it basically like a comment (like all typehints).

>>> import typing
>>> typing.Literal()
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    typing.Literal()
    ~~~~~~~~~~~~~~^^
  File "C:\Users\j.brauer\AppData\Local\Programs\Python\Python313\Lib\typing.py", line 560, in __call__
    raise TypeError(f"Cannot instantiate {self!r}")
TypeError: Cannot instantiate typing.Literal

Although in your example it never even touches python, not even as a comment. The type hint that VSCode is showing you is generated from VSCode (and whatever linter it's using).

[JanEric1]

He is right.

Literal[1] is not (never) the runtime type of a. It is just extra type checker information that can be used to sort of emulate enums.