New PEP: The directive statement

Martin von Loewis loewis at
Fri Mar 23 09:06:33 CET 2001

scarblac at (Remco Gerlich) writes:

> First the inconsistency: the syntax definition in (C) claims that some
> restrictions on the placement of directive may be in place, depending on
> the directive. However, (D) notes that directives must appear as the first
> non-string token in a file, for backwards compatibility. So in practice,
> directive can't be used anywhere in a file.

That's not inconsistent. There is only one directive defined so far,
to activate nested scopes, and it must appear at the top of the file.
In some later release of Python, directive will become a proper
keyword, at which time introducing directives with less strict
placement rules is possible.

> What I miss most in the 'directive' approach is the introspection. Can a
> program see which directives are on? List the current directives and their
> docstrings? Also, if I can turn on a directive further down a file, how can
> I turn it *off*?

Directives operate on a per-module basis, so from a program point of
view, they are neither on nor off (or both, in different modules).
Directives don't have docstrings (just as the print statement has no
docstring), so you can't list them. As for turning of directives: The
nested_scopes directive cannot be turned off, since the compiler needs
to know how variable binding works throughout the entire module. Other
directives may support being turned off, e.g.

directive omit_linenumbers 0 # or on
directive omit_linenumbers 1 # or off

> Transitional features are transitional for a hopefully short time. They are
> provided for people who need to test their existing software against an
> upcoming incompatible feature, and for early adopters who want the new
> feature now so they can tinker with it. The version in which the feature
> will become part of the language proper is already decided (2.2, in the case
> of nested scopes).

That concerns me about PEP 236: The absolute certainty in which people
predict the future. My experience is that the future is unpredictable
when it comes to software releases. It may turn out that there are
unforeseen problems with nested scopes, or that foreseen problems turn
out to be more serious than expected.

> The 'directive' idea still has the magical first line of the file bit, but
> it doesn't provide information to the running program about what is turned
> on.

There is nothing magical about it at all. Try placing a future import
as the second statement - it has exactly the same restriction. It's a
restriction imposed by the feature being activated, namely

> It's not possible to make a single tool once that removes unneeded
> 'directive' statements from files, or even prints a list of
> available statements.

Not true, it is certainly possible to build such a tool.

> And then the other half of the problem, use of the directive
> statement for other things. Is this vapor? I can't think of any
> useful applications at the moment

Tim claims that I invented the statement to declare file encodings,

directive encoding "koi8-r"

However, source encodings are not implemented yet, so there is no
point in defining a directive for it. Also, propagating command line
options (-U, -O, -OO) on a per-module basis would be an application.

> But you can't toggle directives

Not true, that depends on the directive.


More information about the Python-list mailing list