forked from python/peps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
pep-0244.txt
174 lines (122 loc) · 6.19 KB
/
pep-0244.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
PEP: 244
Title: The `directive' statement
Version: $Revision$
Last-Modified: $Date$
Author: martin@v.loewis.de (Martin von Löwis)
Status: Rejected
Type: Standards Track
Created: 20-Mar-2001
Python-Version: 2.1
Post-History:
Motivation
From time to time, Python makes an incompatible change to the
advertised semantics of core language constructs, or changes their
accidental (implementation-dependent) behavior in some way. While
this is never done capriciously, and is always done with the aim
of improving the language over the long term, over the short term
it's contentious and disrupting.
PEP 1, Guidelines for Language Evolution[1] suggests ways to ease
the pain, and this PEP introduces some machinery in support of
that.
PEP 2, Statically Nested Scopes[2] is the first application, and
will be used as an example here.
When a new, potentially incompatible language feature is added,
some modules and libraries may chose to use it, while others may
not. This specification introduces a syntax where a module author
can denote whether a certain language feature is used in the
module or not.
In discussion of this PEP, readers commented that there are two
kinds of "settable" language features:
- those that are designed to eventually become the only option, at
which time specifying use of them is not necessary anymore. The
features for which the syntax of the "Back to the __future__"
PEP 236, Back to the __future__[3] was proposed fall into this
category. This PEP supports declaring such features, and
supports phasing out the "old" meaning of constructs whose
semantics has changed under the new feature. However, it
defines no policy as to what features must be phased out
eventually.
- those which are designed to stay optional forever, e.g. if they
change some default setting in the interpreter. An example for
such settings might be the request to always emit line-number
instructions for a certain module; no specific flags of that
kind are proposed in this specification.
Since a primary goal of this PEP is to support new language
constructs without immediately breaking old libraries, special
care was taken not to break old libraries by introducing the new
syntax.
Syntax
A directive_statement is a statement of the form
directive_statement: 'directive' NAME [atom] [';'] NEWLINE
The name in the directive indicates the kind of the directive; it
defines whether the optional atom can be present, and whether
there are further syntactical or semantical restrictions to the
atom. In addition, depending on the name of the directive,
certain additional syntactical or semantical restrictions may be
placed on the directive (e.g. placement of the directive in the
module may be restricted to the top of the module).
In the directive_statement, 'directive' is a new
keyword. According to [1], this keyword is initially considered as
a keyword only when used in a directive statement, see "Backwards
Compatibility" below.
Semantics
A directive statement instructs the Python interpreter to process
a source file in a different way; the specific details of that
processing depend on the directive name. The optional atom is
typically interpreted when the source code is processed; details
of that interpretation depend on the directive.
Specific Directives: transitional
If a syntactical or semantical change is added to Python which is
incompatible, [1] mandates a transitional evolution of the
language, where the new feature is initially available alongside
with the old one. Such a transition is possible by means of the
transitional directive.
In a transitional directive, the NAME is 'transitional'. The atom
MUST be present, and it MUST be a NAME. The possible values for
that name are defined when the language change is defined. One
example for such a directive is
directive transitional nested_scopes
The transitional directive MUST occur at before any other
statement in a module, except for the documentation string
(i.e. it may appear as the second statement of a module only if
the first statement is a STRING+).
Backwards Compatibility
Introducing 'directive' as a new keyword might cause
incompatibilities with existing code. Following the guideline in
[1], in the initial implementation of this specification,
directive is a new keyword only if it was used in a valid
directive_statement (i.e. if it appeared as the first non-string
token in a module).
Unresolved Problems: directive as the first identifier
Using directive in a module as
directive = 1
(i.e. the name directive appears as the first thing in a module)
will treat it as keyword, not as identifier. It would be possible
to classify it as a NAME with an additional look-ahead token, but
such look-ahead is not available in the Python tokenizer.
Questions and Answers
Q: It looks like this PEP was written to allow definition of source
code character sets. Is that true?
A: No. Even though the directive facility can be extended to
allow source code encodings, no specific directive is proposed.
Q: Then why was this PEP written at all?
A: It acts as a counter-proposal to [3], which proposes to
overload the import statement with a new meaning. This PEP
allows to solve the problem in a more general way.
Q: But isn't mixing source encodings and language changes like
mixing apples and oranges?
A: Perhaps. To address the difference, the predefined
"transitional" directive has been defined.
References and Footnotes
[1] PEP 5, Guidelines for Language Evolution, Prescod
http://www.python.org/dev/peps/pep-0005/
[2] PEP 227, Statically Nested Scopes, Hylton
http://www.python.org/dev/peps/pep-0227/
[3] PEP 236, Back to the __future__, Peters
http://www.python.org/dev/peps/pep-0236/
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: