"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > And I still stand by those blanket statements. Any new module (i.e. > specific code) should see real users for some time before it can > be incorporated into Python.
Let's see, the urandom module was recently released in 2.4, I think initially at my urging. I believe it was written just for 2.4, combining a Windows function used only (as far as I know) by its author, and a wrapper to read /dev/urandom on Posix systems. It didn't have any wide distribution or use before incorporation, and didn't need it. It was simple enough that a reasonable code review and some testing on the relevant platforms was enough to make make sure it worked properly. > > I would say the first thing I'd request would be your sense of how > > plausible it is that the current no-crypto policy might be relaxed. > > There is no such policy in force. Different people have different > opinions, and those opinions change over time. I cannot speak for others. If you can't speak for others, how can you say there's no policy in force? If Guido says "no crypto", is that something other than a policy? And are you speaking for him when you say that? <wink> > proposed feature is good, and I said that, for an example, IETF even > requires *two* implementations before deciding that the feature is good. No, that's completely wrong. IETF requires two implementations before publishing a specification--a precise description--as a draft standard, which means agreeing on how the feature should work at the finest level of detail. That's much different than merely deciding that a feature is good and inviting people to work on it. IETF often decides and announces that a feature is good long before any such details are decided or agreed on. For example, they decided that IP connection encryption was a good feature, and appointed a working group a general mandate to go figure out the details (IPSEC) and write a spec. See? IETF announced in advance that IPSEC was a good feature, and the working group members knew of that decision before they committed the resources needed to write the draft. And when they started, there were zero actual IPSEC implementations, because nobody knew what precise characteristics IPSEC would eventually have. The implementations got written in the process of developing the spec and presenting it as a standard. The two-implementation policy means there has to be two implementations before the draft is finally declared complete, not before the IETF can announce that it wants a standard to be written and intends to use whatever the working group comes up with once the draft and two implementations are done. That is what happens in any normal professional process. Nobody commits resources to develop something (other than for experimentation) unless they think the end result will actually be used. Are you really having trouble understanding this? > >>That's not true. PyCrypto does have AES support. > > That's not in any Python distro that I know of. > > Sure, but "Python" is more than the Python core. Tell me again what "batteries included" means. I personally interpret "included" as meaning "included". That means when I install Python, the module is right there in the distro. So if it's not in the distro, Python itself doesn't have it. "Batteries included" is an expression of Pythonic philosophy that says: putting components that end-users need in the distro is superior to making the users get them from somewhere else separately. I realize that the difference might not matter to you, but it does matter to a heck of a lot of other users. > With that attitude, the patches tracker on SF would grow unbounded, > because we *continuously* get patches that no core developer has > any personal interest in. Obviously those require a different type of consideration. I'm talking about patches where there's a core developer with an interest. Let's say the cmath module doesn't exist and someone submits it. It computes functions like cos(z) for complex arguments. If Tim, the numerics expert, then says "this is worth having and I've examined the code and it looks good, let's put it in", I'd say that takes care of it, and I think that's what typically happens with real modules. If nobody on the core team has an informed opinion, then it has to be decided some slower and more formal way. -- http://mail.python.org/mailman/listinfo/python-list
