Comment 1:

I don't know if we can take responsibility for helping people choose a good encryption
algorithm.  Still, leaving for agl to decided.

Owner changed to @agl.

Comment 2 by alex.gaynor:

Not sure if this is the right place to make this argument, but I'll put it here anyways
:-):
99.9% of everyone isn't educated on cryptography (here everyone means "software
engineers"). The result is that when developers go to make cryptographic decisions they
don't have the information to make good decisions. In basically any other domain of
software engineering, you can stumble around and just use any APIs you find, and when
one spits out the right answer, you roll with it.
This doesn't work in cryptography, because the thing at issue isn't the result, you
can't check the result and see if these bytes are secure, the thing at issue is the
process that produced them, and you either need to do some cryptanalysis, or you need
someone to let you know.
Developers don't know this, so they'll romp around looking for something named encrypt()
that takes a key and a plaintext and spits out what looks like nonsense bytes. Which
would be ok, except the API they'll find won't be secure, they need someone to point
them the right direction. Developers, as often as not, choose encryption algorithms
because the name sounded familiar, between that and the docs mentioning some nice USG
standards DES is in, what could be wrong with it!
Anyways, that's why I think cryptographic library authors have a responsibility to try
to inform their users about risks.

Comment 3:

Sounds nice in theory, but these things change and we can't possibly keep such
documentation up to date.
If we say anything perhaps we should add a disclaimer to all crypto packages saying
"please get expert help in choice of algorithms."

Comment 4:

The implication of "99.9% of everyone isn't educated on cryptography" shouldn't be
"throw them another bone so they can stumble along a bit longer", it should be "they
shouldn't be using cryptography primitives". 
There are bookshelves full of books on cryptography. A comment saying "don't use DES" in
API documentation isn't going to cut it. Now they'll use AES in ECB mode. Or they'll
implement a OTP with reused keys. Or they'll make one of the other possible mistakes, of
which there are probably hundreds.

Comment 5:

I think that I agree that "don't use DES" in the documentation isn't going to save
anyone who didn't already know that and isn't going to help anyone who wouldn't
otherwise screw things up.
It's on my TODO for 1.3 to add a simple seal/open API into the core libraries, although
I'm not sure what form that'll take yet.

Status changed to WontFix.