Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
C
cpython
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
cpython
Commits
e41195fa
Commit
e41195fa
authored
May 21, 2003
by
Jeremy Hylton
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add documentation for __future__
parent
8bea5dc8
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
69 additions
and
0 deletions
+69
-0
Doc/lib/lib__future__.tex
Doc/lib/lib__future__.tex
+69
-0
No files found.
Doc/lib/lib__future__.tex
0 → 100644
View file @
e41195fa
\section
{
\module
{__
future
__}
---
Future statement definitions
}
\declaremodule
[future]
{
standard
}{__
future
__}
\modulesynopsis
{
Future statement definitions
}
\module
{__
future
__}
is a real module, and serves three purposes:
\begin{itemize}
\item
To avoid confusing existing tools that analyze import statements
and expect to find the modules they're importing.
\item
To ensure that future
_
statements run under releases prior to 2.1
at least yield runtime exceptions (the import of
\module
{__
future
__}
will fail, because there was no module of
that name prior to 2.1).
\item
To document when incompatible changes were introduced, and when they
will be --- or were --- made mandatory. This is a form of executable
documentation, and can be inspected programatically via importing
\module
{__
future
__}
and examining its contents.
\end{itemize}
Each statment in
\file
{__
future
__
.py
}
is of the form:
\begin{verbatim}
FeatureName = "
_
Feature(" OptionalRelease "," MandatoryRelease ","
CompilerFlag ")"
\end{verbatim}
where, normally, OptionalRelease is less then MandatoryRelease, and
both are 5-tuples of the same form as
\code
{
sys.version
_
info
}
:
\begin{verbatim}
(PY
_
MAJOR
_
VERSION, # the 2 in 2.1.0a3; an int
PY
_
MINOR
_
VERSION, # the 1; an int
PY
_
MICRO
_
VERSION, # the 0; an int
PY
_
RELEASE
_
LEVEL, # "alpha", "beta", "candidate" or "final"; string
PY
_
RELEASE
_
SERIAL # the 3; an int
)
\end{verbatim}
OptionalRelease records the first release in which the feature was
accepted.
In the case of MandatoryReleases that have not yet occurred,
MandatoryRelease predicts the release in which the feature will become
part of the language.
Else MandatoryRelease records when the feature became part of the
language; in releases at or after that, modules no longer need a
future statement to use the feature in question, but may continue to
use such imports.
MandatoryRelease may also be
\code
{
None
}
, meaning that a planned
feature got dropped.
Instances of class
\class
{_
Feature
}
have two corresponding methods,
\method
{
getOptionalRelease()
}
and
\method
{
getMandatoryRelease()
}
.
CompilerFlag is the (bitfield) flag that should be passed in the
fourth argument to the builtin function
\function
{
compile()
}
to enable
the feature in dynamically compiled code. This flag is stored in the
\member
{
compiler
_
flag
}
attribute on
\class
{_
Future
}
instances.
No feature description will ever be deleted from
\module
{__
future
__}
.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment