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/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 the
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
Guido van Rossum wrote:
But for *immutable* objects (like numbers, strings and tuples) the
implementation is free to use caching. In practice, I believe ints
between -5 and 100 are cached, and 1-character strings are often
cached (but not always).
Also, string literals that resemble Python identifi
> 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 expl
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
