Johan von Boisman wrote:
> Is there ever a reason _not_ to exclusively use the unicode stringtype
> throughout your Python program?
speed and memory use. in 2.5, the unicode datatype is almost often as
fast as the string type at the algorithm level, but it's still limited
by memory bandwidth
On Nov 17, 9:18 pm, Johan von Boisman <[EMAIL PROTECTED]> wrote:
> I missed the beginning of this thread, but why not write
>
> s = u"äÄöÖüÜß"
>
> Is there ever a reason _not_ to exclusively use the unicode stringtype
> throughout your Python program? (of course you may need to encode/decode
> wh
[EMAIL PROTECTED] wrote:
> Hello,
> I think this remark is more to the point. In my experience, the general
> problem is that python operates with the default encoding "ascii" as in
> sys.getdefaultencoding(). It is possible to set the defaultencoding in
> sitecustomize.py, with sys.setdefaultencod
Hello,
I think this remark is more to the point. In my experience, the general
problem is that python operates with the default encoding "ascii" as in
sys.getdefaultencoding(). It is possible to set the defaultencoding in
sitecustomize.py, with sys.setdefaultencoding('latin1'). I have placed
sitecu
"kath" wrote:
> Also python IDLE is able to output the same character corretly when I
> say print and why not I?
probably because IDLE's interactive window is Unicode-aware, but your terminal
is not.
--
http://mail.python.org/mailman/listinfo/python-list
kath wrote:
> Hi all,
>
> Platform:winxp
> Version: Python 2.3
>
> I have a task of reading files in a folder and creating an one excel
> file with sheets, one sheet per file, with sheet named as filename. I
> am facing problem in handling special characters. I am using XLRD
Hi all,
Platform:winxp
Version: Python 2.3
I have a task of reading files in a folder and creating an one excel
file with sheets, one sheet per file, with sheet named as filename. I
am facing problem in handling special characters. I am using XLRD and
XLW package to read/w
