Organized a little bit; merged in some items from the 1.5.2p2 branch that
did not get handled.
This commit is contained in:
parent
e7aa5dc5bb
commit
e39dab6ce1
62
Doc/TODO
62
Doc/TODO
|
@ -1,6 +1,18 @@
|
|||
PYTHON DOCUMENTATION TO-DO LIST -*- indented-text -*-
|
||||
===============================
|
||||
|
||||
General
|
||||
-------
|
||||
|
||||
* Figure out HTMLHelp generation for the Windows world.
|
||||
|
||||
* Straighten out random/whrandom. Things are generally in the right
|
||||
place, but need to respond to comments in email from Jan Kim
|
||||
<kim@mpiz-koeln.mpg.de>.
|
||||
|
||||
|
||||
Python/C API
|
||||
------------
|
||||
|
||||
* The "Very High Level Interface" in the API document has been
|
||||
requested; I guess it wouldn't hurt to fill in a bit there. Request
|
||||
|
@ -9,17 +21,34 @@ PYTHON DOCUMENTATION TO-DO LIST -*- indented-text -*-
|
|||
* Describe implementing types in C, including use of the 'self'
|
||||
parameter to the method implementation function. (Missing material
|
||||
mentioned in the Extending & Embedding manual, section 1.1; problem
|
||||
reported by Clay Spence <cspence@sarnoff.com>.)
|
||||
reported by Clay Spence <cspence@sarnoff.com>.) Heavily impacts one
|
||||
chapter of the Python/C API manual.
|
||||
|
||||
* In the extensions manual, more information is needed about building
|
||||
dynamically linked extensions in C++. Specifically, the extensions
|
||||
must be linked against the C++ libraries (and possibly runtime).
|
||||
Also noted by Albert Hofkamp <a.hofkamp@wtb.tue.nl>.
|
||||
* Missing PyArg_ParseTuple(), PyArg_ParseTupleAndKeywords(),
|
||||
Py_BuildValue(). Information requested by Greg Kochanski
|
||||
<gpk@bell-labs.com>. PyEval_EvalCode() has also been requested.
|
||||
|
||||
* Python/C API reference missing PyArg_ParseTuple(),
|
||||
PyArg_ParseTupleAndKeywords(), Py_BuildValue(). Information
|
||||
requested by Greg Kochanski <gpk@bell-labs.com>. PyEval_EvalCode()
|
||||
has also been requested.
|
||||
Extending & Embedding
|
||||
---------------------
|
||||
|
||||
* More information is needed about building dynamically linked
|
||||
extensions in C++. Specifically, the extensions must be linked
|
||||
against the C++ libraries (and possibly runtime). Also noted by
|
||||
Albert Hofkamp <a.hofkamp@wtb.tue.nl>.
|
||||
|
||||
Reference Manual
|
||||
----------------
|
||||
|
||||
* Document the Extended Call Syntax in the language reference.
|
||||
[Jeremy Hylton]
|
||||
|
||||
* Document new comparison support for recursive objects (lang. ref.?
|
||||
library ref.? (cmp() function). [Jeremy Hylton]
|
||||
|
||||
Library Reference
|
||||
-----------------
|
||||
|
||||
* urllib2 module reference. [Jeremy Hylton]
|
||||
|
||||
* Update the pickle documentation to describe all of the current
|
||||
behavior; only a subset is described. __reduce__, etc. Partial
|
||||
|
@ -27,15 +56,15 @@ PYTHON DOCUMENTATION TO-DO LIST -*- indented-text -*-
|
|||
|
||||
* Update the code/codeop module documentation.
|
||||
|
||||
* Figure out HTMLHelp generation for the Windows world.
|
||||
|
||||
* Straighten out random/whrandom.
|
||||
|
||||
* Update the filecmp documentation (Moshe?).
|
||||
|
||||
* Update the httplib documentation to match Greg Stein's HTTP/1.1
|
||||
support and new classes. (Greg, this is yours!)
|
||||
|
||||
Tutorial
|
||||
--------
|
||||
|
||||
* Update tutorial to use string methods and talk about backward
|
||||
compatibility of same.
|
||||
|
||||
|
||||
NOT WORTH THE TROUBLE
|
||||
---------------------
|
||||
|
@ -45,7 +74,8 @@ NOT WORTH THE TROUBLE
|
|||
<lorenzo@argon.roma2.infn.it>. This one will be hard; probably not
|
||||
really worth the pain. (Only an issue at all when a header-letter
|
||||
and the first index entry get separated -- can change as soon as we
|
||||
change the index entries in the text.)
|
||||
change the index entries in the text.) Also only a problem in the
|
||||
print version.
|
||||
|
||||
* Fix problem with howto documents getting the last module synopsis
|
||||
twice (in \localmoduletable) so we can get rid of the ugly 'uniq'
|
||||
|
|
Loading…
Reference in New Issue