This blog post is
12 years old! Most likely, its content is outdated.
Especially if it's technical.
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
This was changed to:
if type_ is u'textarea':
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
Remember:
>>> "peter" is u"peter"
False
>>> "peter" == u"peter"
True
>>> None is None
True
>>> None == None
True
- Previous:
- Solar power in the north African desert
29 November 2006
- Next:
- CSS selector bug in IE?
05 December 2006
- Related by Keyword:
- How to slice a rune in Go
16 March 2015
- Sending HTML emails in Zope
26 October 2006
- Unicode strings to ASCII ...nicely
08 August 2006
- Valuble site: Commonly Confused Characters
28 December 2004
- Matrix ASCII animated!
15 November 2003
- Related by Text:
- jQuery and Highslide JS
08 January 2008
- I'm back! Peterbe.com has been renewed
05 June 2005
- Anti-McCain propaganda videos
12 August 2008
- Ever wondered how much $87 Billion is?
04 November 2003
- Guake, not Yakuake or Yeahconsole
23 January 2010
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
>>> a ="p"+"eter"
>>> b = "peter"
>>> a is b
False
>>> a
'peter'
>>> b
'peter'
>>>
so you should use e.g.
"müsli" == u"müsli".encode("utf-8")
You only need Unicode for strings displayed to the user.
never ever try to do things more complicated than they need to be!
I don´t know if this would be better (performance wise) than use "==". I do know "==" have a little extra overhead versus "is". But in the case of "in" would be good to see which one perform better.