One thing I forgot to say in the initial email was that I am being intentially heavy-handed with restrictions on people to get some dialog and see where people think things are okay and not.<br><br><div><span class="gmail_quote">
On 6/12/06, <b class="gmail_sendername">Raymond Hettinger</b> <<a href="mailto:rhettinger@ewtllc.com">rhettinger@ewtllc.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Brett Cannon wrote:<br><br>> This is purely about figuring out what is required for accepting a<br>> module and for pruning out what we don't want that we currently have.<br><br><br>Well intentioned, but futile. Each case ultimately gets decided on its
<br>merits. Any one reason for inclusion or exclusion can be outweighed by<br>some other reason. There isn't a consistent ruleset that explains<br>clearly why decimal, elementtree, email, and textwrap were included<br>while Cheetah, Twisted, numpy, and BeautifulSoup were not.
</blockquote><div><br>True. And notice none of my points say that some package must have been used in the community for X number of months or have Y number of users across Z operating systems. That is not the point of the PEP.
<br><br>The points I laid out are not that rigid and are basically what we follow, but centralized in a single place. Plus it codifies how we want to handle contributed code in terms of how flexible we want to be for handling people's wants on how we touch their code in the repository. A PEP on this would give us something to point to when people email the list saying, "I want to get this module added to the stdlib" and prevent ourselves from repeating the same lines over and over and let people know what we expect.
<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;">Overly general rules are likely to be rife with exceptions and amount to<br>useless administrivia. I don't think these contentious issues can be
<br>decided in advance. The specifics of each case are more relevant than a<br>laundry list of generalizations.</blockquote><div><br>I don't think the points made are that unreasonable. Following formatting guidelines, signing a contributor agreement, etc. are not useless administrivia. The PEP requirement maybe. And stating what python-dev is willing to do in terms of maintenance I think is totally reasonable to state up front.
<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;">> First, the modules must have been in the wild and used by the<br>> community. This has worked well so far by making sure the code is
<br>> stable and that the API is good.<br><br><br>Nice guideline, but the decimal module did not meet that test.</blockquote><div><br>Right, so? The decimal module would have most likely been picked up eventually; maybe not
2.3 but at some point. Having it available during dev would have counted as use in the community anyway.<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;">
For AST,<br>the stability criterion was tossed and the ultimate API is still in<br>limbo.</blockquote><div><br>The AST is not a stdlib thing, in my opinion. That was back-end stuff. Plus you can't provide AST access directly without mucking with the internals anyway, so that basically requires dev within at least a branch.
<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;"> Itertools went in directly.</blockquote><div><br>Once again, fine, but would that have prevented it from ever going in? I doubt that. I know you did a lot of asking the community for what to include and such. Had you done that externally while working on it and then propose it to python-dev once you were satisfied with the implementation it probably would have gone right in.
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> However, the tried and true mxTools<br>never went in, and the venerable bytecodehacks never had a chance.
<br><br><br>><br>> Second, the code must follow Python coding guidelines.<br><br>We already have a PEP for that.</blockquote><div><br>Yeah, and yet we still accept stuff that does not necessarily follow those PEPs. I am not saying we need to write those PEPs, again, but say that those PEPs *must* be followed.
<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;">><br>> Third, a PEP discussing why the module should go in.<br><br>We don't need a PEP for every module. If the python-dev discussion says
<br>we want it and Guido approves, then it is a done deal.</blockquote><div><br>Look at pysqlite. We went through that discussion twice. Most module discussions end up being rather long and having a single place where stuff is written would be nice.
<br><br>But I don't view this as a necessary step.<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;">><br>> Now, another thing is backwards compatibility.
<br><br>Isn't there already a PEP where people can add portability restrictions<br>(i.e. having decimal continue to work on Py2.3?<br><br><br></blockquote></div><br><br>Yep, PEP 291. What I am asking here is whether contributers should be able to request compatibility restrictions on the source code at all. As I said, I purposely went heavy-handed in this to get feedback from people. The points I made are all very python-def friendly and not external developer friendly. But we need to discuss that to get an idea of what python-dev is willing to do to get external contributions for the stdlib.
<br><br>-Brett<br>