5 ms·

I dunno about that. There's a lot of Python out there with worker threads dumping their output into a shared "results" dict on the assumption that those insert

I dunno about that. There's a lot of Python out there with worker threads dumping their output into a shared "results" dict on the assumption that those insert operations are atomic.

formerly_proven 3y ago
Relying on implementation behavior, even if it’s very visible and hasn’t changed for a few decades, is morally wrong and reprehensible. Only the letter of the standard has any bearing on correct reality.
- HDThoreaun 3y ago
  > morally wrong That's a wild one
  - smegsicle 3y ago
    woe is man who loses sight of god and sees only himself
  - cozzyd 3y ago
    clearly a user of https://github.com/munificent/vigil https://github.com/munificent/vigil
    - m463 3y ago
      lol from FAQ: Q: But isn't a language that deletes code crazy?
- deleted 3y ago
  [deleted]
- Kranar 3y ago
  Python's semantics do not have a standards document or specification. It's based on its reference implementation (CPython) and different variations of Python even have different semantics (Jython, IronPython, PyPy). The library is documented, and the syntax is also documented, but the semantics themselves are not.
  - eesmith 3y ago
    It isn't as dire as you suggest. The language reference at https://docs.python.org/3/reference/index.html https://docs.python.org/3/reference/index.html "describes the syntax and “core semantics” of the language.". There has been a distinction between Python-the-language and CPython-the-implementation ever since JPython back in the 1990s. For example, reference counting is a CPython implementation details. The reference manual says only: > Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether — it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable. (Quoting https://docs.python.org/3/reference/datamodel.html https://docs.python.org/3/reference/datamodel.html )
    - Kranar 3y ago
      Absolutely, but note what your very quote says "describes ... the language" rather than "prescribes ... the language". A standards document or specification's purpose is to "prescribe" how a system shall work in order to be compliant as opposed to a reference which documents how systems currently happen to work.
eesmith 3y ago
Python says those insert operations are atomic. https://docs.python.org/3/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe https://docs.python.org/3/faq/library.html#what-kinds-of-glo... For example, the following operations are all atomic (L, L1, L2 are lists, D, D1, D2 are dicts, x, y are objects, i, j are ints): L.append(x) L1.extend(L2) x = L[i] x = L.pop() L1[i:j] = L2 L.sort() x = y x.field = y D[x] = y D1.update(D2) D.keys()
- mikepurvis 3y ago
  That's helpful that that's explicitly documented as such then, rather than just a "lol GIL" implementation detail that people have been able to take advantage of since forever— not carrying a documented guarantee like that over into GIL-less python's stdlib would be a nightmare.

I dunno about that. There's a lot of Python out there with worker threads dumping their output into a shared "results" dict on the assumption that those insert operations are atomic.

formerly_proven 3y ago

Relying on implementation behavior, even if it’s very visible and hasn’t changed for a few decades, is morally wrong and reprehensible. Only the letter of the standard has any bearing on correct reality.

HDThoreaun 3y ago
> morally wrong That's a wild one
- smegsicle 3y ago
  woe is man who loses sight of god and sees only himself
- cozzyd 3y ago
  clearly a user of https://github.com/munificent/vigil https://github.com/munificent/vigil
  - m463 3y ago
    lol from FAQ: Q: But isn't a language that deletes code crazy?
deleted 3y ago
[deleted]
Kranar 3y ago
Python's semantics do not have a standards document or specification. It's based on its reference implementation (CPython) and different variations of Python even have different semantics (Jython, IronPython, PyPy). The library is documented, and the syntax is also documented, but the semantics themselves are not.
- eesmith 3y ago
  It isn't as dire as you suggest. The language reference at https://docs.python.org/3/reference/index.html https://docs.python.org/3/reference/index.html "describes the syntax and “core semantics” of the language.". There has been a distinction between Python-the-language and CPython-the-implementation ever since JPython back in the 1990s. For example, reference counting is a CPython implementation details. The reference manual says only: > Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether — it is a matter of implementation quality how garbage collection is implemented, as long as no objects are collected that are still reachable. (Quoting https://docs.python.org/3/reference/datamodel.html https://docs.python.org/3/reference/datamodel.html )
  - Kranar 3y ago
    Absolutely, but note what your very quote says "describes ... the language" rather than "prescribes ... the language". A standards document or specification's purpose is to "prescribe" how a system shall work in order to be compliant as opposed to a reference which documents how systems currently happen to work.

eesmith 3y ago

Python says those insert operations are atomic. https://docs.python.org/3/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe https://docs.python.org/3/faq/library.html#what-kinds-of-glo... For example, the following operations are all atomic (L, L1, L2 are lists, D, D1, D2 are dicts, x, y are objects, i, j are ints): L.append(x) L1.extend(L2) x = L[i] x = L.pop() L1[i:j] = L2 L.sort() x = y x.field = y D[x] = y D1.update(D2) D.keys()

mikepurvis 3y ago
That's helpful that that's explicitly documented as such then, rather than just a "lol GIL" implementation detail that people have been able to take advantage of since forever— not carrying a documented guarantee like that over into GIL-less python's stdlib would be a nightmare.