PEP: Defining Python Source Code Encodings

[Bengt Richter]

On Tue, 17 Jul 2001 14:47:32 -0600 (MDT), Bruce Sass <bsass at freenet.edmonton.ab.ca> wrote:

>Hi,
>
>regarding...
>
>> >Generally:  #<magic> <directive> [<arguments>]
>
>or as I should have written it...
>
>#<magic><directive> [<arguments>]
>
><...>
>> I withdraw my #!pragma (or #!pythma ;-) suggestion and propose
>> r'^\s*#pragma\s' as the magic line prefix regular expression.
>
>Why is "pragma" better <magic> than " ## ", or some other sequence of
>non-word characters?
>
>I would think that using any *word* as the <magic> is just asking for
>trouble; someone is bound to have done (or normally does) a
>block of comments where there is no space between the "#" and the
>first word of the comment (iirc, emacs handles comments in such a way
>that "#comments" is the right thing to do in some cases)... is the
>word "pragma" now illegal as the first word in such a comment, what
>does this do to any tools that automatically turn arbitrary text into
>comments?
>
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
#
# Ok, I'm not married to pragma. But the <magic> should be less
# likely than " ## " and unique enough to grep well ;-)
#
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##

If there are tools (not to mention the interpreter itself) dependent
on current syntax, perhaps the file should not be modified at all?

I.e., keep the unicode and other special file attributes or processing
directives separate, but associated, as brought up by David Eppstein.

See my other recent post in this thread for a couple alternative ideas
along those lines. There could be some real benefits to separation.

Separation would factor pre-processing out of the internal file context,
and open the door for other kinds of per-file pre-processing like
decompression etc., which have nothing to do with the python language
definition itself, yet which could be controlled as files are accessed
by the interpreter for its processing.