Python's 8-bit cleanness deprecated?

[Roman Suzi]

On Fri, 7 Feb 2003, Jp Calderone wrote:

>On Sat, Feb 08, 2003 at 01:21:33AM +0200, Kirill Simonov wrote:
>> * Jp Calderone <exarkun at intarweb.us>:
>> > On Sat, Feb 08, 2003 at 12:48:46AM +0200, Kirill Simonov wrote:
>> > > * Jp Calderone <exarkun at intarweb.us>:
>> > > > Source files that are using non-ASCII encodings are precisely
>> > > > the ones that this feature benefits.
>> > > > It allows anyone to look at these files and actually *read* them.
>> > > 
>> > > The only editor that can read the encoding declaration is emacs. Do you
>> > > assume that *anyone* use emacs?
>> > 
>> >   Who said anything about -reading- the encoding declarations?
>> 
>> You wrote "It allows anyone to look at these files and actually
>> *read* them". I thought that you meant decoding source files according
>> to the encoding declaration. 
>> 
>
>  Ahh, true.  I should have phrased that better.
>
>  What I meant was that while the editor might be smart enough to pick up
>the encoding, the actual person doing the reading should *always* be smart
>enough to see "coding: <something>" in the first two lines and take the
>appropriate action to have the source display properly.

And what if source get automatically recoded?  Say, web-browser can
automatically detect encoding and save source in some other
encoding. Then in order to run the program I need to change it.

>  With no encoding specified at all, it can be an exercise in futility to
>get a source file rendered properly.

It was working all the way before 2.3a! And there were no great problems. I
wonder why anything should change. While coding-feature will benefit somewhere
sometimes, it will spoil impressions of all others.

So, I support Kirill's solution. Let's not make Python backward-incompatible
in such big way. For us, it's like banning string literals...


Sincerely yours, Roman Suzi
-- 
rnd at onego.ru =\= My AI powered by Linux RedHat 7.3