What's so funny? WAS Re: rotor replacement

[Paul Rubin]

"Martin v. Löwis" <martin at v.loewis.de> writes:
> And I still stand by those blanket statements. Any new module (i.e.
> specific code) should see real users for some time before it can
> be incorporated into Python.

Let's see, the urandom module was recently released in 2.4, I think
initially at my urging.  I believe it was written just for 2.4,
combining a Windows function used only (as far as I know) by its
author, and a wrapper to read /dev/urandom on Posix systems.  It
didn't have any wide distribution or use before incorporation, and
didn't need it.  It was simple enough that a reasonable code review
and some testing on the relevant platforms was enough to make make
sure it worked properly.

> > I would say the first thing I'd request would be your sense of how
> > plausible it is that the current no-crypto policy might be relaxed.
> 
> There is no such policy in force. Different people have different
> opinions, and those opinions change over time. I cannot speak for others.

If you can't speak for others, how can you say there's no policy in
force?  If Guido says "no crypto", is that something other than a
policy?  And are you speaking for him when you say that?  <wink>

> proposed feature is good, and I said that, for an example, IETF even
> requires *two* implementations before deciding that the feature is good.

No, that's completely wrong.  IETF requires two implementations before
publishing a specification--a precise description--as a draft
standard, which means agreeing on how the feature should work at the
finest level of detail.  That's much different than merely deciding
that a feature is good and inviting people to work on it.

IETF often decides and announces that a feature is good long before
any such details are decided or agreed on.  For example, they decided
that IP connection encryption was a good feature, and appointed a
working group a general mandate to go figure out the details (IPSEC)
and write a spec.  See?  IETF announced in advance that IPSEC was a
good feature, and the working group members knew of that decision
before they committed the resources needed to write the draft.  And
when they started, there were zero actual IPSEC implementations,
because nobody knew what precise characteristics IPSEC would
eventually have.  The implementations got written in the process of
developing the spec and presenting it as a standard.

The two-implementation policy means there has to be two
implementations before the draft is finally declared complete, not
before the IETF can announce that it wants a standard to be written
and intends to use whatever the working group comes up with once the
draft and two implementations are done.  That is what happens in any
normal professional process.  Nobody commits resources to develop
something (other than for experimentation) unless they think the end
result will actually be used.  Are you really having trouble
understanding this?

> >>That's not true. PyCrypto does have AES support.
> > That's not in any Python distro that I know of.
> 
> Sure, but "Python" is more than the Python core.

Tell me again what "batteries included" means.  I personally interpret
"included" as meaning "included".  That means when I install Python,
the module is right there in the distro.  So if it's not in the
distro, Python itself doesn't have it.  "Batteries included" is an
expression of Pythonic philosophy that says: putting components that
end-users need in the distro is superior to making the users get them
from somewhere else separately.  I realize that the difference might
not matter to you, but it does matter to a heck of a lot of other
users.

> With that attitude, the patches tracker on SF would grow unbounded,
> because we *continuously* get patches that no core developer has
> any personal interest in.

Obviously those require a different type of consideration.  I'm
talking about patches where there's a core developer with an interest.
Let's say the cmath module doesn't exist and someone submits it.  It
computes functions like cos(z) for complex arguments.  If Tim, the
numerics expert, then says "this is worth having and I've examined the
code and it looks good, let's put it in", I'd say that takes care of
it, and I think that's what typically happens with real modules.  If
nobody on the core team has an informed opinion, then it has to be
decided some slower and more formal way.