Python's 8-bit cleanness deprecated?
Anders J. Munch
andersjm at inbound.dk
Wed Feb 5 20:28:25 CET 2003
"Paul Rubin" <phr-n2003b at NOSPAMnightsong.com> wrote:
> "Anders J. Munch" <andersjm at dancontrol.dk> writes:
> > A source encoding directive is a line containing three tokens: the
> > identfier "encoding", a colon and a string constant. The string
> > constant contains the name of the encoding, optionally surrounded by
> > "-*- coding:" and "-*-". That way you have a choice between short and
> > sweet style:
> > encoding: "latin-1"
> This isn't so great because if you insert an encoding statement, the
> script will no longer run under older Pythons like 2.2.
Is that a good or a bad thing? I'm not so sure anymore.
First, this only affects newly written modules, and new modules
intended to be useful with old Python versions have the option of
using the ascii encoding and escape sequences for the rest. It should
be trivial to write a script that converts arbitrary source code with
an encoding declaration to this form.
Second, the backwards compatibility is a mirage. If the encoding
declaration is a no-op in the older version, then for all encodings
other than Latin-1, not only will it not work, but it will silently do
the wrong thing!
> I think it's more in the Python tradition (although this particular
> tradition is one that I don't like) to use a variable:
> __encoding__ = "latin-1"
> or if necessary:
> __encoding__ = "-*- latin-1 -*-"
Not bad at all. Same number of tokens, but has a very familiar look
My only complaint is that it doesn't fail with older Python versions ;-)
More information about the Python-list