Oops, sorry, it's in the os module:
http://docs.python.org/lib/os-miscfunc.html
The difference is simply a matter of the packaging.
No, it's not. It also is a matter of code size, and impact. Small additions can be reviewed and studied more easily, and need to be tested on less users. A new module is on a larger scale than a mere new function.
> Unless you're saying that if I
wanted to add AES to the string module (so you could say 'spam and sausage'.aes_encrypt('swordfish banana')) instead of writing a
separate module, then we wouldn't need this discussion.
Indeed, if it was a single new function to an existing module, I would not require that this be delivered to users first. It is entire new libraries that I worry about.
If you would propose a change to the string module to add an aes_encrypt function, I would immediately reject that patch, of course, because that function does not belong to the string module.
What matters is the code complexity, not whether something is in a separate module or not.
A module *is* typically more complex than a single function. If your new module has only a single new function, we should discuss whether it really needs to be a separate module.
Well, if he indicates that it's not a policy and that the question is still open, then I could see getting interested again in writing an AES module. At the moment I continue to see his python-dev post as quite discouraging.
And, again, I consider this perfectly fine. This would be a volunteer effort, and volunteers are free to work on whatever they please.
Furthermore, people who want an AES module for Python could get one from
http://sourceforge.net/projects/cryptkit/
Maybe Bryan Mongeau will contribute this code to Python some day.
Not true. For example, you once invited me to work on an ancillary message feature for the socket module (SF bug 814689), and so it's been on my want-to-do-one-of-these-days list since then. I think it's reasonable for me to have taken your message there as an expression of interest, sufficient to get me to want to work on it. So it's bogus to say the Python developers should avoid expressing interest in something that hasn't already been written.
I did not say that. I said we don't normally invite people to work on anything - I said not that we *should* not invite them. Now that you mention it, I find that there is an important exception from my factual statement: I do regularly ask people reporting bugs or requesting features to work fixing the bugs or implementing the features. It is perfectly fine if they say "no" then. If they say yes, there is an implied promise that I'll review their code when they are done.
As it appears to be clear that you are not going to implement an AES module in the foreseeable future, and as it also seems to be clear that you cannot talk me into changing my views on how Python should be developed, I think further discussing this entire thing is pointless.
Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list