What's so funny? WAS Re: rotor replacement

["Martin v. Löwis"]

phr at localhost.localdomain wrote:
> 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?

This is not possible - whether the module is included in Python or not.
People *will* have to download something besides your application,
namely Python - and in the version your require, too. If they cannot
compile Python themselves, they will have to find somebody who did that
for them.

This is very easy if you are using Windows, Debian, or Mac OS X.
It is very difficult if you are using an Amiga, or any of the other
Python target platforms that you don't have compilers for. HP-UX
users of your application will have a hard time to get it running
even if the module was available as a built-in.

This does not change much if the module is available separately,
and it does not change much whether the separate module is written
in Python or in C: Windows, Debian, and OS X users will still
find precompiled binaries for the module, and all others will still
have to build it themselves. This is very easy, since all they have
to do is to use distutils.

> So, if your modules are generally useful, I hope you
> will try to get them into the core.

Right - the critical condition is "if the modules are generally
useful". I cannot possibly know whether they are generally useful
until a general public has commented that they are.

> 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.

That is my impression, too.

> 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.

Hmm. Most applications don't have any crypto needs. Those that do
typically need TLS, or secure password hashing (crypt(3) specifically).
So I somehow doubt that an AES module would be generally useful.

>>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 would have to apply the "generally useful" test. For an 3x speed
improvement, about 100% of the Python users would find that useful.
For an AES module with an interface nobody has ever used but yourself,
it would be very difficult to argue that the module is generally useful.

If the module does not serve a need that people have, in general,
I don't see why it should be included (and yes, I wish a few of the
modules that were included recently wouldn't have been added so
quickly).

> 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'm primarily looking for the user testing. I require that this happens
*outside* the Python distribution. Make a distutils package, and report
the user feedback. Then propose inclusion into the core.

> 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?

It very much depends on the details of the target system. Yes,
it is a bit more tricky to install the additional library - but
that is the case with any additional library, whether it is C
or not.

For the CGI user who is not allowed to install binaries into
/usr/local, she can still install the module in her home
directory, no?

> 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.

See, this is the critical point: "commonly-used functions", not
"functions I believe would be commonly used". You must have
*existing* users for a function to be commonly-used.

Regards,
Martin