4 ms·
The author intentionally chooses decomposed form. Indeed all of them work with Python 3. Here: Python 3.3.2+ (default, Oct 9 2013, 14:50:09) [GCC 4.8
by brihat 13y ago
The author intentionally chooses decomposed form. Indeed all of them work with Python 3. Here:
Python 3.3.2+ (default, Oct 9 2013, 14:50:09)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> noel="noël"
>>> noel[::-1] # reverse
'lëon'
>>> noel[0:3] # first three characters
'noë'
>>> len(noel) # length
4
The point is, defining what is a character based on how it is displayed is flawed. Just precompose the string ifg you want and carry on. Like I said in my other comment, making automatic conversion of decomposed -> precomposed wrecks havoc with Indian languages.
- jfim 13y agoWorks as expected too in Scala, although it might be because the terminal does normalization. scala> val noel = "Noël" noel: String = Noël scala> noel.reverse res0: String = lëoN scala> noel.take(3) res1: String = Noë scala> noel.length res2: Int = 4 scala> import java.text.Normalizer val nfdNoel = Normalizer.normalize(noel, Normalizer.Form.NFD) import java.text.Normalizer scala> nfdNoel: String = Noël scala> nfdNoel.length res3: Int = 5 scala> nfdNoel.reverse res4: String = l̈eoN scala> nfdNoel.take(3) res5: String = Noe The problem with an array of characters, as he mentions, is that it doesn't work properly in many use cases. If your array of characters stores 16 bit codepoints, it breaks with the 32 bit codepoints (Java got bit hard by that, where a char used to be a character prior to the introduction of surrogate pairs in Unicode); if it stores 32 bit codepoints, then it's pretty wasteful in most cases, which is exactly why you'd want a string type that handles storage of series of characters in an optimal fashion.