8 ms·

All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.

by catnaroek 10y ago

in_the_sticks 10y ago
That's a useless distinction. Everything is an object in Python. Does that mean Python doesn't have values?
- catnaroek 10y ago
  It has primitive values: (0) small enough numbers (1) True, False, None, etc. (2) object references But it doesn't have compound values. And the distinction isn't useless. Values have a richer equational theory than objects, enabling lots of automatic optimizations.
  - qwertyuiop924 10y ago
    ...And outside FP, nobody cares, or uses that definition of value. As noted in my above post.
    - catnaroek 10y ago
      It's useful when writing Prolog programs too.
      - qwertyuiop924 10y ago
        Logic programming's actually pretty close to FP.
        catnaroek 10y ago
        Not really. Prolog is first-order. Functional languages, just like object-oriented ones, are higher-order.
        qwertyuiop924 10y ago
        "Close," not "is."
        catnaroek 10y ago
        There's very little in common, beyond the notions of mathematical variable and value. Syntactically, a functional program is an expression, but a logic program is a proposition. Operationally, functional programs run already constructed proofs, but logic programs search for proofs. Pragmatically, transcribing a logic program into a functional language or vice versa is difficult without effectively writing an interpreter for an embedded DSL. Or maybe by “close”, you mean “both are about equally difficult to wrap my head around”?
        qwertyuiop924 10y ago
        Don't mock me. And yes, I did mean the notion of mathematical value and variable. That's one of the core tenets of both.
        catnaroek 10y ago
        > I did mean the notion of mathematical value and variable. That's one of the core tenets of both. Maybe from a big distance this is enough similarity to lump functional and logic programming together. But on closer inspection, functional and logic programs are still very different. > Don't mock me. I wasn't mocking you. You clearly must not understand functional and logic programming very well, if you think they are in some way “close”.
        qwertyuiop924 10y ago
        They are somewhat close in paradigm: They both favor declarativism, and have mathematical values. Given, they're pretty far apart in paradigm, but those are some strong similarities.
sevensor 10y ago
While that's a good point, the namedtuple is value-like enough to address the "anemic objects" problem. Could you expand on the advantages of this: (a, b, c) is (a, b, c) being True instead of False?
- catnaroek 10y ago
  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
dragonwriter 10y ago
> All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values. That is not language feature of Python but an implementation detail. Python implementations are permitted (but not required) to intern any immutable value (which tuples, contrary to your description, are), and "is" is a mechanism for revealing what the implementation has done. You seem to be equivocating between talk of values as a logical thing (where Python absolutely has compound values, including tuples) and as an implementation feature (where individual Python implementations may or may not implement certain logical values through interning.)
- catnaroek 10y ago
  > That is not language feature of Python but an implementation detail. So you're saying that the behavior of the `is` operator is implementation-defined? > values as a logical thing (where Python absolutely has compound values, including tuples) The (informal, unspecified) metalanguage that you're using to reason about Python programs has compound values. Python itself doesn't.
  - dragonwriter 10y ago
    > So you're saying that the behavior of the `is` operator is implementation-defined? No, the behavior has a standard definition: it reveals whether the operands refer to the same in-memory construct. Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent.
    - catnaroek 10y ago
      > Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent. If I can't bind it to a variable, it isn't a value. You can't bind the list [1,2,3] to a variable, because Python has no such thing as the list [1,2,3].
      - dragonwriter 10y ago

All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.

in_the_sticks 10y ago

That's a useless distinction. Everything is an object in Python. Does that mean Python doesn't have values?

catnaroek 10y ago
It has primitive values: (0) small enough numbers (1) True, False, None, etc. (2) object references But it doesn't have compound values. And the distinction isn't useless. Values have a richer equational theory than objects, enabling lots of automatic optimizations.
- qwertyuiop924 10y ago
  ...And outside FP, nobody cares, or uses that definition of value. As noted in my above post.
  - catnaroek 10y ago
    It's useful when writing Prolog programs too.
    - qwertyuiop924 10y ago
      Logic programming's actually pretty close to FP.
      - catnaroek 10y ago
        Not really. Prolog is first-order. Functional languages, just like object-oriented ones, are higher-order.
        qwertyuiop924 10y ago
        "Close," not "is."
        catnaroek 10y ago
        There's very little in common, beyond the notions of mathematical variable and value. Syntactically, a functional program is an expression, but a logic program is a proposition. Operationally, functional programs run already constructed proofs, but logic programs search for proofs. Pragmatically, transcribing a logic program into a functional language or vice versa is difficult without effectively writing an interpreter for an embedded DSL. Or maybe by “close”, you mean “both are about equally difficult to wrap my head around”?
        qwertyuiop924 10y ago
        Don't mock me. And yes, I did mean the notion of mathematical value and variable. That's one of the core tenets of both.
        catnaroek 10y ago
        > I did mean the notion of mathematical value and variable. That's one of the core tenets of both. Maybe from a big distance this is enough similarity to lump functional and logic programming together. But on closer inspection, functional and logic programs are still very different. > Don't mock me. I wasn't mocking you. You clearly must not understand functional and logic programming very well, if you think they are in some way “close”.
        qwertyuiop924 10y ago
        They are somewhat close in paradigm: They both favor declarativism, and have mathematical values. Given, they're pretty far apart in paradigm, but those are some strong similarities.

sevensor 10y ago

While that's a good point, the namedtuple is value-like enough to address the "anemic objects" problem. Could you expand on the advantages of this: (a, b, c) is (a, b, c) being True instead of False?

catnaroek 10y ago
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

dragonwriter 10y ago

> All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values. That is not language feature of Python but an implementation detail. Python implementations are permitted (but not required) to intern any immutable value (which tuples, contrary to your description, are), and "is" is a mechanism for revealing what the implementation has done. You seem to be equivocating between talk of values as a logical thing (where Python absolutely has compound values, including tuples) and as an implementation feature (where individual Python implementations may or may not implement certain logical values through interning.)

catnaroek 10y ago
> That is not language feature of Python but an implementation detail. So you're saying that the behavior of the `is` operator is implementation-defined? > values as a logical thing (where Python absolutely has compound values, including tuples) The (informal, unspecified) metalanguage that you're using to reason about Python programs has compound values. Python itself doesn't.
- dragonwriter 10y ago
  > So you're saying that the behavior of the `is` operator is implementation-defined? No, the behavior has a standard definition: it reveals whether the operands refer to the same in-memory construct. Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent.
  - catnaroek 10y ago
    > Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent. If I can't bind it to a variable, it isn't a value. You can't bind the list [1,2,3] to a variable, because Python has no such thing as the list [1,2,3].
    - dragonwriter 10y ago