Python's 8-bit cleanness deprecated?

Anders J. Munch andersjm at dancontrol.dk
Tue Feb 4 05:03:50 EST 2003


"Skip Montanaro" <skip at pobox.com> wrote:
> 
>     Paul> How about "from __encodings__ import latin1"?
> 
> I believe the coding cookie scheme was used because some editors already
> understand it (Emacs/XEmacs and perhaps vim).  It makes sense to go along
> with something others are already using, otherwise each file needing
> something would require two strings to specify the same thing, one for the
> editor, one for the Python interpreter.

I've had the same gut reaction as Paul ever since it was first
mentioned on c.l.p., but since I didn't have a better suggestion, I've
kept my mouth shut.

But of course, the very second 2.3a is out and it's probably too late
to change, the nature of the problem dawns on me.  Aaargh, bad timing.

The thing is, this is just syntax.  Plain and simple.  Some call it a
hint, but it's not, it's a syntactical measure that affects the
interpretation of the code that follows.  This is in exact analogy to
the r and u string prefixes.

A magic comment is syntax hidden in comments.  No more, no less.  And
hiding syntax in comments is bad for several reasons:
* Misleading the reader, who might think that comments can be ignored.
* Loss of syntax checking.  Having once spent a week on a performance
  problem in an Oracle database that turned out to be a misspelling in
  a comment-embedded optimisation hint, I can assure you that this is
  a very real problem.
* Forcing tools that read Python source code to mimic _exactly_ what
  the interpreter does.  This is really just a corollary to the
  previous item.

Now to define a not-in-comment syntax, that trivial.  Just remove the
in-comment part and write, as a statement:

-*- coding: Latin-1 -*-

- Anders






More information about the Python-list mailing list