Lambda going out of fashion

[Craig Ringer]

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
>>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