Fredrik Lundh wrote:
Good point. Unfortunately, many translation mechanisms - like Qt's, for example - don't make it easy to translate strings in resource files using the same tools as the core app. Translators have a hard enough job already with one set of tools in my experience, lumping more on them probably isn't nice. On the other hand, this isn't really Python's problem - but neither is where they come from. Even if I load docstrings from resource files, I still have a fair bit of work ahead to make Python accept them if they're not plain ASCII. In my current project, I actually gave up and changed sysdefaultencoding to utf-8 . (It's an embedded interpreter, so it's not too bad - and all modules should handle that correctly by now anyway).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.
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...).
Agreed. However, it's my understanding that one can convert:
PyObject* *Py_BuildValue*( char *format, ...)
to PyObject* *Py_BuildValue*( const char *format, ...)
(for example) without affecting module developers or users of that function elsewhere in the core code. const _arguments_ are often very safe, its const return values that tend to suck.
-- Craig Ringer -- http://mail.python.org/mailman/listinfo/python-list
