Lambda going out of fashion

[Fredrik Lundh]

Craig Ringer wrote:

>  It's hard to consistently support Unicode in extension modules without
> doing a lot of jumping through hoops. Unicode in docstrings is
> particularly painful. This may not be a big deal for normal extension
> modules, but when embedding Python it's a source of considerable
> frustration. It's also not easy to make docstrings translatable.
> Supporting an optional encoding argument for docstrings in the
> PyMethodDef struct would help a lot, especially for docstrings returned
> by translation mechanisms.

docstrings should be moved out of the C modules, and into resource
files.  (possibly via macros and an extractor).  when I ship programs
to users, I should be able to decide whether or not to include docstrings
without having to recompile the darn thing.

and yes, docstrings should support any encoding supported by python's
unicode system.

>  Const. I know there's a whole giant can of worms here, but even so -
> some parts of the Python/C API take arguments that will almost always be
> string literals, such as format values for Py_BuildValue and
> PyArg_ParseTuple or the string arguments to Py*_(Get|Set)String calls.
> Many of these are not declared const, though they're not passed on to
> anywhere else. This means that especially in c++, one ends up doing a
> lot of swearing and including a lot of ugly and unnecessary string
> copies or const_cast<char*>()s to silence the compiler's whining. It
> would be nice if functions in the Python/C API would declare arguments
> (not return values) const if they do not pass them on and do not change
> them.

I think the only reason that this hasn't already been done is to reduce the
amount of swearing during the conversion process (both for the core developer
and C extension developers...).

</F>