Hacker News Reader

Comment by kghose | Hacker News Reader

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.

View on HN

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).

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.

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.

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.

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.

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.

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/04614...

One easy way to know is to run it a few times and observe the behavior.

This is why JIT runtimes need a "warm up time" to get really fast, say V8 for JavaScript.

Ruby -- or more precisely, MRI, though some other interpretations may do something similar -- uses the a fixed set of object_ids (which is what is stored on the stack to locate an object on the heap) for small integers, so if the object_id is within that range, the interpreter uses it directly to calculate the value, and doesn't need to go to the heap to get a value. (MRI does a similar thing with the values nil, true, and false, as well.)

Python does the same thing for integers in the range (-5, 256)

Python statically allocates small integers (-5 to 256), so you're not actually creating a new object unless you're creating one outside that range.

http://www.laurentluce.com/posts/python-integer-objects-impl...

Dynamic allocation isn't the only cost there -- a cost that's just as big when you're doing number crunching in Python is cache efficiency. If every number is on the heap, and every number in Python is ~20 bytes long, you're going to have caching problems, even if your numbers only ever range from -5 to 256.

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

And 110 is probably an interned int, so a and b are likely referencing an object that was compiled into the interpreter.

Yeap:

  >>> a = 110
  >>> b = 110
  >>> id(a) == id(b)
  True

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

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.)

I'd argue the real fix is to use a language that doesn't have insane semantics for ==.

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.

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

The #equal? method does your object_id comparison, by the way.

Ruby's default #== for new classes simply performs identity comparison, just like in Java. The difference is that Ruby has operator overloading, so all the builtin classes overload it with something sensible.

(This could work in Java, or it could go the .NET route and ban using the == operator entirely until a certain interface (.NET's IEquatable) is fulfilled.)

Reply on news.ycombinator.com