that info to code dynamically compiled *by* code compiled with generators
enabled. Doesn't yet work because there's still no way to tell the parser
that "yield" is OK (unlike nested_scopes, the parser has its fingers in
this too).
Replaced PyEval_GetNestedScopes by a more-general
PyEval_MergeCompilerFlags. Perhaps I should not have? I doubted it was
*intended* to be part of the public API, so just did.
If a module has a future statement enabling nested scopes, they are
also enable for the exec statement and the functions compile() and
execfile() if they occur in the module.
If Python is run with the -i option, which enters interactive mode
after executing a script, and the script it runs enables nested
scopes, they are also enabled in interactive mode.
XXX The use of -i with -c "from __future__ import nested_scopes" is
not supported. What's the point?
To support these changes, many function variants have been added to
pythonrun.c. All the variants names end with Flags and they take an
extra PyCompilerFlags * argument. It is possible that this complexity
will be eliminated in a future version of the interpreter in which
nested scopes are not optional.
the internal API function to release the interned strings as the very
last thing before returning status. This aids in memory use debugging
because it eliminates a huge source of noise from the reports. This
is never called during normal (non-debugging) use because releasing
the interned strings slows Python's shutdown and isn't necessary
anyway because the system will always reclaim the memory.
regardless of whether the system getopt() does what we want. This avoids the
hassle with prototypes and externs, and the check to see if the system
getopt() does what we want. Prefix optind, optarg and opterr with _PyOS_ to
avoid name clashes. Add new include file to define the right symbols. Fix
Demo/pyserv/pyserv.c to include getopt.h itself, instead of relying on
Python to provide it.
PyRun_FileEx(). These are the same as their non-Ex counterparts but
have an extra argument, a flag telling them to close the file when
done.
Then this is used by Py_Main() and execfile() to close the file after
it is parsed but before it is executed.
Adding APIs seems strange given the feature freeze but it's the only
way I see to close the bug report without incompatible changes.
[ Bug #110616 ] source file stays open after parsing is done (PR#209)
up the _tkinter main loop. Not clear why; the _kbhit() call _tkinter
makes probably confuses the stdio library when buffering isn't set to
whatever it is by default.
- New option -x, to skip first line of script
- Use the correct platform-specific delimiter and library location in
the usage message
(Also removed two blank lines and moved one line around so that each
part of the usage message is again under 512 bytes and the whole usage
message still fits in 23 lines.)
it can be placed in the library.
Other, related changes:
- Moved the inspection of some environment variables to
Py_Initialize().
- Got rid of -s option.
- Moved Py_GetProgramName() and related logic to pythonrun.c; call
Py_SetProgramName() instead.
- Print the version header *after* successful initialization.
This used to be done whenever stdin was interactive. Now we only do
it when the -i flag is given. Also (and this is the real reason for
this fix) we explicitly allocate a buffer -- this seems to be
necessary on Windows.
even if it isn't. Changes:
- set the global flag Py_InteractiveFlag when -i is given
- call Py_FdIsInteractive() instead of isatty()
- make stdin unbuffered, too, when using -u
- make stdin and stdout line buffered, when stdin is interactive and not -u
Note that setting the environment variable PYTHONINSPECT does not have
these extra effects of -i. (Should it?)
Unlike Lee's changes, I don't set change the prompt to go to stderr
when -i is given.
Neil Schemenauer
Guido van Rossum
Tim Peters
Marc-André Lemburg
Jeremy Hylton
Barry Warsaw
Thomas Wouters
Fredrik Lundh