Python's 8-bit cleanness deprecated?

Chris Liechti cliechti at gmx.net
Wed Feb 5 00:21:54 CET 2003


Roman Suzi <rnd at onego.ru> wrote in news:mailman.1044337448.21865.python-
list at python.org:

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

i don't like the "-*-" and especialy not that it is a comment.
a comment is a comment is a comment. it gets very confusing when
a comment alters the behaviour of a program (yes its only a warning, but i 
consider programs that are issuing warnings as unfinished).

"#-*- coding: latin1 -*-" may look nice to a all time vi user but most 
users are NOT using vi or emacs. to me it does not look very pythoninc
it's not easy to remeber, it's not helping my editor as it does not store 
it's preferences in each source file and i can't even write a one-liner 
"python -c ..." with latin1 chars.
we're not writing python _for_ vi but python _with_ vi, are we?

we're speaking german here and i will have to explain to every newbie why 
he has to write that magic string in each and every source file as he 
will use his native language it his first scripts...

the "#!..." line is a completly other thing. it has NO effect on python. it 
has an effect on the environment that a script loads. it does not change 
the behaviour of a python script. it cannot be compared to the encoding 
comment.

> However, I do not like Deprecation warnings!
> It will be nightmare for maintainance people and
> also newbies will feel themselves bad.

no warnings for me please... it makes older python programs
appearing as bad software, which is simply not true.
this means that i'll get a warning for a program that was perfectly valid 
and ran error free.

we're using python at work and many programs use german comments
and strings and getting a warning for these is wrong in my optinion.
 
worst thing i've seen so far is the perl waring about unknown locale
on all the GNU/Linux Debian Woody boxes for each and every perl script.
so i'm getting warnings for apt-get and lots other tools.

luckly it seems, that according to the PEP, warnings are only issued
when a non-ascii character is found and not like perl, but still, this 
means a lot of warnings...
the warning is not much to the help the user, the developer should get it.
how about displaying the warning only with __debug__ == 1 and making
__debug__ == 0 as default for future python releases?

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

right, the source encoding won't change the fact that a (winblows) DOS box 
wont display any non-ASCII chatacter as you want...
 
> I think raw 8bit must be set by default without any warnings.

I think it should work as in 2.2 without warnings, or that the warnings are 
off by default.
 
>>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.

that's no argument against a "form __encoding__ import latin1" from which i 
thing it would be more pythonic. its as easy to handle as the magic 
comment. and we already have import that do not realy import (see 
__future__ ;-)
 
>>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.

which is a good *sugestion*. but i don't like warnings for programs that 
are not following this advise... do you realy care in which language the 
comments of a working module are? do you wan't to see a warning even if you 
don't ever look at the source?

my summary:
- comments with effect on code is a bad idea
- "#-*- coding: latin1 -*-" does not look pythonic/nice
- a warning gives a bad impression on (older) python programs
- the ability to specify the source encoding is a good idea but should
  not be enforced by filling the screen with warnings instead of useful 
  program output.

chris

-- 
Chris <cliechti at gmx.net>





More information about the Python-list mailing list