New Python block cipher API, comments wanted

[Chad Netzer]

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/

Chad Netzer
(any opinion expressed is my own and not NASA's or my employer's)