This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients belopolsky, lemburg, loewis, pbnan
Date 2010-11-28.19:35:10
SpamBayes Score 5.2691044e-05
Marked as misclassified No
Message-id <4CF2AEED.7090500@egenix.com>
In-reply-to <4CF2A879.1040507@egenix.com>
Content
It is still strange that the .isspace() property value changed,
since the code point has not changed in the recent Unicode versions:

4.1.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
5.1.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
5.2.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
6.0.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;

based on http://www.unicode.org/Public/<version>/ucd/UnicodeData.txt

True
> python2.5 -c 'print u"\u200b".isspace()'
True
> python2.6 -c 'print u"\u200b".isspace()'
True
> python2.7 -c 'print u"\u200b".isspace()'
False

Looking at the code again: Now I know why...

The tables in unicodectype.c were generated from the Unicode database,
but not by the makeunicodedata.py script. I used a script to generate
those tables for Python 1.6.0 and it seems that they were never updated
since then. Python 2.7 then replaced them with the data from the
makeunicodedata.py script.

That's probably why Martin thought they were manually maintained.
History
Date User Action Args
2010-11-28 19:35:13lemburgsetrecipients: + lemburg, loewis, belopolsky, pbnan
2010-11-28 19:35:10lemburglinkissue10567 messages
2010-11-28 19:35:10lemburgcreate