What's so funny? WAS Re: rotor replacement

[Paul Rubin]

"Martin v. Löwis" <martin at v.loewis.de> writes:
> 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.

Why is it different if a single new function is added to an existing
module, or if the single new function has the boilerplate of a new
module wrapped around it?

Look at the sha and md5 modules.  They are very similar in both
interface and implementation.  The only internal function that's
really different is the update operation; they actually might have
been combined into one module that did the other operations with the
same code.  But, it's also reasonable to have them as separate
modules.  If users start needing sha256, it could be done the same
way, one new update operation and the rest boilerplate, but in
practice it would probably be a separate module.

Are you saying if there was user demand for an sha256 module and
someone wrote one, you'd still require a year of separate distribution?

> 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.

I previously had the mistaken belief that urandom was a new module
rather than a function inserted into an existing module.  Note that
the urandom's implementation is not ultra-trivial.

An AES or DES addition to an existing module that implements just one
call:
   ECB(key, data, direction)
would be a huge improvement over what we have now.  A more complete
crypto module would have some additional operations, but ECB is the
only one that's really essential.  I already have a pure-Python module
that does all the other operations using ECB as a subroutine.
It's speed isn't great but it's useable in some real applications.
It's only the ECB operation that's intolerably slow in Python.

If you think a function like that could be added to some existing
module with less hassle than adding a new module, then I can write one
and submit it.

> > 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.

Well, volunteers are more likely to work on modules that are mentioned
as being welcome by the developers, than modules affected by explicit
prior developers' public decisions that cast a chill over the hope of
ever getting such a module accepted.

> Furthermore, people who want an AES module for Python could get one from

Come on, you're being deliberately obtuse, we've discussed this over
and over.  There are plenty of AES modules that people can get from
somewhere.  The topic is what it takes to have an AES module that
people don't NEED to get from anywhere, because they already have it
from having Python installed.  Do I have to keep repeating "batteries
included" until you understand what it means?

> http://sourceforge.net/projects/cryptkit/
> 
> Maybe Bryan Mongeau will contribute this code to Python some day.

Well, that code has been around for over a year, people are using it,
etc.  Are you saying you'll support its inclusion if Bryan offers to
contribute it?  I've examined that module, I wouldn't consider it
ideal for the core (besides AES, it has some complicated additional
functions that aren't useful to most people), but it would certainly
take care of my AES needs (it's apparently missing DES though).

> 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.

I would say that inviting people to work on a module for the stdlib
means the developers have thought about whether such a module would be
useful and worth including, and are indicating that they're favorable
to the idea.  However, you wrote:

   In Message-ID: <41f4324a$0$1547$9b622d9e at news.freenet.de>
   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.

The context was new modules in general, not specifically an AES
module.  Since "considered" means "thought about", so you said
inclusion shouldn't even be thought about until the module is already
done.  That's completely in conflict with the idea of inviting anyone
to work on a new module, since inviting means that there's been some
thought.

> 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.

I would say there's an implied promise of something more than a code
review.  There's an implied statement that you agree that the proposed
new functionality is useful, which means the patch has a good chance
of being accepted to the stdlib if it's not too messy or cumbersome.
That's a heck of a lot different from saying "why don't you write that
patch and distribute it independently for a year on a purely
speculative basis, and then I'll think about whether it's worthwhile
to include it or not".

> As it appears to be clear that you are not going to implement an AES
> module in the foreseeable future, 

The reason for that is as far as I can tell, even if I follow 100% of
your prescription of writing the module, releasing it independently
and supporting it for a year, and then offering to contribute it
complete with favorable user reviews and a promise of two years of
further support, the probability of it being accepted and included is
still close to zero.  In more recent messages you've suggested that my
reading of that probability is wrong and that it's actually higher
than zero.

So let me just ask you one final question: suppose I do all that
stuff.  The question: in your personal opinion, based on the best
information you have, what is the your own subjective estimate of the
probability?

I won't say I'd immediately replace my estimate with yours, but if you
name a reasonably high number and tell me that you really believe that
number, then I could get interested again.

> 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.

Well, you can have whatever views you want, but one I've thing I've
realized from this thread is that many of the frustrations I often
encounter with Python are a direct result of a development process
that's successful in some ways but dysfunctional in others.