<br><br><div><span class="gmail_quote">On 1/4/07, <b class="gmail_sendername">M.-A. Lemburg</b> &lt;<a href="mailto:mal@egenix.com">mal@egenix.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 2007-01-03 01:42, Brett Cannon wrote:<br>&gt; On 1/2/07, M.-A. Lemburg &lt;<a href="mailto:mal@egenix.com">mal@egenix.com</a>&gt; wrote:<br>&gt;&gt; &gt;&gt; &gt; +Open Issues<br>&gt;&gt; &gt;&gt; &gt; +===========<br>
&gt;&gt; &gt;&gt; &gt; +<br>&gt;&gt; &gt;&gt; &gt; +Consolidate dependent modules together into a single module or<br>&gt;&gt; &gt;&gt; package?<br>&gt;&gt; &gt;&gt; &gt; ...<br>&gt;&gt; &gt;&gt; &gt; +Consolidate certain modules with similar themes together in a
<br>&gt;&gt; package?<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; +----------------------------------------------------------------------<br>&gt;&gt; &gt;&gt; &gt; ...<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; If you do follow this route, please take the chance to place
<br>&gt;&gt; &gt;&gt; the whole Python stdlib under a single package. That way we&#39;ll<br>&gt;&gt; &gt;&gt; avoid name clashes with existing packages and modules now and<br>&gt;&gt; &gt;&gt; in the future.<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; That has been suggested before (including by me) and Guido has always<br>&gt;&gt; shot<br>&gt;&gt; &gt; it down.&nbsp;&nbsp;That&#39;s why I left it out of this proposal.<br>&gt;&gt;<br>&gt;&gt; Even if it is shot down again, it still deserves to be documented
<br>&gt;&gt; together with the reasons for being shot down.<br>&gt;&gt;<br>&gt;&gt; This is a one-in-a-lifetime chance, so it would be sad if it were<br>&gt;&gt; not taken into account.<br>&gt;&gt;<br>&gt;&gt; The extra effort would be minimal - the renaming would have to be
<br>&gt;&gt; done using a script anyway and adding an extra &#39;from py import &#39;<br>&gt;&gt; prefix to the modules wouldn&#39;t really make the renaming more<br>&gt;&gt; complicated ;-)<br>&gt;<br>&gt;<br>&gt; I was about to start writing an open issue on this since the biggest
<br>&gt; objection from Guido I could find on this topic is<br>&gt; <a href="http://mail.python.org/pipermail/python-dev/2002-July/026409.html">http://mail.python.org/pipermail/python-dev/2002-July/026409.html</a> , but<br>
&gt; then<br>&gt; it started to feel like a separate PEP to me.&nbsp;&nbsp;So I think I am going to<br>&gt; pass<br>&gt; on taking on this topic and let someone else tackle it in a PEP.&nbsp;&nbsp;Sorry,<br>&gt; MAL, but I need to worry about my sanity on this one.&nbsp;&nbsp;=)
<br><br>Oh well, it seemed like a perfect fit for the scope of PEP 3108.</blockquote><div><br>I know, but I honestly just don&#39;t have the energy to deal with it.&nbsp; If you want to spear-head the discussion and help me add it to the PEP, then that&#39;s great. 
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Guido&#39;s reply seems to suggest that he&#39;s in favor of introducing<br>a multi-package stdlib structure:
<br><br>&quot;&quot;&quot;<br>&gt; &gt; I&#39;m rejecting the proposal of a single top-level package named &quot;python&quot;.<br>&gt;<br>&gt; You&#39;ve written that before, but you still haven&#39;t given any<br>&gt; explanation of why a single package would be worse than a
<br>&gt; multi-level hierarchy of modules (e.g. grouped by application<br>&gt; space).<br><br>Because a single package doesn&#39;t have any other benefits besides<br>getting out of the way from 3rd party developers.<br><br>
At least a proper hierarchy would have the other benefits of grouping.<br>(But better make it a shallow hierarchy!&nbsp;&nbsp;remember &quot;Flat is better<br>than nested.&quot;)<br>&quot;&quot;&quot;<br><br>AFAICT, he was only objecting having a single package without any
<br>extra restructuring.</blockquote><div><br>Yep.&nbsp; PEP 3108 does have some basic package suggestions in the Open Issues section and people seem to support them.&nbsp; I will be making a separate push for them on python-3000 once the whole discussion of what modules to remove has settled down.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Then again, the post is from 2002 - so things may have changed.</blockquote><div>
<br>Maybe.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There have been a couple of attempts to reorg the stdlib into<br>packages, but AFAIR, I see, all of them were withdrawn
<br>due to the problem of finding a suitable grouping (often enough,<br>a module would be suitable for more than just one functional<br>package, e.g. urllib would fit &quot;io&quot; as well as &quot;net&quot;) or<br>lack of support from the developers.
</blockquote><div><br>Yep, that&#39;s what has happened. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Now that we&#39;re discussing moving the include files into
<br>a subdirectory (for much the same reasons), I think it&#39;s<br>time to reboot the discussion of a Python package with or<br>without possible subpackages.</blockquote><div><br>Well, perhaps other people want to show support if they like the idea?&nbsp; I am personally split down the middle either way.
<br><br>-Brett<br></div></div><br>