How do I display unicode value stored in a string variable using ord()

Mark Lawrence breamoreboy at yahoo.co.uk
Sat Aug 18 23:37:13 CEST 2012


On 18/08/2012 21:22, wxjmfauth at gmail.com wrote:
> Le samedi 18 août 2012 20:40:23 UTC+2, rusi a écrit :
>> On Aug 18, 10:59 pm, Steven D'Aprano <steve
>>
>> +comp.lang.pyt... at pearwood.info> wrote:
>>
>>> On Sat, 18 Aug 2012 08:07:05 -0700, wxjmfauth wrote:
>>
>>>> Is there any reason why non ascii users are somehow penalized compared
>>
>>>> to ascii users?
>>
>>>
>>
>>> Of course there is a reason.
>>
>>>
>>
>>> If you want to represent 1114111 different characters in a string, as
>>
>>> Unicode supports, you can't use a single byte per character, or even two
>>
>>> bytes. That is a fact of basic mathematics. Supporting 1114111 characters
>>
>>> must be more expensive than supporting 128 of them.
>>
>>>
>>
>>> But why should you carry the cost of 4-bytes per character just because
>>
>>> someday you *might* need a non-BMP character?
>>
>>
>>
>> I am reminded of: http://answers.microsoft.com/thread/720108ee-0a9c-4090-b62d-bbd5cb1a7605
>>
>>
>>
>> Original above does not open for me but here's a copy that does:
>>
>>
>>
>> http://onceuponatimeinindia.blogspot.in/2009/07/hard-drive-weight-increasing.html
>
> I thing it's time to leave the discussion and to go to bed.

In plain English, duck out cos I'm losing.

>
> You can take the problem the way you wish, Python 3.3 is "slower"
> than Python 3.2.

I'll ask for the second time.  Provide proof that is acceptable to 
everybody and not just yourself.

>
> If you see the present status as an optimisation, I'm condidering
> this as a regression.

Considering does not equate to proof.  Where are the figures which back 
up your claim?

>
> I'm pretty sure a pure ucs-4/utf-32 can only be, by nature,
> the correct solution.

I look forward to seeing your patch on the bug tracker.  If and only if 
you can find something that needs patching, which from the course of 
this thread I think is highly unlikely.


>
> To be extreme, tools using pure utf-16 or utf-32 are, at least,
> considering all the citizen on this planet in the same way.
>
> jmf
>


-- 
Cheers.

Mark Lawrence.



More information about the Python-list mailing list