Python's 8-bit cleanness deprecated?

[Anders J. Munch]

"Paul Rubin" <phr-n2003b at NOSPAMnightsong.com> wrote:
> Brian Quinlan <brian at sweetapp.com> writes:
> > > 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"
> >
> > It has to be a bit more special than that because the encoding must be
> > detected before the grammar is parsed. Variable assignment would be
> > acceptable, I guess, except that the assignment:
> >
> > 1. would have to use a simplified grammar
> > 2. it would have to be near the top of the file

You don't have to think about it as an assignment.  Think about it as
three lexer tokens appearing as one of the two first lines of the
file.

>
> Yes, there are similar constraints for "from __future__" declarations.
> This would be similar.

Not quite.  The point with "from __future__" is that if you try to
import a non-existant feature, you get a runtime (not a syntax) error,
which can be trapped from within the same file so you can default to
some other behaviour if the feature is missing.  But you do get an
error!  With a variable assignment, there's no error and the module
will silently do the wrong thing.

Which brings us back to "from __encodings__ import latin1", whose only
drawback is that it doesn't invoke any Emacs magic.  (And so what?
Emacs is pliable.  We'll think of something.)

Or perhaps something else that is a trappable error in Python<2.3:

__encoding__("utf-8")
__encoding__("-*- encoding: utf-8 -*-")

Again, this is not really a function call, it's just four lexer tokens
on a line at or near the top of the file.  But to an old Python it's a
NameError.

- Anders