[Python-Dev] directive statement (PEP 244)
Guido van Rossum
Mon, 16 Jul 2001 14:24:21 -0400
> > MAL seems to want two other changes: directive should be allowed
> > (required???)
> "allowed" not "required".
but last I looked if there was a docstring before the directive you
couldn't guarantee that the directive applied.
> > before the module docstring, and it should support the
> > syntax from his proto-PEP (directive key = value).
> > But MAL and PaulP don't seem to agree on the semantics of this
> > directive, and I haven't gotten a good answer why we can't do that
> > with a magic comment.
> We don't ?
It seems to me that each post from you gets a response from Paul with
some kind of objection, and vice versa. Maybe you're converging, but
I don't see where you are converging yet. Also, your arguments
sometimes seem contradictory. For example, Paul has said that you may
need a comment with an editor-specific encoding indicator, while you
were expecting editors to look at the directive and made this a reason
why the directive should precede the docstring.
> Paul suggested adding encoding directives for 8-bit
> strings and comments, but these cannot be used by the Python
> compiler in any way and would only be for the benefit of an
> editor, so I don't really see the need for them.
Another indication you two aren't on the same page just yet.
> A programmer
> can still add some editor specific comment to the source file
> to tell the editor in what encoding to display the file, but this
> information is really only useful for the editor, not the
> Python compiler.
This redundancy worries me though. Are we going to encourage people
to use an editor-specific comment for each editor out there that could
be used to touch the file?
> About the magic comment: Unicode literals are translated into
> Unicode objects at compile time. The encoding information is
> vital for the decoding to succeed. If you place this information
> into a comment of the Python source code and have the compiler
> depend on it, removing the comment would break your program.
Yes, and so would removing a directive. I don't see the point at
> I don't think that's good language design (besides, we already
> have enough Unicode magic in Python already...), but then
> people may feel different about this.
Directives come with their own set of magic.
> > In the mean time, I've decided to enable the yield keyword with a
> > future statement. In general I now prefer using future statements for
> > enabling future features over the directive statement.
> > So it's still unclear if we want a directive...
> One way or another we need a way to specify compiler parameters
> and settings on a per-source file basis. Whether you call it
> directive, pragma or magic comment is really secondary and only
> a matter of language design.
I still haven't seen this need demonstrated. Most purported uses of
these are better done with existing mechanisms. For example, in PEP
253 I propose an assignment to a global __metaclass__ to set the
default class for a baseless class statement.
> I've only chosen PEP 244 as basis for the PEP because it seemed
> to fit the need. If you decide to go down some other path,
> then I'll happily update the PEP to whatever becomes part of
But you're implying without clearly specifying all sorts of amendments
to PEP 244, which weakens your position.
For example, PEP 244 allows a doc string before the directive, but you
indicated that the directive can only affect strings that occur after
it. I don't think this is true: the creation of actual string objects
is done after the whole file has been parsed, is it wouldn't be hard
to collect and interpret all directives before creating code objects.
--Guido van Rossum (home page: http://www.python.org/~guido/)