Le tout premier numéro de la série posait la règle sans jamais expliquer pourquoi elle semblait avoir des exceptions.The very first issue of the series stated the rule without ever explaining why it seemed to have exceptions.
Le n°01 a ouvert toute la série sur une distinction fondatrice : is compare l'identité de deux objets — sont-ils littéralement le même objet en mémoire, le même id() — tandis que == compare leur valeur. Mais une question restait en suspens : pourquoi deux entiers valant 256, calculés à l'exécution, sont-ils le même objet, alors que deux entiers valant 257 ne le sont pas, quand == aurait répondu True dans les deux cas sans exception ? La réponse tenait dans un détail d'implémentation de CPython jamais encore nommé : certains objets, en nombre volontairement limité, sont créés une seule fois au démarrage de l'interpréteur, puis partagés — jamais recréés — chaque fois que leur valeur revient dans le code. Deux petits entiers égaux à 256 ne sont donc pas seulement égaux : ce sont, littéralement, le même objet.Issue №01 opened the entire series with a founding distinction: is compares the identity of two objects — are they literally the same object in memory, the same id() — while == compares their value. But a question was left hanging: why are two integers worth 256, computed at runtime, the same object, while two integers worth 257 are not, when == would have answered True in both cases without exception? The answer lay in a CPython implementation detail never yet named: certain objects, in a deliberately limited number, are created exactly once at interpreter startup, then shared — never recreated — every time their value comes up again in the code. Two small integers equal to 256 aren't just equal, then: they are, literally, the same object.
# la règle du n°01, appliquée à des entiers calculés à l'exécution : a = int("256") b = int("256") print(a is b) # True -- "is" compare l'IDENTITÉ (id()), pas la valeur a = int("257") b = int("257") print(a is b) # False -- pourtant, == aurait donné True dans les deux cas # (a = 257; b = 257 écrits tels quels dans un script donneraient True : # le compilateur partage les constantes identiques d'un même bloc.) # Mais pourquoi 256 se comporte-t-il différemment de 257 ? # La réponse n'a jamais été donnée -- jusqu'à ce numéro.
Ce numéro ne présente pas une nouvelle règle : il explique enfin celle posée au tout premier numéro de la série. Le prix invisible du dynamisme n'est jamais mieux visible qu'ici, dans une coïncidence d'implémentation prise, à tort, pour une garantie du langage.This issue doesn't introduce a new rule: it finally explains the one stated in the series' very first issue. The invisible price of dynamism is never more visible than here, in an implementation coincidence wrongly mistaken for a language guarantee.