[Note: this is a 2nd attempt at posting reply to Martin's message,
since the first one didn't reach the server. It's a rewrite from memory
but says about the same thing as the other attempt. --Paul]
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Paul Rubin wrote:
> > If he understood how Python is actually used, he'd understand that any
> > C module is a lot more useful in the core than out of it.
>
> This is non-sense. I have been distributing C modules outside the
> core for quite some time now, and I found that the modules are quite
> useful. distutils makes it really easy for anybody to use them.
Maybe we're not thinking about the same problems. Say I'm an app
writer and I want to use one of your modules. My development
environment is GNU/Linux, and I want to ship a self-contained app that
anyone can run without having to download additional components. That
includes people wanting to run my app on Windows, Macintosh, Amiga,
and various other Python target platforms that I don't have compilers
for. How do I do it?
I'm sure your modules are excellent but as an app writer, I feel I
must try to avoid needing them, in favor of modules that are already
in the core, even if it means more work for me or worse functionality
in my app, just for the sake of reducing installation headaches for my
target audience. So, if your modules are generally useful, I hope you
will try to get them into the core.
> > There are already tons of 3rd party crypto modules outside the
> > core, and the module I was writing wouldn't add anything useful to those.
>
> Why do you think these are not part of the core? It's not because
> they contain crypto code, or because they had been rejected. They
> are primarily not included in Python because they have not been
> contributed to Python, yet.
I can't speak for the authors but I'd personally say that none of
those old modules are really suitable for the core on technical
grounds. They're too fancy and specialized, or they depend on
external libraries like OpenSSL, or they're written mostly to support
some specific application and don't present a simple, general-purpose
interface like a core module should have. Maybe the authors felt the
same way and chose not to submit them. Or maybe the authors had other
reasons, such as licensing priorities that conflict with the Python
license.
The module I'm discussing would simply implement the FIPS standard
block ciphers (AES and DES) and the FIPS operating modes. These are
the basic building blocks that I feel are missing from the core. They
should be enough to fill the crypto needs of most applications.
> If they were contributed, a number of things still would need to
> be considered, e.g. what is the size of the code, including libraries,
> is the contributor really the author, is the code likely going
> to be maintained, and so on. However, it never got that far.
The module we're talking about wouldn't have had any of those problems.
> I know that *I* am very opposed to any contribution of a larger
> module that has not seen any real users, yet.
We're not talking about a "larger module", we're talking about a
module that implements the basic AES and DES block ciphers (similar to
how the sha module implements the basic SHA-1 hash algorithm) and
wraps them with some well-defined FIPS operating modes (similar to how
the hmac module wraps the sha module to compute RFC 2104 hmac
authentication codes). This stuff isn't rocket science. It's just
straightforward implementation of modes and algorithms that go back to
the 1970's, are the subject of national and international standards,
and are already in use in thousands of non-Python applications all
over the world.
Also, I've already released a pure-Python implementation of the
interface, suitable for application testing but too slow for real use.
I tried rather hard to design a convenient and general interface that
I feel was an improvement over PEP 272. I don't know if anyone except
me is using it, but several people including Andrew (author of PEP
272) have written favorably about it based on reading the
specification. The spec was designed from the beginning to fill the
needs of the core. If I were writing it as a non-core module I would
have included more stuff.
> 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.
That makes no sense; improving the core is a perfectly valid reason to
write something. If someone wrote a straightforward patch that made
the Python interpreter 3x faster, would you still want to wait a year
before thinking about including it? I certainly believe that every
contribution needs code review and user testing before entering wide
release, but that doesn't seem to be what you're getting at.
> I fail to see the problem you seem to have with C modules. They are
> very easy to use if written properly.
Well again, maybe we're not talking about the same thing, or perhaps I
just need more explanation of what you mean. Suppose I want to write
an "application" that tells people the SHA-1 checksum of their name.
I write 3 lines of Python using the built-in sha module:
import sha
name = raw_input('Enter your name: ')
print 'Your hash is', sha.new(name).hexdigest()
I release this "app" and presto, every Python user on every OS
platform can run it with no fuss. That includes CGI authors who
aren't allowed to install C modules at all, without getting their
hosting service to do it. How do I do the same thing if there's no
built-in sha module and all I have is sha.c?
To me, the whole Python notion of "batteries included" expresses
precisely the idea that I'm trying to describe. Commonly-used
functions belong in the core, because making people download or
install them separately is a pain in the neck.
--
http://mail.python.org/mailman/listinfo/python-list
