Lambda going out of fashion
craig at postnewspapers.com.au
Thu Dec 23 14:22:12 CET 2004
Fredrik Lundh wrote:
>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.
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).
>> 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
>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, ...)
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.
More information about the Python-list