Fix showstopper SF bug #442983: use of site.addsitedir() was broken
because it references the global dirs_in_sys_path which is deleted.
The fix avoids deleting that global.
(My email through python.org or digicool.com is non-functional at the
moment; use gvanrossum@home.com to reach me.)
This is a Windows-specific glitch that's really due to that, e.g.,
ntpath.join("c:", "/abc") returned "/abc" instead of "c:/abc". Made
join smarter.
Bugfix candidate.
Reorganize so the initialization sequences does not bite us in the foot.
(There is no good reason to discard classes that clients may want to
subclass.)
****************
PyShell: Added functionality:
usage: idle.py [-c command] [-d] [-i] [-r script] [-s] [-t title] [arg] ...
idle file(s) (without options) edit the file(s)
-c cmd run the command in a shell
-d enable the debugger
-i open an interactive shell
-i file(s) open a shell and also an editor window for each file
-r script run a file as a script in a shell
-s run $IDLESTARTUP or $PYTHONSTARTUP before anything else
-t title set title of shell window
Remaining arguments are applied to the command (-c) or script (-r).
******************
idles: Removed the idles script, not needed
******************
idle: Removed the IdleConf references, not required anymore
was already correctly parsed (contrary to a comment in Mailman).
test_rfc2822_phrases(): RFC 2822 now requires that we allow `.' in
phrases, which means we must accept dots in unquoted realname parts.
Add a test to check the change in rfc822.py 1.58.
now allowed in unquoted RealName areas (technically, they are defined
as "obsolete syntax" we MUST accept in phrases, as part of the
obs-phrase production). Thus, parsing
To: User J. Person <person@dom.ain>
correctly returns "User J. Person" as the RealName.
AddrlistClass.__init__(): Add definition of self.phraseends which is
just self.atomends with `.' removed.
getatom(): Add an optional argument `atomends' which, if None (the
default) means use self.atomends.
getphraselist(): Pass self.phraseends to getatom() and break out of
the loop only when the current character is in phraseends instead of
atomends. This allows dots to continue to serve as atom delimiters in
all contexts except phrases.
Also, loads of docstring updates to document RFC 2822 conformance
(sorry, this should have been two separate patches).
Added a patch which modifies idlefork so that it can co-exist with
"official" IDLE in the site-packages directory. This patch is not
necessary if only idlefork IDLE is installed. See INSTALLATION for further
details.
The default behaviour of idlefork idle is to open an editor window instead
of a shell. Complex expressions may be run in a fresh environment by
selecting "run". There are times, however, when a shell is desired.
Though one can be started by "idle -t 'foo'", this script is more
convenient. In addition, a shell and an editor window can be started
in parallel by "idles -e foo.py".
that 'yield' is a keyword. This doesn't help test_generators at all! I
don't know why not. These things do work now (and didn't before this
patch):
1. "from __future__ import generators" now works in a native shell.
2. Similarly "python -i xxx.py" now has generators enabled in the
shell if xxx.py had them enabled.
3. This program (which was my doctest proxy) works fine:
from __future__ import generators
source = """\
def f():
yield 1
"""
exec compile(source, "", "single") in globals()
print type(f())
The default behaviour of idlefork idle is to open an editor window instead
of a shell. Complex expressions may be run in a fresh environment by
selecting "run". There are times, however, when a shell is desired.
Though one can be started by "idle -t 'foo'", this script is more
convenient. In addition, a shell and an editor window can be started
in parallel by "idles -e foo.py".
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.
