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 Nicholas.Cole
Recipients Arfrever, Nicholas.Cole, ezio.melotti, inigoserna, loewis, poq, tchrist, vstinner, zeha
Date 2012-03-11.11:43:09
SpamBayes Score 1.7888752e-10
Marked as misclassified No
Message-id <1331466191.22.0.664950479132.issue12568@psf.upfronthosting.co.za>
In-reply-to
Content
Poq: I agree.  Guessing from the Unicode standard is going to lead to users having to write some complicated code that people are going have to reinvent over and over, and is not going to be accurate with respect to curses.  I'd favour exposing wcwidth.

Martin: I agree that there are going to be cases where it is not correct because the terminal does something strange, but what we need is something that gets as close as possible to what the terminal is likely to be doing (the Unicode standard itself is not really the issue for curses stuff).  So whether it is called wcwidth or wcswidth I don't really mind, but I think it would be useful.

The other alternative is to include one of the other ideas that have been mentioned in this thread as part of the library, I suppose, so that people don't have to keep reinventing the wheel for themselves.  

The one thing I really don't favour is shipping something that supports wide characters, but gives the users no way of guessing whether or not that is what they are printing, because that is surely going to break a lot of applications.
History
Date User Action Args
2012-03-11 11:43:11Nicholas.Colesetrecipients: + Nicholas.Cole, loewis, vstinner, ezio.melotti, Arfrever, inigoserna, zeha, poq, tchrist
2012-03-11 11:43:11Nicholas.Colesetmessageid: <1331466191.22.0.664950479132.issue12568@psf.upfronthosting.co.za>
2012-03-11 11:43:10Nicholas.Colelinkissue12568 messages
2012-03-11 11:43:09Nicholas.Colecreate