[gdal-dev] Proposed UTF-8 SWIG Changes
Even Rouault
even.rouault at mines-paris.org
Mon Sep 27 15:24:53 EDT 2010
Frank,
you'd likely need to also define the following typemap
%typemap(freearg) (const char *utf8_path) {
GDALPythonFreeCStr($1);
}
to avoid memory leaks with Python3.
Hum, and on Python2, GDALPythonObjectToCStr() doesn't seem to accept unicode
strings. Did you make a change in it ? or did I miss something ? I think that
the part that deals with Unicode for Python3 currently should be generalized
for Python2 too
For example, currently feat.SetField(0, u'a') throws :
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.6/dist-packages/GDAL-1.7.0-py2.6-linux-
x86_64.egg/osgeo/ogr.py", line 2179, in SetField
return _ogr.Feature_SetField(self, *args)
NotImplementedError: Wrong number of arguments for overloaded function
'Feature_SetField'.
Possible C/C++ prototypes are:
SetField(OGRFeatureShadow *,int,char const *)
SetField(OGRFeatureShadow *,char const *,char const *)
SetField(OGRFeatureShadow *,int,int)
SetField(OGRFeatureShadow *,char const *,int)
SetField(OGRFeatureShadow *,int,double)
SetField(OGRFeatureShadow *,char const *,double)
SetField(OGRFeatureShadow *,int,int,int,int,int,int,int,int)
SetField(OGRFeatureShadow *,char const *,int,int,int,int,int,int,int)
whereas the same with feat.SetField(0, 'a') works.
Also it seems that the %typemap(in) (tostring argin) typemap is essentially
the same as the new one you propose. So perhaps tostring use should be
generalized instead ?
> Even, Tamas, Ari, Howard, and other SWIG wise men,
>
> I got lost last night in the SWIG typemaps we use for GDAL, but eventually
> I came up with a minimal patch that seems to make sense and work. I would
> appreciate it if you guys could skim it and let me know if I'm doing things
> in a really wrong or dangerous way.
>
> http://trac.osgeo.org/gdal/attachment/ticket/3766/utf8_swig.patch
>
> I am attempting to treat any const char * parameter named utf8_path via
> a custom typemap that uses the preexisting GDALPythonObjectToCStr() to
> convert it. This appears to take regular strings, and unicode strings
> properly in Python.
>
> In other languages there is no special processing except that I have also
> globally applied the NONNULL typemap to such parameters.
>
> If I got ahead with this, should I add utf8_path in the README.typemaps?
>
> Best regards,
More information about the gdal-dev
mailing list