Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder4.news.weretis.net!news.mixmin.net!hq-usenetpeers.eweka.nl!81.171.88.15.MISMATCH!eweka.nl!lightspeed.eweka.nl!194.109.133.85.MISMATCH!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Return-Path: <wxjmfauth@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.006
X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'say,': 0.05; 'subject:How': 0.09; 'encode': 0.09; 'forcing': 0.09; 'happens.': 0.09; 'internally': 0.09; 'lawrence': 0.09; 'release.': 0.09; 'sizeof': 0.09; 'subject:()': 0.09; 'subject:string': 0.09; 'subject:using': 0.09; 'to:addr:comp.lang.python': 0.09; 'cc:addr :python-list': 0.10; 'alpha': 0.15; '3.3,': 0.16; 'ascii,': 0.16; 'editor,': 0.16; 'subject:unicode': 0.16; 'subject:variable': 0.16; 'ucs-4': 0.16; 'string': 0.17; 'windows': 0.19; 'question.': 0.20; 'cc:2**0': 0.23; 'cc:no real name:2**0': 0.24; 'least': 0.25; 'cc:addr:python.org': 0.25; 'header:In-Reply-To:1': 0.25; 'header:User-Agent:1': 0.26; 'attempted': 0.29; 'facing': 0.29; 'factor': 0.29; "i'm": 0.29; 'related': 0.30; 'expect': 0.31; 'received:google.com': 0.34; 'text': 0.34; 'acceptable': 0.35; 'saved': 0.35; 'received:209.85.220': 0.35; 'received:209.85': 0.35; 'there': 0.35; 'but': 0.36; 'success.': 0.36; 'does': 0.37; 'received:209': 0.37; 'subject:: ': 0.38; 'mark': 0.38; 'fact': 0.38; 'some': 0.38; 'build': 0.39; 'skip:" 10': 0.40; 'from:no real name:2**0': 0.60; 'remove': 0.61; 'first': 0.61; 'kind': 0.61; 'wide': 0.62; 'please,': 0.62; 'between': 0.63; '10.': 0.64; 'become': 0.65; 'charset:windows-1252': 0.65; 'surprise': 0.65; 'everybody': 0.69; 'samedi': 0.84; 'subject:value': 0.84; 'toy': 0.84; 'concluded': 0.91; 'received:209.85.220.184': 0.91; 'imagine': 0.96
Newsgroups: comp.lang.python
Date: Sat, 18 Aug 2012 11:05:07 -0700 (PDT)
In-Reply-To: <mailman.3462.1345310859.4697.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=83.78.79.69; posting-account=ung4FAoAAAC46zhHJ0Nsnuox7M5gDvs_
References: <f801e06f-f7b2-4aca-b352-66856a939746@googlegroups.com> <308df2af-abe7-4043-b199-0a39f440e0ab@googlegroups.com> <502f8a2a$0$29978$c3e8da3$5496439d@news.astraweb.com> <d575737d-c1e3-47db-9c7b-10fe0300cba7@googlegroups.com> <mailman.3457.1345305136.4697.python-list@python.org> <4c62a649-bc21-4e47-9c0f-acb1b1e70e36@googlegroups.com> <mailman.3462.1345310859.4697.python-list@python.org>
User-Agent: G2/1.0
X-Google-Web-Client: true
X-Google-IP: 83.78.79.69
MIME-Version: 1.0
Subject: Re: How do I display unicode value stored in a string variable using ord()
From: wxjmfauth@gmail.com
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Message-ID: <mailman.3467.1345313116.4697.python-list@python.org>
Lines: 37
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1345313116 news.xs4all.nl 6950 [2001:888:2000:d::a6]:47634
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:27321

Le samedi 18 ao=FBt 2012 19:28:26 UTC+2, Mark Lawrence a =E9crit=A0:
>=20
> Proof that is acceptable to everybody please, not just yourself.
>=20
>=20
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 "=E9", the text can only
be saved in at least latin-1. Then I enter an "=80", the text
become an internal ucs-4 "string". The remove the "=80" 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,=20
I attempted to toy with sizeof and stuct, but without
success.

jmf