What's so funny? WAS Re: rotor replacement

["Martin v. Löwis"]

Paul Rubin wrote:
>>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.

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.

The question whether I would like to see a certain *feature*
in Python (whether as a separate module, a language feature, or
otherwise) is an entirely different question. That I would not
object to an AES code in general doesn't imply that I will
agree to any AES module that somebody contributes.

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

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

Thanks for the advise, but I'll have my own policies. I have included
several modules in the past which I'm not personally using.

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

See PEP 2.

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

And I did not suggest such a thing. You said you never heard about
a process which requires an implementation before deciding that the
proposed feature is good, and I said that, for an example, IETF even
requires *two* implementations before deciding that the feature is
good.

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

Sure, but "Python" is more than the Python core.

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

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. I'll try to look at *all* patches, whenever
I can, and in the process, I have to learn about technologies which
I've never used before (primarily operating systems, but also
APIs and protocols).

Rejecting all these patches would be unfair to the contributors.

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

I cannot see these as the same thing.

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

Thanks again for the advise, but this is not how Python is being
maintained.

Regards,
Martin