Mobile version of this page
Previous:
Solar power in the north African desert
Next:
CSS selector bug in IE?
Unicode strings to ASCII ...nicely
Sending HTML emails in Zope
Valuble site: Commonly Confused Characters
Save this page in del.icio.usSolar power in the north African desert
Next:
CSS selector bug in IE?
Related blogs
Matrix ASCII animated!Unicode strings to ASCII ...nicely
Sending HTML emails in Zope
Valuble site: Commonly Confused Characters
Related by category
is is not the same as equal in Python
1st of December 2006
Don't do the silly misstake that I did today. I improved my code to better support unicode by replacing all plain strings with unicode strings. In there I had code that looked like this:
if type_ is 'textarea':
do something
do something
This was changed to:
if type_ is u'textarea':
do something
do something
And it no longer matched since type_ was a normal ascii string. The correct wat to do these things is like this:
if type_ == u'textarea':
do something
elif type_ is None:
do something else
do something
elif type_ is None:
do something else
Remember:
>>> "peter" is u"peter"
False
>>> "peter" == u"peter"
True
>>> None is None
True
>>> None == None
True
False
>>> "peter" == u"peter"
True
>>> None is None
True
>>> None == None
True
Comment
David Goodger -
1st December 2006
[«« Reply to this]
That ("peter" is "peter") works at all is an implementation quirk that shouldn't be relied upon, even for 8-bit strings.
That ("peter" is "peter") works at all is an implementation quirk that shouldn't be relied upon, even for 8-bit strings.
kevin -
1st December 2006
[«« Reply to this]
Hi Peter,
You're mixing up identity with equality...easily done :-)
While it's true that...
"peter" == "peter" and
"peter" is "peter"
you'll note that:
"peter" is "peter1"[:-1] is not true while
"peter" == "peter1"[:-1] is
Hope this sheds some light :-)
The interpreter is obviously using two references to the same string "peter" in the first case, but is creating a new string in the second example.
Kevin
Hi Peter,
You're mixing up identity with equality...easily done :-)
While it's true that...
"peter" == "peter" and
"peter" is "peter"
you'll note that:
"peter" is "peter1"[:-1] is not true while
"peter" == "peter1"[:-1] is
Hope this sheds some light :-)
The interpreter is obviously using two references to the same string "peter" in the first case, but is creating a new string in the second example.
Kevin
Guillaume Proux -
1st December 2006
[«« Reply to this]
yes what you are doing was dangerous EVEN with plain 8bit data; check this:
>>> a ="p"+"eter"
>>> b = "peter"
>>> a is b
False
>>> a
'peter'
>>> b
'peter'
>>>
yes what you are doing was dangerous EVEN with plain 8bit data; check this:
>>> a ="p"+"eter"
>>> b = "peter"
>>> a is b
False
>>> a
'peter'
>>> b
'peter'
>>>
Gerhard Kalab -
1st December 2006
[«« Reply to this]
"peter" == u"peter" will raise a UnicodeDecodeError if you compare "müsli" instead of "peter"
so you should use e.g.
"müsli" == u"müsli".encode("utf-8")
"peter" == u"peter" will raise a UnicodeDecodeError if you compare "müsli" instead of "peter"
so you should use e.g.
"müsli" == u"müsli".encode("utf-8")
sdsdff -
12th December 2006
[«« Reply to this]
Why would you ever use Unicode strings in the internal types?
You only need Unicode for strings displayed to the user.
Why would you ever use Unicode strings in the internal types?
You only need Unicode for strings displayed to the user.
Anonymous -
12th December 2006
[«« Reply to this]
This is the reason for loving python:
never ever try to do things more complicated than they need to be!
This is the reason for loving python:
never ever try to do things more complicated than they need to be!
You should really only use 'is' to check for object identity, and for any kind of value comparison, == is the way to go. Also, as you yourself point out, the changes you made make no difference at all, unless there are non-ascii characters in the string you are comparing the variable to, so in the case of 'textarea', I would have just left it as is. ;)