[EMAIL PROTECTED] wrote:
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"
(the latter part in consideration of consequences that inclusion
of crypto code might have).
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)
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.
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).
Again, we're talking about straightforward modules whose basic
interface needs are obvious.
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.
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.
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.
No, it's three steps
1. decide that you want to do it
2. do it
3. decide whether you are pleased with the result, and only
use it if you are
IOW, there should not be a blanket guarantee to use it after step 1.
But, it's completely normal to say before step 1 that "if the result
of step 2 does so-and-so, then I'll be pleased in step 3",
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.
You and
Frederik seem to think there's something inappropriate or
self-inflated about wanting that expectation before committing to do a
pile of work that's primarily for other people's benefit.
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.
I think
your stated attitude is completely bizarre, that you can't really
believe anything so silly, so you're really just acting bureaucratic,
looking for excuses to say no instead of yes to worthwhile proposals.
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.
What I do care about is the effort that I will need to continue
maintaining Python. I don't want to have to maintain an ill-designed,
buggy module with no active maintainer, and I don't want to tell
people that I had to rip the module out just because it doesn't
work at all.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
