"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > There isn't. The interface might be beautifully designed, and you might > claim it is, and I would *still* require that the module gets field > testing before being incorporated into Python.
Yes, of course, that's completely reasonable. > If other people start attesting that the module is beatifully > designed, and should be included in the Python core - *then* it is > worth looking into inclusion. You said something more than that. You said it's not worth even thinking about inclusion until the finished module is actually in distribution outside the core. 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 think that's silly. (Anyway I don't think "beautifully designed" needs to be a requirement, and I don't claim to have done a beautiful design. "Gets the job done straightforwardly" is all that's needed and is all that I've aimed for). 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". More normally, he'd have given them a proposal with an outline and maybe a sample chapter and they used that to decide to give him a go-ahead. Usually at that point, they'd even also pay him some money in advance to do the rest of the work with, and promise to pay him a cancellation fee if they changed their mind about the book. I certainly never asked for anything like that from the Python guys about the crypto module. I did ask for, and receive, a "this looks good, we want it". I later heard that they backed off because of legal concerns, so I put the task aside. 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. To take your view to an extreme, no project should even have a task list of desired features that people are invited to implement. There's been numerous times when I've written something for the GNU project because it's been on a list like that, and it's been accepted after checking that it does what it's supposed to. > > I'm happy to have that kind of testing (and I requested it), given > > that the goal is inclusion in the core, and the core developers have > > told me (as they did) that the proposal looks good and they'd like to > > have the module, so I can reasonably expect it to go into the core if > > it meets its technical expectations. > > Not if I have a say in it. *Any* new module should see out-of-the-core > distribution first (unless there is BDFL pronouncement to include it, > of course). > > This really is a matter of development process, not of technical > quality. 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? They figure out what the features should be, and write them into a specification. The specification defines what features will be included. Then they implement the features. (I'm talking specificially about straightforward, well-defined features, not blue-sky or experimental concepts). You see, they decide in advance what features they're going to include, because development consumes resources and they don't want to burn resources to develop something unless they're pretty sure they're going to use the result once it's done. (Of course it doesn't always work out that way. Everyone has worked on projects that have gotten cancelled before delivery. However that by definition means that something has gone wrong. No engineer likes it when that happens.) 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. > > If the developers instead say (as they seemed to somewhat later) that > > because of legal/political concerns, there's no way the module can > > possibly go into the core no matter how good it is technically, then > > my motivation for writing the module dries up quite a bit. > > I personally would not say that, although I can imagine that some people > do say that, and I would also defend an inclusion, and push compliance > the BXA requirements so we can legally export Python out of the U.S.A. The BXA notification on the US side is pretty easy to handle, as you know. If you look at those Python-dev messages, the concern was about importing Python-with-crypto into countries like Holland, not about exporting it from the USA. Those concerns are not necessarily something to sneeze at. Salman Rushdie had to go into hiding for years, after publishing a book in England whose contents were illegal in Iran. So, I can't get too upset with the Python maintainers for deciding to stay away from such political messes, even though I don't feel such strong concern myself. > In either case, the user would best use the pre-compiled binary that > somebody else provided for the platform. Who's the "somebody else"? The module author might also not have had a compiler for that platform. Are you suggesting that he maintain his own distribution of multiple binaries, duplicating the machinery of the Python distro for managing multi-platform builds? Do you do that with your own modules, and still say that it's easy? If you don't, then how does the end user know where to get the module for his platform? > No, I'm merely repeating myself, and rephrasing each time. > I have to, because apparently you don't see what my requirement is. 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. > The original source code of the SHA-1 implementation is the NIST code > (Gutmann, then Hollerbach), so I guess that had hundreds of users before > the module was contributed to Python. Not terribly relevant, the NIST code was not a Python module. > The module itself (including the API) was written by Greg Stein and > Andrew Kuchling. I believe (without being able to verify) that they > distributed this module for quite some time, before contributing it > to Python. We would have to ask them how many users they had until > they felt confident to contribute the code. 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. I suspect they were able to have that confidence long before testing was complete, and maybe before implementation even started. That is, they were likely able to decide that the core obviously needed a sha module, before setting off to write and test one for that purpose. If Andrew is reading this, maybe he can comment. -- http://mail.python.org/mailman/listinfo/python-list
