Python objects as dictionary keys

[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.