10 ms·

Python also has destructors (def del(self):). They are called at whatever time and whichever order the GC gets around to it.

Python also has destructors (def __del__(self):). They are called at whatever time and whichever order the GC gets around to it.

saurik 6y ago
The Python people don't want you to rely on this--which I only learned many years later and it frankly ruined Python for me (are least in the abstract, as "practically" I can ignore this for my projects), as I consider "deterministic finalization" to be a critical language feature--but CPython uses reference counting and thereby has predictable deconstruction.
- ben509 6y ago
  CPython uses reference counting and gc. It's the worst of both worlds: the expense of refcounting, and faux determinism until some innocuous code change causes you to hang on to a reference.
  - klyrs 6y ago
    Refcounting needs a mechanism for cycle breaking, or it's necessarily leaky. This isn't the worst of both worlds; it's simply a consequence of refcounting. The same issue occurs in c++ if you're sloppy with shared_ptr. If you know what you're doing, you can break cycles with weak references in either language. Where Python has diapers, c++ has footguns aplenty.
    - int_19h 6y ago
      The problem with Python isn't that it has reference cycles. It's that it has a tracing GC that tries to automagically fix those cycles for you. So in C++, if you get a cycle, the destructors do not run at all - which is pretty noticeable. In Python, they run "sometime later", so programmers are less inclined to fix the cycles (indeed, many aren't even aware that it's a problem). But if you provide a non-deterministic mechanism on top of refcounting to break the cycles, and destructors aren't consistently deterministic already, why even bother with refcounting at all?
    - ncmncm 6y ago
      In practice, cycles just don't happen in real code. It is possible to contrive a graph data structure with cycles, but it is a bad (i.e. slow) representation not useful in production.
gpderetta 6y ago
Those are finalizes thought and are a bit different.

Python also has destructors (def __del__(self):). They are called at whatever time and whichever order the GC gets around to it.

saurik 6y ago

The Python people don't want you to rely on this--which I only learned many years later and it frankly ruined Python for me (are least in the abstract, as "practically" I can ignore this for my projects), as I consider "deterministic finalization" to be a critical language feature--but CPython uses reference counting and thereby has predictable deconstruction.

ben509 6y ago
CPython uses reference counting and gc. It's the worst of both worlds: the expense of refcounting, and faux determinism until some innocuous code change causes you to hang on to a reference.
- klyrs 6y ago
  Refcounting needs a mechanism for cycle breaking, or it's necessarily leaky. This isn't the worst of both worlds; it's simply a consequence of refcounting. The same issue occurs in c++ if you're sloppy with shared_ptr. If you know what you're doing, you can break cycles with weak references in either language. Where Python has diapers, c++ has footguns aplenty.
  - int_19h 6y ago
    The problem with Python isn't that it has reference cycles. It's that it has a tracing GC that tries to automagically fix those cycles for you. So in C++, if you get a cycle, the destructors do not run at all - which is pretty noticeable. In Python, they run "sometime later", so programmers are less inclined to fix the cycles (indeed, many aren't even aware that it's a problem). But if you provide a non-deterministic mechanism on top of refcounting to break the cycles, and destructors aren't consistently deterministic already, why even bother with refcounting at all?
  - ncmncm 6y ago
    In practice, cycles just don't happen in real code. It is possible to contrive a graph data structure with cycles, but it is a bad (i.e. slow) representation not useful in production.

gpderetta 6y ago

Those are finalizes thought and are a bit different.