What's so funny? WAS Re: rotor replacement

[phr at localhost.localdomain]

"Martin v. Löwis" <martin at v.loewis.de> writes:
> There isn't. The interface might be beautifully designed, and you might
> claim it is, and I would *still* require that the module gets field
> testing before being incorporated into Python.

Yes, of course, that's completely reasonable.

> If other people start attesting that the module is beatifully
> designed, and should be included in the Python core - *then* it is
> worth looking into inclusion.

You said something more than that.  You said it's not worth even
thinking about inclusion until the finished module is actually in
distribution outside the core.  That it's not appropriate for the
distro maintainers to look at the spec and the reference (pure Python)
implementatation and say "yes, we want this, go write the C version
and we'll include it after it's had some testing".  I think that's
silly.  (Anyway I don't think "beautifully designed" needs to be a
requirement, and I don't claim to have done a beautiful design.  "Gets
the job done straightforwardly" is all that's needed and is all that
I've aimed for).

When the inestimable Alexbot went to O'Reilly to pitch "Python in a
Nutshell", I'm sure they didn't tell him "go write the whole book from
cover to cover, circulate it for at least a year and get it thoroughly
reviewed, and if enough people recommend it, then and only then will
we begin to think about distributing it ourselves".  More normally,
he'd have given them a proposal with an outline and maybe a sample
chapter and they used that to decide to give him a go-ahead.  Usually
at that point, they'd even also pay him some money in advance to do
the rest of the work with, and promise to pay him a cancellation fee
if they changed their mind about the book.

I certainly never asked for anything like that from the Python guys
about the crypto module.  I did ask for, and receive, a "this looks
good, we want it".  I later heard that they backed off because of
legal concerns, so I put the task aside.

Similarly, look at how the whole PEP process works.  There are lots of
times when a PEP has been accepted before any working code is
distributed.

To take your view to an extreme, no project should even have a task
list of desired features that people are invited to implement.
There's been numerous times when I've written something for the GNU
project because it's been on a list like that, and it's been accepted
after checking that it does what it's supposed to.

> > I'm happy to have that kind of testing (and I requested it), given
> > that the goal is inclusion in the core, and the core developers have
> > told me (as they did) that the proposal looks good and they'd like to
> > have the module, so I can reasonably expect it to go into the core if
> > it meets its technical expectations.
> 
> Not if I have a say in it. *Any* new module should see out-of-the-core
> distribution first (unless there is BDFL pronouncement to include it,
> of course).
> 
> This really is a matter of development process, not of technical
> quality.

That's bizarre and abnormal as a development process.  What kind of
development process in industry doesn't decide whether to include a
feature, until after the feature is completely implemented at a
production scale?  They figure out what the features should be, and
write them into a specification.  The specification defines what
features will be included.  Then they implement the features.  (I'm
talking specificially about straightforward, well-defined features,
not blue-sky or experimental concepts).

You see, they decide in advance what features they're going to
include, because development consumes resources and they don't want to
burn resources to develop something unless they're pretty sure they're
going to use the result once it's done.  (Of course it doesn't always
work out that way.  Everyone has worked on projects that have gotten
cancelled before delivery.  However that by definition means that
something has gone wrong.  No engineer likes it when that happens.)

You seem to have the attitude that since volunteer development effort
doesn't consume actual PSF funds, the volunteer effort is worth
nothing and can be expended arbitrarily.  The volunteers may not feel
that way.

> > If the developers instead say (as they seemed to somewhat later) that
> > because of legal/political concerns, there's no way the module can
> > possibly go into the core no matter how good it is technically, then
> > my motivation for writing the module dries up quite a bit.
> 
> I personally would not say that, although I can imagine that some people
> do say that, and I would also defend an inclusion, and push compliance
> the BXA requirements so we can legally export Python out of the U.S.A.

The BXA notification on the US side is pretty easy to handle, as you
know.  If you look at those Python-dev messages, the concern was about
importing Python-with-crypto into countries like Holland, not about
exporting it from the USA.  Those concerns are not necessarily
something to sneeze at.  Salman Rushdie had to go into hiding for
years, after publishing a book in England whose contents were illegal
in Iran.  So, I can't get too upset with the Python maintainers for
deciding to stay away from such political messes, even though I don't
feel such strong concern myself.

> In either case, the user would best use the pre-compiled binary that
> somebody else provided for the platform. 

Who's the "somebody else"?  The module author might also not have had
a compiler for that platform.  Are you suggesting that he maintain his
own distribution of multiple binaries, duplicating the machinery of
the Python distro for managing multi-platform builds?  Do you do that
with your own modules, and still say that it's easy?  If you don't,
then how does the end user know where to get the module for his
platform?

> No, I'm merely repeating myself, and rephrasing each time.
> I have to, because apparently you don't see what my requirement is.

Unless your requirement is different than what you say it is, I do see
what it is, and I'm saying it's better to do what normal projects do
and what Python has done in the past.  That is, it's perfectly ok to
decide to do something and then do it, rather than insisting,
bizarrely, that it always be the other way around.

> The original source code of the SHA-1 implementation is the NIST code
> (Gutmann, then Hollerbach), so I guess that had hundreds of users before
> the module was contributed to Python. 

Not terribly relevant, the NIST code was not a Python module.

> The module itself (including the API) was written by Greg Stein and
> Andrew Kuchling. I believe (without being able to verify) that they
> distributed this module for quite some time, before contributing it
> to Python. We would have to ask them how many users they had until
> they felt confident to contribute the code.

I think that question isn't the right one.  We need to ask how many
users the sha module was required to have, before Greg and Andrew
could have reasonable confidence that the sha module would go into the
core once it was tested enough and shown to be reliable.  I suspect
they were able to have that confidence long before testing was
complete, and maybe before implementation even started.  That is, they
were likely able to decide that the core obviously needed a sha
module, before setting off to write and test one for that purpose.

If Andrew is reading this, maybe he can comment.