Le samedi 18 août 2012 19:28:26 UTC+2, Mark Lawrence a écrit : > > Proof that is acceptable to everybody please, not just yourself. > > I cann't, I'm only facing the fact it works slower on my Windows platform.
As I understand (I think) the undelying mechanism, I can only say, it is not a surprise that it happens. Imagine an editor, I type an "a", internally the text is saved as ascii, then I type en "é", the text can only be saved in at least latin-1. Then I enter an "€", the text become an internal ucs-4 "string". The remove the "€" and so on. Intuitively I expect there is some kind slow down between all these "strings" conversion. When I tested this flexible representation, a few months ago, at the first alpha release. This is precisely what, I tested. String manipulations which are forcing this internal change and I concluded the result is not brillant. Realy, a factor 0.n up to 10. This are simply my conclusions. Related question. Does any body know a way to get the size of the internal "string" in bytes? In the narrow or wide build it is easy, I can encode with the "unicode_internal" codec. In Py 3.3, I attempted to toy with sizeof and stuct, but without success. jmf -- http://mail.python.org/mailman/listinfo/python-list
