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> -- http://mail.python.org/mailman/listinfo/python-list
