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 belopolsky
Recipients belopolsky, docs@python, ezio.melotti, lemburg, loewis, vstinner
Date 2010-11-30.19:10:49
SpamBayes Score 3.4101166e-11
Marked as misclassified No
Message-id <AANLkTi=FthoSgHv7_JLVxD7=HezDOZDKQm-7KBowhqDK@mail.gmail.com>
In-reply-to <1291143237.56.0.478012941258.issue10587@psf.upfronthosting.co.za>
Content
On Tue, Nov 30, 2010 at 1:53 PM, Martin v. Löwis <report@bugs.python.org> wrote:
..
> What is the issue that you are reporting? that the status quo should be documented, or that isalpha is wrong?
> These are independent - don't mix them.

This is a documentation issue.  I don't say that str.isalpha() is
necessarily wrong.  (If unicodedata had an isAlphabetic() menthod
defined as Lu + Ll + Lt + Lm + Lo, I would file a bug report for
that.)   Here, I just want to mention that proper str.isalpha()
definition is subject to debate and it being defined as Lu + Ll + Lt +
Lm + Lo may need to be marked as CPython implementation detail.  Note
that the Unicode book (sorry, don't have the page reference) advises
not to rely on catch-all APIs such as isAlphabetic(), but consult the
underlying properties directly.  I tend to agree with that because
some programs may want to treat say Roman numerals as letters and some
as numbers, so whether isAlphabetic() should include Nl category is
better left to the application.
History
Date User Action Args
2010-11-30 19:10:51belopolskysetrecipients: + belopolsky, lemburg, loewis, vstinner, ezio.melotti, docs@python
2010-11-30 19:10:49belopolskylinkissue10587 messages
2010-11-30 19:10:49belopolskycreate