+6  A: 

I strongly suspect that Python is behaving like many other languages here - recognising string constants within your source code and using a common table for those, but not applying the same rules when creating strings dynamically. This makes sense as there will only be a finite set of strings within your source code (although Python lets you evaluate code dynamically, of course) whereas it's much more likely that you'll be creating huge numbers of strings in the course of your program.

This process is generally called interning - and indeed by the looks of this page it's called interning in Python, too.

Jon Skeet
Any idea then why id("ab") == id("a"+"b") ?Would you agree that we just don't know how Python runs Ucaches ?
Denis
+9  A: 

Each implementation of the Python language is free to make its own tradeoffs in allocating immutable objects (such as strings) -- either making a new one, or finding an existing equal one and using one more reference to it, are just fine from the language's point of view. In practice, of course, real-world implementation strike reasonable compromise: one more reference to a suitable existing object when locating such an object is cheap and easy, just make a new object if the task of locating a suitable existing one (which may or may not exist) looks like it could potentially take a long time searching.

So, for example, multiple occurrences of the same string literal within a single function will (in all implementations I know of) use the "new reference to same object" strategy, because when building that function's constants-pool it's pretty fast and easy to avoid duplicates; but doing so across separate functions could potentially be a very time-consuming task, so real-world implementations either don't do it at all, or only do it in some heuristically identified subset of cases where one can hope for a reasonable tradeoff of compilation time (slowed down by searching for identical existing constants) vs memory consumption (increased if new copies of constants keep being made).

I don't know of any implementation of Python (or for that matter other languages with constant strings, such as Java) that takes the trouble of identifying possible duplicates (to reuse a single object via multiple references) when reading data from a file -- it just doesn't seem to be a promising tradeoff (and here you'd be paying runtime, not compile time, so the tradeoff is even less attractive). Of course, if you know (thanks to application level considerations) that such immutable objects are large and quite prone to many duplications, you can implement your own "constants-pool" strategy quite easily (intern can help you do it for strings, but it's not hard to roll your own for, e.g., tuples with immutable items, huge long integers, and so forth).

Alex Martelli
Is there anything of value within my answer that you don't think is covered in yours? If not, I'll delete my answer. If there is, do you want to edit it into mine and *then* I'll delete my answer?
Jon Skeet
+1 for mentioning `intern`. I had completely forgotten that this function existed. Using `joinsplit = [intern(n) for n in "\n".join(names).split()]` did the job and lowered memory usage from 4,374,528 to 3,190,783 on my MacBook.
D.Shawley
@John, I think having the two viewpoints (mine from an "insider's perspective", yours from an experienced programmer without a special "insider's perspective" on Python) is valuable as it stands -- not sure there's an optimal way to get the same "triangulation" within a single answer!
Alex Martelli
Lua always has only one instance of any particular string. It's a very neat system: a bit of overhead on string creation (very small in practice) makes all comparisons for string equality an O(1) pointer comparison.
Glenn Maynard
A: 
x = 42
y = 42
x == y #True
x is y #True

In this interaction, X and Y should be == (same value), but not is (same object) because we ran two different literal expressions. Because small integers and strings are cached and reused, though, is tells us they reference the same single object.

In fact, if you really want to look under the hood, you can always ask Python how many references there are to an object using the getrefcount function in the standard sys module returns the object’s reference count. This behavior reflects one of the many ways Python optimizes its model for execution speed.

Learning Python

Nimbuz
A: 

A side note: it is very important to know the lifetime of objects in Python. Note the following session:

Python 2.6.4 (r264:75706, Dec 26 2009, 01:03:10) 
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a="a"
>>> b="b"
>>> print id(a+b), id(b+a)
134898720 134898720
>>> print (a+b) is (b+a)
False

Your thinking that by printing the IDs of two separate expressions and noting they are equal (ergo the two expressions must be equal/equivalent/the same) is faulty. A single line of output does not necessarily imply all of its contents were created in the same single moment in time.

If you want to know if two objects are the same object, ask Python directly (using the is operator).

ΤΖΩΤΖΙΟΥ