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
--
http://mail.python.org/mailman/listinfo/python-list
