What's so funny? WAS Re: rotor replacement
"Martin v. Löwis"
martin at v.loewis.de
Sat Jan 29 05:24:54 EST 2005
Paul Rubin wrote:
> Oops, sorry, it's in the os module:
> The difference is simply a matter of the packaging.
No, it's not. It also is a matter of code size, and impact. Small
additions can be reviewed and studied more easily, and need to be
tested on less users. A new module is on a larger scale than
a mere new function.
> Unless you're saying that if I
> wanted to add AES to the string module (so you could say
> 'spam and sausage'.aes_encrypt('swordfish banana')) instead of writing a
> separate module, then we wouldn't need this discussion.
Indeed, if it was a single new function to an existing module, I would
not require that this be delivered to users first. It is entire new
libraries that I worry about.
If you would propose a change to the string module to add an aes_encrypt
function, I would immediately reject that patch, of course, because that
function does not belong to the string module.
> What matters is the code complexity, not whether
> something is in a separate module or not.
A module *is* typically more complex than a single function. If
your new module has only a single new function, we should discuss
whether it really needs to be a separate module.
> Well, if he indicates that it's not a policy and that the question is
> still open, then I could see getting interested again in writing an
> AES module. At the moment I continue to see his python-dev post as
> quite discouraging.
And, again, I consider this perfectly fine. This would be a volunteer
effort, and volunteers are free to work on whatever they please.
Furthermore, people who want an AES module for Python could get one
Maybe Bryan Mongeau will contribute this code to Python some day.
> Not true. For example, you once invited me to work on an ancillary
> message feature for the socket module (SF bug 814689), and so it's
> been on my want-to-do-one-of-these-days list since then. I think it's
> reasonable for me to have taken your message there as an expression of
> interest, sufficient to get me to want to work on it. So it's bogus
> to say the Python developers should avoid expressing interest in
> something that hasn't already been written.
I did not say that. I said we don't normally invite people to work
on anything - I said not that we *should* not invite them. Now that
you mention it, I find that there is an important exception from my
factual statement: I do regularly ask people reporting bugs
or requesting features to work fixing the bugs or implementing the
features. It is perfectly fine if they say "no" then. If they say
yes, there is an implied promise that I'll review their code when
they are done.
As it appears to be clear that you are not going to implement
an AES module in the foreseeable future, and as it also seems
to be clear that you cannot talk me into changing my views on
how Python should be developed, I think further discussing this
entire thing is pointless.
More information about the Python-list