6 ms·

The runtime system's memory manager could automatically hash-cons equal compound values, reducing their memory footprint. It's like the flyweight pattern, excep

The runtime system's memory manager could automatically hash-cons equal compound values, reducing their memory footprint. It's like the flyweight pattern, except the runtime system gives it to you for free.

sevensor 10y ago
I agree that's nice for memory use. It's totally consistent with the immutability of tuples, too. I suppose Python has elected to take the memory hit to reduce complexity in the interpreter?
- catnaroek 10y ago
  As things stand now, the main reason why Python can't do it is because it could potentially break programs.
  - dragonwriter 10y ago
    > As things stand now, the main reason why Python can't do it is because it could potentially break programs. Since the documented behavior of Python is compatible with what is suggested as a change, any program that relies on the behavior not reflecting as described in the "change" is asking to be broken (and quite possibly already broken across different implementations -- including different versions of the same implementation.) Immutable types in python already are defined with the semantics of values, in that "for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed." [0] [0] https://docs.python.org/2/reference/datamodel.html https://docs.python.org/2/reference/datamodel.html
    - catnaroek 10y ago
      So, which is the case? (0) Python provides a compound value abstraction, but this abstraction leaks, because we can distinguish between multiple representations of the same compound value. (1) Python doesn't provide a compound value abstraction. With a few exceptions (e.g., garbage collection, which pretends memory is infinite, even though it's not), I tend not to consider so-called “leaky abstractions” actual abstractions, but if you know of a good reason to do otherwise, please tell me.
      - dragonwriter 10y ago
        Python provides a value abstraction that includes (but is not distinct for) compound values. It also provides an independent mechanism for examining physical (rather than logical) identity -- which is object identity; for all compound values (and all but a very narrow subset of simple values) there is no guarantee that the logical identity of values is equivalent to physical/object identity. I don't see that this makes the value abstraction "leaky", though; for values, value identity is tested by equality. For objects, equality tests object equality but not object identity. Because Python is an "everything is an object" language, you can also test object identity for values, but for values in general there is no defined relationship between object identity and value identity, so this has no defined general logical (as opposed to physical) meaning for value types. (There are some values which are defined to also be singleton objects so that value and object identity are equivalent for these values; but that's a feature not of the value abstraction in Python but of the value-object mapping in Python.) So I don't see the value abstraction itself as leaky. OTOH, I'd probably be happier if Python had (whether it was "is" or something else) a clean logical identity test operator.
        catnaroek 10y ago
        This simply doesn't make sense. It violates the indiscernibility of identicals, which is one of the cornerstones of Western logic. I can accept different opinions on several matters (e.g., the extent to which using objects is a good idea), but throwing logic out of the window is just too much.
        sevensor 10y ago
        I would argue that, because Python requires its users to reason about storage and interpreter state, we shouldn't consider (a,b,c) and (a,b,c) identical under is unless they're aliases for the same structure in memory. I'm not sure I understand dragonwriter's idea for a third equality operator, however. Isn't == adequate for that purpose? By the way, I'd like to thank both catnaroek and dragonwriter for an excellent discussion; this sort of thing is why I come to HN.

sevensor 10y ago

I agree that's nice for memory use. It's totally consistent with the immutability of tuples, too. I suppose Python has elected to take the memory hit to reduce complexity in the interpreter?

catnaroek 10y ago
As things stand now, the main reason why Python can't do it is because it could potentially break programs.
- dragonwriter 10y ago
  > As things stand now, the main reason why Python can't do it is because it could potentially break programs. Since the documented behavior of Python is compatible with what is suggested as a change, any program that relies on the behavior not reflecting as described in the "change" is asking to be broken (and quite possibly already broken across different implementations -- including different versions of the same implementation.) Immutable types in python already are defined with the semantics of values, in that "for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed." [0] [0] https://docs.python.org/2/reference/datamodel.html https://docs.python.org/2/reference/datamodel.html
  - catnaroek 10y ago
    So, which is the case? (0) Python provides a compound value abstraction, but this abstraction leaks, because we can distinguish between multiple representations of the same compound value. (1) Python doesn't provide a compound value abstraction. With a few exceptions (e.g., garbage collection, which pretends memory is infinite, even though it's not), I tend not to consider so-called “leaky abstractions” actual abstractions, but if you know of a good reason to do otherwise, please tell me.
    - dragonwriter 10y ago
      Python provides a value abstraction that includes (but is not distinct for) compound values. It also provides an independent mechanism for examining physical (rather than logical) identity -- which is object identity; for all compound values (and all but a very narrow subset of simple values) there is no guarantee that the logical identity of values is equivalent to physical/object identity. I don't see that this makes the value abstraction "leaky", though; for values, value identity is tested by equality. For objects, equality tests object equality but not object identity. Because Python is an "everything is an object" language, you can also test object identity for values, but for values in general there is no defined relationship between object identity and value identity, so this has no defined general logical (as opposed to physical) meaning for value types. (There are some values which are defined to also be singleton objects so that value and object identity are equivalent for these values; but that's a feature not of the value abstraction in Python but of the value-object mapping in Python.) So I don't see the value abstraction itself as leaky. OTOH, I'd probably be happier if Python had (whether it was "is" or something else) a clean logical identity test operator.
      - catnaroek 10y ago
        This simply doesn't make sense. It violates the indiscernibility of identicals, which is one of the cornerstones of Western logic. I can accept different opinions on several matters (e.g., the extent to which using objects is a good idea), but throwing logic out of the window is just too much.
        sevensor 10y ago
        I would argue that, because Python requires its users to reason about storage and interpreter state, we shouldn't consider (a,b,c) and (a,b,c) identical under is unless they're aliases for the same structure in memory. I'm not sure I understand dragonwriter's idea for a third equality operator, however. Isn't == adequate for that purpose? By the way, I'd like to thank both catnaroek and dragonwriter for an excellent discussion; this sort of thing is why I come to HN.