The note example might be abit better than you think (see below),
though I still think Omer's beads example is better.
The important part common to both is that the example should not consist
merely of letters, but must include some container too.
Not only does the empty string comes naturally this way, but it shows
that an empty string (string with no beads) is not the same as an empty
list (empty piece of paper).
References:
'Take some more tea,' the March Hare said to Alice, very earnestly.
'I've had nothing yet,' Alice replied in an offended tone, 'so I
can't take more.'
'You mean you ca'n't take /LESS/,' said the Hatter, 'it's very easy
to take /MORE/ than nothing.'
Lewis Carrol / Alice's Adventures in Wonderland / Chapter 7
For text-adventure games fans, a ref to the "no tea" object from
Douglas Adams' "The Hitchhiker's Guide to the Galaxy":
http://www.everything2.com/index.pl?node_id=29864
>
>
> */guy keren <[EMAIL PROTECTED]>/* wrote:
>
>
> 4. the empty string realy confused them. since i didn't think
> about it in
> advance, i was puzzled about how to explain what an empty string is.
> need to prepare a good analogy for such abstract things next time (and
> lets face it - there are no intuitive "empty strings" in real life.
> no - a blank note is not exactly the same as an "empty string").
>
> This can be visualized in the following way:
> A string is a note which you can write words in it. an empty string is
> an empty note.
> You lose some of the flexibility in this visualization (how can you
> change a letter if it is already written down? you don't erase and
> write in python, you just write over it.,
No you don't -
you do exactly the same as you would with your note: you create a new
one with desired contents and use it instead (possibly leaving the old
note hanging around for the garbage-man to collect ;-) ).
> and, a note has a final size limitation, while a string, for any
> everyday usage, doesn't have one.)
>
> you also lose the ability to explain:
> >>> a = ""
> >>> b = ""
> >>> a == b
> True
> >>> a is b
> True
> >>> a = "1"+"2"
> >>> b = "1"+"2"
> >>> a == b
> True
> >>> a is b
> False
>
Why would you want to explain that? That's merely an implementation
dependant coincidence. Certainly not part of the language.
Would you want to explain this:
>>> "a b" is "a b"
True
>>> x = "a b"
>>> y = "a b"
>>> x is y
False
(try it - I think the result depends on the value of the string, maybe
also on the room temperature or something ;-) )
Quoting guido from here:
http://mail.python.org/pipermail/python-dev/2004-March/043235.html
"The language spec explicitly *allows* but does not *require* the
implementation to cache and reuse immutable values."
