Python's 8-bit cleanness deprecated?
rnd at onego.ru
Tue Feb 4 06:42:54 CET 2003
On Mon, 3 Feb 2003, Scott David Daniels wrote:
>OK, the suggestion about the proper encoding format was mine.
>As I am a vi-bigot, I chose the non-vi standard in part to
>demonstrate that I was advising, "choose someone elses's
>standard, don't invent your own."
And that is good suggestion. I am both hands for
-*--thingie. However, I do not like Deprecation warnings!
It will be nightmare for maintainance people and
also newbies will feel themselves bad.
>The reason we want it in the file is that we want your script,
>when e-mailed to a Japanese user, to still run "correctly."
I do not belive my terminal can show even latin-1 as it's
tuned for cyrillic.
And what if I include some raw 8-bit character missing in the
No-no. Encodings must not generate warnings! Especially
deprecation ones. Also, will it mean that the program will
refuse to run if encoding is wrong?
If it will be the case, Python will be no better than Java
which was constantly missing some fonts on my computer
when I tried various programs.
I blame myself for not checking the PEP with the suggestion
I think raw 8bit must be set by default without any warnings.
>Remember that we want to check for multiple encodings: the
>encoding will be source-file specific so an "import" is pretty
>much a bad idea to solve it(since the imported file may be in
>another format). This should allow you to use modules built
>in several different encodings in the same program, rather than
>having to translate every source code you get to your encoding.
>Imagine the problem of a "CPAN"-like code repository with people
>editting and checking in code from different source code
This is completely another matter. Python coding style
suggest writing such programs with English comments.
>-Scott David Daniels
>Scott.Daniels at Acm.Org
Sincerely yours, Roman Suzi
rnd at onego.ru =\= My AI powered by Linux RedHat 7.3
More information about the Python-list