Paul Rubin wrote:
An AES or DES addition to an existing module that implements just one
call:
ECB(key, data, direction)
would be a huge improvement over what we have now.
Apparently, people disagree on what precisely the API should be. E.g.
cryptkit has
obj = aes(key)
obj.encrypt(data)
I think I would prefer explicit encrypt/decrypt methods over a
direction parameter. Whether or not selection of mode is a separate
parameter, or a separate method, might be debatable - I'ld personally
prefer a separate method. However, we would have to ask users.
If you think a function like that could be added to some existing
module with less hassle than adding a new module, then I can write one
and submit it.
I would trust my intuition more for a single function than for an
entire API. In this specific proposal, I think I would trust my
intuition and reject the ECB function because of the direction
argument.
Come on, you're being deliberately obtuse, we've discussed this over
and over. There are plenty of AES modules that people can get from
somewhere. The topic is what it takes to have an AES module that
people don't NEED to get from anywhere, because they already have it
from having Python installed. Do I have to keep repeating "batteries
included" until you understand what it means?
I fully understand what you desire - to include the module "as a
battery". What makes this decision difficult is that you fail to
understand that I don't want included batteries so much that I
would accept empty or leaking batteries.
http://sourceforge.net/projects/cryptkit/
Well, that code has been around for over a year, people are using it,
etc. Are you saying you'll support its inclusion if Bryan offers to
contribute it?
*Now* you get it. Precisely that. I would ask the users what they
think about the API (shouldn't be too difficult because the module
does have users) and what they think about other aspects (performance,
stability, and so on).
I've examined that module, I wouldn't consider it
ideal for the core (besides AES, it has some complicated additional
functions that aren't useful to most people)
Ok, that would be a problem. If this is a simple removal of functions
that you'ld request (which functions?), I'ld try to collect opinions
on that specific issue, and ask Bryan whether he could accept
removal of these functions.
So if the module was primarily written to be included in the core, I
would initially reject it for that very reason. After one year or so
in its life, and a recognizable user base, inclusion can be considered.
The context was new modules in general, not specifically an AES
module. Since "considered" means "thought about", so you said
inclusion shouldn't even be thought about until the module is already
done. That's completely in conflict with the idea of inviting anyone
to work on a new module, since inviting means that there's been some
thought.
I rarely invite people to work on new modules. For new modules, I
normally propose that they develop the module, and ship it to users
for some time.
I may have made exceptions to this rule in the past, e.g. when the
proposal is to simply wrap an existing C API in a Python module
(like shadow passwords). In this case, both the interface and
the implementation are straight-forward, and I expect no surprises.
For an AES module (or most other modules), I do expect surprises.
I would say there's an implied promise of something more than a code
review. There's an implied statement that you agree that the proposed
new functionality is useful, which means the patch has a good chance
of being accepted to the stdlib if it's not too messy or cumbersome.
I have said many times that I am in favour of including an AES
implementation in the Python distribution, e.g. in
http://mail.python.org/pipermail/python-dev/2003-April/034963.html
What I cannot promise is to include *your* AES implementation,
not without getting user feedback first. The whole notion of
creating the module from scratch just to include it in the core
strikes me as odd - when there are so many AES implementations
out there already that have been proven useful to users.
So let me just ask you one final question: suppose I do all that
stuff. The question: in your personal opinion, based on the best
information you have, what is the your own subjective estimate of the
probability?
Eventually, with hard work, I estimate the chances at, say, 90%. That
is, eventually, unless the code itself shows flaws, the module *will*
be included. However, initially, when first proposed, the chances are
rather like 10%. I.e. people will initially object. Decision processes
take their time, and valid concerns must be responded to. I personally
think that there is a good response to each concern, but it will take
time to find it. Before that, it will take time to find out what
precisely the concern is.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
