New Python block cipher API, comments wanted
cnetzer at mail.arc.nasa.gov
Wed Jan 29 10:13:25 CET 2003
On Tuesday 28 January 2003 21:48, Paul Rubin wrote:
> mertz at gnosis.cx (David Mertz, Ph.D.) writes:
> > The rotor module existed before the PEP process did. If someone
> > wanted to introduce rotor today as a new addition, I would strongly
> > advocate that it not be added without a prior PEP.
> OK, look at all the other library modules introduced more recently,
> and tell me how many have PEP's. The answer is not many.
The reason for that is that most modules get developed to fulfill some
need. Then they get used more and more by people who also need it.
The code gets worked on and maintained for a while, sometimes a long
while. Eventually, the core developers see that it is useful, and
either include it in the distro (if it has shown to be well maintained,
and has good tests, and the interface is deemed elegant or pythonic),
or take the ideas and make a new but related module that they think
fits the bill. So rarely is it "PEP first, module later". Usually it
is "module first, lots of use and testing, okay we'll bless it."
I know of no new modules in recent history, proposed outside of the
core developers group, where someone says, "I'm developing this module,
here is some rough code, there are no conformance tests yet, I plan to
reimplement core parts of it in C, and I'm gonna do it all in a few
weeks because I want it to be a new module in the next alpha release."
I realize your intentions are good, and I think the code and ideas show
promise, and as I said before, your enthusiasm is helping to get people
interested in your work. But the way you floated the idea, at least in
this newsgroup, comes off as VERY presumptuous. Frankly, that is all
well and good, but when you talk about modules dealing with security
and cryptography, there are many people who appreciate a MUCH more
conservative attitude for adoption; they don't want to use security
related code written by a hotshot in a few weeks. They want testing,
testing, TESTING, and more testing. Then they want to make sure they
don't get boxed in and have to change later (they want it to work now
and forever, with as few changes as possible.)
So, while I support your goals, and plan to look into using the code a
bit, I think it is no surprise that you are getting some challenging
responses about your time table. It is just the natural way of things,
given the presentation of the ideas, and your ambitions.
Bay Area Python Interest Group - http://www.baypiggies.net/
(any opinion expressed is my own and not NASA's or my employer's)
More information about the Python-list