What's so funny? WAS Re: rotor replacement

[Paul Rubin]

"Martin v. Löwis" <martin at v.loewis.de> writes:
> > I don't see why you can't make up your mind enough to issue simple
> > statements like "the Python lib should have a module that does
> > so-and-so
> 
> I can say that assuming I know what so-and-so is. For the specific
> case of AES, I would say "I don't think the Python lib necessarily
> needs to have an AES module, but I would not object if it had one"

Well, ok, you're changing your tune a little bit now, and getting more
reasonable.  Before, you were making blanket statements of any modules
written for the Python stdlib.  Now you're limiting it to AES and basing
it on some AES-specific things.

> (the latter part in consideration of consequences that inclusion
>   of crypto code might have).

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.
And I think this is about totally up to Guido, since (reading between
the lines of those python-dev messages) he's concerned about the Dutch
crypto restrictions, which makes some sense because he's Dutch and
still has to deal with the Dutch government from time to time, while
you or I might not care what the Dutch government thinks.

I was about to mention that Rop Gongrijp has been operating a crypto
company in Holland (www.nah6.com) but I now see that it's moved to
Germany, and I wonder if those Dutch restrictions might be the reason.
I don't know any details though.

> > and it should meet such-and-such requirements
> 
> I can only say such things if I know such-and-such in detail
> to specify requirements. For the specific case of AES, I don't
> know enough about it to specify requirements. I will have to
> trust others (and by that, I mean *multiple* others)

OK.  If it helps, I can tell you that the Python crypto crowd hangs
out on a mailing list called python-crypto and has discussed this
module at some length.

> > so if someone submits one that meets the requirements and passes
> > code review and testing and doesn't have unexpected issues or
> > otherwise fail to meet reasonable expectations, we'll use it".
> 
> Because I cannot specify requirements, I cannot make such a promise.

Again OK.  I had thought from earlier discussions that you were a
crypto developer and familiar with this stuff; no problem if you're
not.  However, in that case, you probably wouldn't be using the module
if it got included.  I think the best policy if you don't feel
comfortable supporting including some module (whether it's crypto or
something else) that you're not personally going to use, is don't
support inclusion, but also don't obstruct it.  If there's some other
stdlib maintainers who are knowledgeable about that kind of module and
have an opinion about it, then go along with them unless there's a
clear reason not to.  Like, if I were a stdlib maintainer and somebody
submitted a fancy multigrid PDE solver, that's outside my expertise
and I'd go along with whatever Tim recommended.

> In addition, for any new module, there is one primary requirement
> for acceptance that cannot be fulfilled in code quality: the
> contributor should promise to support the module in a foreseeable
> future (i.e. a couple of years).

That's not too unreasonable, though I don't think I've heard it
mentioned as a requirement before.

> You are talking about such a thing. I don't know enough about the
> functionality to specify what an obvious interface is, or to
> recognize one if I see it.

The thing to do then is just defer the whole issue to someone on the
core team who uses that type of function.  Only if no one on the team
has an opinion do you start having to look for stuff like wide use of
the module in the outside community.

> > I don't know what OMG is, but there is no IETF requirement that any
> > implementations be available in any particular language.
> 
> See RFC 2026, section 4.1.2. Two independent implementations
> are required for the document to advance to draft (!) standard.

That says nothing about the implementation languages.  Both might be
in Python, or one might be in VHDL and the other in Ada, or whatever.

This particular module we're discussing is a straightforward
implementation of AES, DES, and FIPS 81, for which there are thousands
of implementations in both hardware and software.  For the specific
Python API, there's a Python implementation and the proposed new
module is a C implementation that does the exact same thing only
faster.  So that's two implementations, though not independent in the
IETF sense, because they'd both be written by the same person.

I've never heard of any requirement before that there be two separate
implementations of every Python stdlib module, by the way.  That would
be silly.

> > However, the result of my not writing an AES module is that Python
> > doesn't have an AES module.
> 
> That's not true. PyCrypto does have AES support.

That's not in any Python distro that I know of.  I'm talking about
modules in the stdlib, not external modules.  "Batteries included",
you know.

> That's what I'm saying: If you distribute the module to users for
> a year, and users express interest and support for your choice of
> API, I'll support inclusion of the module. "do it" involves more than
> just writing the code.

Well, that's nice of you to offer to support inclusion of a module
that you're not likely to use yourself and whose functionality you
don't really understand (I'm not being sarcastic).  If you're going to
offer such support it makes sense to impose an unusually high standard
for offering it.  I myself would probably never support including any
such module no matter how long it was distributed, but rather would
just defer the whole question to people experienced with such modules
and trust their sense of what the acceptance criteria should be for a
specific module.  That is, I'd abstain from any decision.

> It's very easy. If you are primarily do it for other people's
> benefit, and if you don't find any satisfaction in the process
> of doing it - THEN DON'T. I really mean that; this is how
> free software works. People *volunteer* to do things. If they
> don't volunteer - that's perfectly fine.

That doesn't map well onto the real world.  Say I'm a professional
cook and I have a good recipe for spam, eggs, sausage, and spam.  I
write the PyCon organizers and ask if they'd like me to cook up a big
batch to serve for breakfast for PyCon attendees (this is as a
volunteer, all ingredients provided at my own expense, etc).
Reasonable answers might be:

  1) No, we don't want to serve breakfast at PyCon, we thought about
     it but decided against it.  => OK, fine, I don't cook it.

  2) Hey, that sounds good--cook enough for 500 people and bring it to
     the site before the conference starts, and we'll put it on the
     menu unless it's below expectations.  => OK, fine, I start
     cooking.  Nobody has made an ironclad promise, but the organizers
     have told me their basic intentions, which is good enough for me.

  3) Hmm, that recipe sounds interesting, why don't you send one or
     two portions to the organizers, we'll try them and let you know.
     => OK, this is basically a prototype implementation, like the
     pure-Python version of the AES module, that's fine for testing
     but not fast enough to serve (e.g.) 500 web connections.  I
     send the small batch and wait for an answer before deciding to
     start the much bigger job of making a 500-person batch.

Your answer is more like "make enough for 500 people and bring it to
the conference site and only then will we even THINK about whether to
serve it for breakfast.  Serving it at PyCon shouldn't matter to you,
what are you, some kind of egotist?  You like cooking, so if you make
the 500 portions and then the organizers decline them, you can always
hand them out in the street.  If you don't find any satisfaction in
that, THEN DON'T DO IT."

If the cook's goal is not just to feed Python users in the street, but
to actually improve PyCon itself by providing for PyCon to serve
breakfast to attendees, I hope you can see why he might not think much
of your answer.

> As I said above - for the specific feature in question, I don't
> care enough for the feature itself. Python will be just as useful
> to me with the feature as it is without.

I'm sure that's true of lots of modules.  If you're the sole maintainer
of the Python distro, then you have to evaluate every module that anyone
submits.  But since you're part of a reasonable sized group, I think
it's best to examine the modules you care about, but don't feel that
you have to have your hands in everything.