PEP 285. Everything described in the PEP is here, and there is even
some documentation. I had to fix 12 unit tests; all but one of these
were printing Boolean outcomes that changed from 0/1 to False/True.
(The exception is test_unicode.py, which did a type(x) == type(y)
style comparison. I could've fixed that with a single line using
issubtype(x, type(y)), but instead chose to be explicit about those
places where a bool is expected.
Still to do: perhaps more documentation; change standard library
modules to return False/True from predicates.
code (if it isn't open already).
PythonIDE still opens the resource file "manually" because it also uses
presence of the CURS resource to determine whether it needs to adjust
sys.path.
457466: popenx() argument mangling hangs python
226766: popen('python -c"...."') tends to hang
Fixes argument quoting in w9xpopen.exe for Windows 9x. w9xpopen.exe
also never attempts to display a MessageBox when not executed
interactively.
Added test_popen() test. This test currently just executes
"python -c ..." as a child process, and checks that the expected
arguments were all recieved correctly by the child process. This
test succeeds for me on Win9x, win2k and Linux, and I hope it does
for other popen supported platforms too :)
types for each code, and give the actual C types.
Clarified the support for slice operations and note when some TypeError
exceptions are raised.
This closes SF bugs 518767 and 536469.
the manual refer to it.
XXX Not sure that it belongs in this section, or that the concept is
particularly important for writing documentation. Perhaps references
to the frame should be removed entirely.
Replace section 4.1 with section A.3.
The new section 4.1 is titled "Naming and binding." It includes the
text of section A.3 augmented with some of the detailed text from the
old section 4.1.
The \dfn, \index stuff is probably wrong, but I tried.
Also update other parts of appendix A to mention that nested scopes
and generators are standard features.
possible pool states. I think it's much clearer now.
Added a new long overdue block-management overview comment block.
I believe the comments are in good shape now.
Added two comments about possible small optimizations (one getting rid
of runtime multiplications at the cost of a new pool_header member; the
other getting rid of runtime divisions and the pool_header capacity
member, at the cost of a static const vector of 32 uints).
Split the description of co_flags into two paragraphs. The first
describes the flags that are used for non-future purposes, where
CO_GENERATOR was added. The second describes __future__'s use of
co_flags and mentions the only one currently meaningful,
CO_FUTURE_DIVISION.