[Python-Dev] Sharing expat instances

[Steve Holden]

Michael McLay wrote:
> On Wednesday 14 December 2005 01:05, Fredrik Lundh wrote:
> 
>>Michael McLay wrote:
>>
>>>Avoiding imaginaary name collisions and putting cElementTree into the xml
>>>package
>>
>>there's nothing imaginary here -- cElementTree is an existing and quite
>>popular module, and will remain available as a separate distribution.
>>
>>it would be nice if people could install that kit also under 2.5 without
>>risking to mess up their Python installation.
>>
>>(another solution would of course to rule out use of cElementTree by
>>modules shipped with Python...)
> 
> 
> Renaming the cElementTree in the standard distribution to etree would 
> elmiinate collisions with the existing cElementTree. A few other names to 
> consider would be xmltree or xmlTree.  Or, if the consensus is to keep it in 
> the xml package, the name could still be shorted to calling it xml.tree.  
> 
> Average name lengths in the standard distribution are getting longer. In some 
> cases the longer names are very helpful when browsing the module index. For 
> instance, the function of SimpleXMLRPCServer is immediately apparent. To me, 
> the purpose of a package named ElementTree isn't as apparent. While there is 
> value in having meaningful names, there is also an advantage in having names 
> short for commonly used tools. Imagine how painful it would be to type 
> Operatingsystem instead of os. The name xmltree would be shorter and as 
> descriptive as xml.cElementTree. The name etree would be shorter, but less 
> descriptive.

Which reminds me, what about the idea of reducing certain packages 
(Carbon, dostutils and email come to mind) to just a single entry in the 
global module index and adding a first-level TOC at the beginning of 
that section of content?

Even if we then have to call it the global package and module index!

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                  www.python.org/pycon/