Paul Rubin wrote:
If he understood how Python is actually used, he'd understand that any
C module is a lot more useful in the core than out of it.
This is non-sense. I have been distributing C modules outside
the core for quite some time now, and I found that the modules
are quite useful. distutils makes it really easy for anybody
to use them.
There are already tons of
3rd party crypto modules outside the core, and the module I was
writing wouldn't add anything useful to those.
Why do you think these are not part of the core? It's not because
they contain crypto code, or because they had been rejected. They
are primarily not included in Python because they have not been
contributed to Python, yet.
If they were contributed, a number of things still would need to
be considered, e.g. what is the size of the code, including libraries,
is the contributor really the author, is the code likely going
to be maintained, and so on. However, it never got that far.
Where does Frederik get
off lecturing me about wanting to get a module into the core, when
Guido had invited me to do precisely that with that very module?
I know that *I* am very opposed to any contribution of a larger
module that has not seen any real users, yet. So if the module
was primarily written to be included in the core, I would initially
reject it for that very reason. After one year or so in its life,
and a recognizable user base, inclusion can be considered.
I did release a replacement for the rotor module that's written in
Python, which means it's reasonably useable without being in the core.
However, while its security should be ok, to provide reasonable
performance it had to use a nonstandard algorithm and therefore isn't
good for interoperating with anything. To be both acceptably fast and
interoperable with other applications, a C module is needed.
I fail to see the problem you seem to have with C modules. They are
very easy to use if written properly.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
