mirror of
				https://github.com/python/cpython.git
				synced 2025-11-03 19:34:08 +00:00 
			
		
		
		
	merge 11164
This commit is contained in:
		
						commit
						7c038b4726
					
				
					 9 changed files with 10 additions and 105 deletions
				
			
		| 
						 | 
				
			
			@ -187,7 +187,7 @@ modules using the Distutils:
 | 
			
		|||
module distribution
 | 
			
		||||
   a collection of Python modules distributed together as a single downloadable
 | 
			
		||||
   resource and meant to be installed *en masse*.  Examples of some well-known
 | 
			
		||||
   module distributions are Numeric Python, PyXML, PIL (the Python Imaging
 | 
			
		||||
   module distributions are NumPy, SciPy, PIL (the Python Imaging
 | 
			
		||||
   Library), or mxBase.  (This would be called a *package*, except that term is
 | 
			
		||||
   already taken in the Python context: a single module distribution may contain
 | 
			
		||||
   zero, one, or many Python packages.)
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -25,8 +25,7 @@ report of the imported modules will be printed.
 | 
			
		|||
.. function:: ReplacePackage(oldname, newname)
 | 
			
		||||
 | 
			
		||||
   Allows specifying that the module named *oldname* is in fact the package named
 | 
			
		||||
   *newname*.  The most common usage would be  to handle how the :mod:`_xmlplus`
 | 
			
		||||
   package replaces the :mod:`xml` package.
 | 
			
		||||
   *newname*.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
.. class:: ModuleFinder(path=None, debug=0, excludes=[], replace_paths=[])
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -60,12 +60,8 @@ functions do not provide a parser implementation themselves.
 | 
			
		|||
You can also create a :class:`Document` by calling a method on a "DOM
 | 
			
		||||
Implementation" object.  You can get this object either by calling the
 | 
			
		||||
:func:`getDOMImplementation` function in the :mod:`xml.dom` package or the
 | 
			
		||||
:mod:`xml.dom.minidom` module. Using the implementation from the
 | 
			
		||||
:mod:`xml.dom.minidom` module will always return a :class:`Document` instance
 | 
			
		||||
from the minidom implementation, while the version from :mod:`xml.dom` may
 | 
			
		||||
provide an alternate implementation (this is likely if you have the `PyXML
 | 
			
		||||
package <http://pyxml.sourceforge.net/>`_ installed).  Once you have a
 | 
			
		||||
:class:`Document`, you can add child nodes to it to populate the DOM::
 | 
			
		||||
:mod:`xml.dom.minidom` module.  Once you have a :class:`Document`, you
 | 
			
		||||
can add child nodes to it to populate the DOM::
 | 
			
		||||
 | 
			
		||||
   from xml.dom.minidom import getDOMImplementation
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -30,13 +30,6 @@ The Document Object Model is being defined by the W3C in stages, or "levels" in
 | 
			
		|||
their terminology.  The Python mapping of the API is substantially based on the
 | 
			
		||||
DOM Level 2 recommendation.
 | 
			
		||||
 | 
			
		||||
.. XXX PyXML is dead...
 | 
			
		||||
.. The mapping of the Level 3 specification, currently
 | 
			
		||||
   only available in draft form, is being developed by the `Python XML Special
 | 
			
		||||
   Interest Group <http://www.python.org/sigs/xml-sig/>`_ as part of the `PyXML
 | 
			
		||||
   package <http://pyxml.sourceforge.net/>`_.  Refer to the documentation bundled
 | 
			
		||||
   with that package for information on the current state of DOM Level 3 support.
 | 
			
		||||
 | 
			
		||||
.. What if your needs are somewhere between SAX and the DOM?  Perhaps
 | 
			
		||||
   you cannot afford to load the entire tree in memory but you find the
 | 
			
		||||
   SAX model somewhat cumbersome and low-level.  There is also a module
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
	Add table
		Add a link
		
	
		Reference in a new issue