On 4/25/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I was in my second class of the Python workshop I'm giving here in one
Argentine University, and I was explaining how to think using
name/object and not variable/value.
Using id() for being pedagogic about the objects, the kids saw
On 4/26/05, Greg Ewing [EMAIL PROTECTED] wrote:
Also, string literals that resemble Python identifiers
are often interned, although this is not guaranteed.
And this only applies to literals, not strings constructed
dynamically by the program (unless you explicitly apply
intern() to them).
Facundo Batista wrote:
Aargh! Bad explanation. Or at least you're missing something:
Not really. It's easier for me to show that id(3) is always the same
and id([]) not, and let the kids see that's not so easy and you'll
have to look deeper if you want to know better.
I think Guido was saying that
On 4/22/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Is there a document that details which objects are cached in memory
(to not create the same object multiple times, for performance)?
why do you think you need to know?
I was in my second class of the Python workshop I'm giving here in one
I was in my second class of the Python workshop I'm giving here in one
Argentine University, and I was explaining how to think using
name/object and not variable/value.
Using id() for being pedagogic about the objects, the kids saw that
id(3) was always the same, but id([]) not. I explained
Facundo Batista wrote:
Is there a document that details which objects are cached in memory
(to not create the same object multiple times, for performance)?
why do you think you need to know?
If not, could please somebody point me out where this is implemented
for strings?
Objects/stringobject.c
