Python's 8-bit cleanness deprecated?

[Roman Suzi]

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
current encoding?

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
in time...

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
>environments.

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