4 ms·

The 'slow' part wasn't so new to me, but the `id` command and the attendant understanding that smply typing 110 in the interpreter creates an OBJECT and when yo

by kghose 12y ago

The 'slow' part wasn't so new to me, but the `id` command and the attendant understanding that smply typing 110 in the interpreter creates an OBJECT and when you assign a=110 `a` points at that object (and when you reassign a=30, a new object is created and a points at that), blew my mind. Thanks for this! Previously I had thought that doing a=110 creates an object 'a' that stores the value 110 (and when we do b=a, b simply points to a). I had no idea there is a third object in play.

taejo 12y ago
`a=110; b=a` involves only one object: 110. a and b are just names.
- dekhn 12y ago
  And 110 is probably an interned int, so a and b are likely referencing an object that was compiled into the interpreter.
  - icebraining 12y ago
    Yeap: >>> a = 110 >>> b = 110 >>> id(a) == id(b) True
    - deleted 12y ago
      [deleted]
      - icebraining 12y ago
        Uh, I didn't use assignment between variables; my code is the same as your second example (both variables independently assigned to 110).
        taejo 12y ago
        Indeed; I was confused by the dekhn's aside.
stuki 12y ago
That's pretty central to any OO language. "Everything's an object." Veering away from that, only serves to turn the language into a mess of boxing and unboxing. That's not to say that OO is necessarily the ideal language paradigm, but it has certainly been the most dominant in the era Python has existed.
- theseoafs 12y ago
  OO languages do not have to do this. Ruby doesn't, for instance (that is, it turns the language into a "mess of boxing and unboxing", but that's invisible to the programmer and makes working with integers so much more efficient). There's simply no reason to allocate integers on the heap -- it's a bad design desicion.
  - icebraining 12y ago
    How does Ruby know that 'a' is an integer and not any other type? Java and C# can use the variable types to track this, but I don't see how would a dynamic language work without tagging the value.
    - gregwebs 12y ago
      My understanding from 5 years ago is that in MRI the leading bit is reserved to indicate whether something is an integer. This of course reduces the size of numbers that fit into a machine word but it seems like a pretty good tradeoff.
      - lispm 12y ago
        Most Lisp systems use tags. Several data types will have tags included in the data word, like fixnums, characters. Other data types have an extra word.
      - icebraining 12y ago
        Yeah, apparently they're called tagged pointers. The More You Know. EDIT: And here's Guido explaining why he didn't want that in Python: https://mail.python.org/pipermail/python-dev/2004-July/046147.html https://mail.python.org/pipermail/python-dev/2004-July/04614...
wyager 12y ago
Something I noticed a while back is that Python already has objects pre-made for the small integers.
- koenigdavidmj 12y ago
  That's common. Same for the one-character strings. That's a sticking point with a lot of young Java programmers encountering boxed types for the first time. They see that x is true here: Integer x = new Integer(5); Integer y = new Integer(5); x == y But this is false: Integer x = new Integer(5000); Integer y = new Integer(5000); x == y (The real fix, of course, is to use the 'equals' method when comparing objects.)
  - yxhuvud 12y ago
    I'd argue the real fix is to use a language that doesn't have insane semantics for ==.
    - Terr_ 12y ago
      No, Java's semantics for == are entirely sane and straightforward: It compares primitives by value, and objects by identity in memory. The true problem is that newbies who haven't grasped the difference see that x==y in a sample program and then leap to all sorts of conclusions, overgeneralizing what they observed because they don't understand how it happened.
      - yxhuvud 12y ago
        The problem is that comparing by value is not a good default for ==. A language should strive to make the common tasks as simple as possible to do right, while not making it impossible to check object equality or some other kind of equality. Compare Ruby: 1 == 1 => true 4711 == 4711 => true 1.object_id == 1.object_id => true 4711.object_id == 4711.object_id => false
        koenigdavidmj 12y ago
sqrt17 12y ago
Actually, it's a bit more complicated: for small integers, the Python runtime has a stash of pre-made objects. For compiled code, the code may include a static reference to a constant object. Which means that, if you execute "a = 110" a bunch of times, no new objects get created. If you execute "a= 110+300" a bunch of times, a whole bunch of new objects is created and destroyed. By the way, this boxing/unboxing logic is also at work when you stick numbers into a standard HashMap, since it stores Integer objects and not the primitive type. However, in Java you can use GNU Trove's IntObjectHashMap or ObjectIntHashMap and save some memory, whereas Python's "everything is an object" rules this out (unless you're using PyPy and its tracing jit which figures out that a always contains a number).

by kghose 12y ago

taejo 12y ago

`a=110; b=a` involves only one object: 110. a and b are just names.

dekhn 12y ago
And 110 is probably an interned int, so a and b are likely referencing an object that was compiled into the interpreter.
- icebraining 12y ago
  Yeap: >>> a = 110 >>> b = 110 >>> id(a) == id(b) True
  - deleted 12y ago
    [deleted]
    - icebraining 12y ago
      Uh, I didn't use assignment between variables; my code is the same as your second example (both variables independently assigned to 110).
      - taejo 12y ago
        Indeed; I was confused by the dekhn's aside.

stuki 12y ago

That's pretty central to any OO language. "Everything's an object." Veering away from that, only serves to turn the language into a mess of boxing and unboxing. That's not to say that OO is necessarily the ideal language paradigm, but it has certainly been the most dominant in the era Python has existed.

theseoafs 12y ago
OO languages do not have to do this. Ruby doesn't, for instance (that is, it turns the language into a "mess of boxing and unboxing", but that's invisible to the programmer and makes working with integers so much more efficient). There's simply no reason to allocate integers on the heap -- it's a bad design desicion.
- icebraining 12y ago
  How does Ruby know that 'a' is an integer and not any other type? Java and C# can use the variable types to track this, but I don't see how would a dynamic language work without tagging the value.
  - gregwebs 12y ago
    My understanding from 5 years ago is that in MRI the leading bit is reserved to indicate whether something is an integer. This of course reduces the size of numbers that fit into a machine word but it seems like a pretty good tradeoff.
    - lispm 12y ago
      Most Lisp systems use tags. Several data types will have tags included in the data word, like fixnums, characters. Other data types have an extra word.
    - icebraining 12y ago
      Yeah, apparently they're called tagged pointers. The More You Know. EDIT: And here's Guido explaining why he didn't want that in Python: https://mail.python.org/pipermail/python-dev/2004-July/046147.html https://mail.python.org/pipermail/python-dev/2004-July/04614...

wyager 12y ago

Something I noticed a while back is that Python already has objects pre-made for the small integers.

koenigdavidmj 12y ago
That's common. Same for the one-character strings. That's a sticking point with a lot of young Java programmers encountering boxed types for the first time. They see that x is true here: Integer x = new Integer(5); Integer y = new Integer(5); x == y But this is false: Integer x = new Integer(5000); Integer y = new Integer(5000); x == y (The real fix, of course, is to use the 'equals' method when comparing objects.)
- yxhuvud 12y ago
  I'd argue the real fix is to use a language that doesn't have insane semantics for ==.
  - Terr_ 12y ago
    No, Java's semantics for == are entirely sane and straightforward: It compares primitives by value, and objects by identity in memory. The true problem is that newbies who haven't grasped the difference see that x==y in a sample program and then leap to all sorts of conclusions, overgeneralizing what they observed because they don't understand how it happened.
    - yxhuvud 12y ago
      The problem is that comparing by value is not a good default for ==. A language should strive to make the common tasks as simple as possible to do right, while not making it impossible to check object equality or some other kind of equality. Compare Ruby: 1 == 1 => true 4711 == 4711 => true 1.object_id == 1.object_id => true 4711.object_id == 4711.object_id => false
      - koenigdavidmj 12y ago

sqrt17 12y ago

Actually, it's a bit more complicated: for small integers, the Python runtime has a stash of pre-made objects. For compiled code, the code may include a static reference to a constant object. Which means that, if you execute "a = 110" a bunch of times, no new objects get created. If you execute "a= 110+300" a bunch of times, a whole bunch of new objects is created and destroyed. By the way, this boxing/unboxing logic is also at work when you stick numbers into a standard HashMap, since it stores Integer objects and not the primitive type. However, in Java you can use GNU Trove's IntObjectHashMap or ObjectIntHashMap and save some memory, whereas Python's "everything is an object" rules this out (unless you're using PyPy and its tracing jit which figures out that a always contains a number).