That it's not appropriate for the
distro maintainers to look at the spec and the reference (pure Python)
implementatation and say "yes, we want this, go write the C version
and we'll include it after it's had some testing".
I know that I'm not going to give a blanket promise to include some code in the future. I can give blanket promises to *review* such code. Actually, assuming I find the time, I will review *any* code that is contributed.
When the inestimable Alexbot went to O'Reilly to pitch "Python in a Nutshell", I'm sure they didn't tell him "go write the whole book from cover to cover, circulate it for at least a year and get it thoroughly reviewed, and if enough people recommend it, then and only then will we begin to think about distributing it ourselves".
Sure. That is because O'Reilly is willing to take a financial risk of failure of a book product. I'm not willing to take similar risks for Python code (risk of having to redesign the interface, fix bugs in the implementation, or have the submitter run away after the contribution).
Similarly, look at how the whole PEP process works. There are lots of times when a PEP has been accepted before any working code is distributed.
Indeed. For new language features, it is more difficult to try them out
in advance than for new library API. As a result, flaws of the new feature are often only fully understood years after the new feature
first gets released. For an example, consider the buffer interface.
To take your view to an extreme, no project should even have a task list of desired features that people are invited to implement.
Taking it to the extreme misses the point. I'm asking for field testing for new modules - not for all changes.
That's bizarre and abnormal as a development process. What kind of development process in industry doesn't decide whether to include a feature, until after the feature is completely implemented at a production scale?
Any high-quality standardization process. Standards in IETF and OMG are only accepted after implementations have been available.
You seem to have the attitude that since volunteer development effort doesn't consume actual PSF funds, the volunteer effort is worth nothing and can be expended arbitrarily. The volunteers may not feel that way.
The volunteers are free to work on whatever they please. If you chose not to write an AES module - that's fine with me. Still, people do contribute to Python, and they do so without asking for permission first. Typically, they develop the code because it solves their own needs - then it doesn't really matter whether it also solves the needs of others.
In either case, the user would best use the pre-compiled binary that
somebody else provided for the platform.
Who's the "somebody else"?
Some user. I find that users contribute binaries for all kinds of platforms for the code I publish. This is how open source works.
Do you do that with your own modules, and still say that it's easy?
I publish or link to binaries of my code that others have created, and find no problems in doing so.
Unless your requirement is different than what you say it is, I do see what it is, and I'm saying it's better to do what normal projects do and what Python has done in the past. That is, it's perfectly ok to decide to do something and then do it, rather than insisting, bizarrely, that it always be the other way around.
No, it's three steps 1. decide that you want to do it 2. do it 3. decide whether you are pleased with the result, and only use it if you are
IOW, there should not be a blanket guarantee to use it after step 1.
I think that question isn't the right one. We need to ask how many users the sha module was required to have, before Greg and Andrew could have reasonable confidence that the sha module would go into the core once it was tested enough and shown to be reliable.
They did not have *any* guarantee until they asked. I guess when they asked it was accepted immediately.
I suspect they were able to have that confidence long before testing was complete, and maybe before implementation even started.
I'm pretty certain that you are wrong with that assumption. Again, we would have to ask - but I would not be surprised if AMK started implementing the module without even *considering* a later inclusion in the Python core at that time. He has done so on many occasions (include PyXML, which I inherited from him).
Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
