On Sun, 08 Jul 2018 19:35:55 +0300, Marko Rauhamaa wrote: > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>: >> On Sun, 08 Jul 2018 14:11:58 +0300, Marko Rauhamaa wrote: >>> PS My example with "impossible" being the result of a racy integer >>> operation is of course unlikely but could be the outcome if the Python >>> runtime reorganized its object cache on the fly (in a hypothetical >>> implementation). >> >> That would be a cache bug :-) >> >> Not every interpreter bug should be considered the caller's fault :-) > > Whether it's a bug or not depends on the language specification.
"It is true that if you turn the indicator on at the same time that you turn the windshield wipers on, the car will explode in an enormous fireball releasing sufficient poisonous gases to kill everyone in a fifteen block radius. But we never said that it was safe to turn the indicator and windshield wipers on at the same time, so it's not a bug, its operator error." Compiler writers and language designers need to stop hiding behind specifications. No other industry so routinely tries (and too often succeeds) in playing the "but we never said our product wouldn't set you on fire" card with so little justification. > Java > has a very clear definition for correct synchronization. It's not so > clear on what could happen in the event of a data race; it's not > entirely unspecified, but the language spec admonishes the application > to brace itself for surprising effects. Incorrect synchronisation is irrelevant in this example. If the object cache is *ever* in an invalid state, such that (as per your example) the literal 1 (an int) could be evaluated as "impossible" (a string), that is a bug in the object management. Threads or no threads. The only excuse would be if the caller directly messed with the cache in an unsupported fashion (say, with ctypes). Software needs "fit for purpose" laws and end-user warranties with teeth. If that means that the software industry spends the next thirty years fixing bugs instead of adding features, that's a good thing. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list