Am Dienstag, 19. Dezember 2006 13:33 schrieb Sebastian
Sauer:
> Raphael Langerhorst wrote:
> > There is also another error related to python and
kross in the way that
> > at least Py::AttributeError() and Py::TypeError()
are not understood by
> > the compiler. I don't know python, but trying to
fix it I came to the
> > impression that the parameter should name a type
as a string literal, not
> > the error message text(??):
> >
> > [100%] Building CXX object
> >
libs/kross/python/CMakeFiles/krosspython.dir/pythonextension
.o
> >
/home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pyth
onextension.c
> >pp: In
> > member function `virtual Py::Object
> > Kross::PythonExtension::getattr(const char*)':
> >
/home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pyth
onextension.c
> >pp:203: error: parse
> > error before `.' token
> >
> > This is with NetBSD 3 (GCC 3.3.3) and Python 2.3.5
as well as latest
> > qt-copy, kdelibs, etc. - on amd64
> >
> > Any ideas how this can be fixed?
> >
> >
> > Attached patch is a suggestion for KoView and a
question for the python
> > bindings. It is not meant to be committed the way
it is (python bindings
> > need to be properly fixed first).
>
> Regarding;
>
> if(! property.isReadable()) {
> - Py::AttributeError(
QString("Attribute "%1" is not
> readable.").arg(n).toLatin1().constData() );
> + QString tstr("Attribute
"");
> + tstr.append(n);
> + tstr.append(" is not
readable.");
> + QByteArray ba = tstr.toLatin1();
> + char* string_data = ba.data();
> + Py::AttributeError( string_data /*
"Attribute is not
> readable." /* QString("Attribute
"%1" is not
>
readable.").arg(QString::number(n)).toLatin1().constDat
a() */ );
> return Py::None();
> }
>
> That looks interessting. So, it is not possible to do
something like
> QString().arg(n) where n is a char* ?
I think you can. Qt would make a QString of the given char
and use this as
parameter to arg() (AFAICS) - char* is an acceptable
parameter to the QString
constructor so its internally constructing one and passes
that to arg().
The above verbosity was meant to track down the actual call
that doesn't work
(in gcc error+line output), but in fact everything up there
worked fine
except that "string_data" was an unknown type
(whatever). So my assumption is
that the argument to Py::AttributeError is not a normal
argument.
If I use above code, I get the following output:
/home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pyth
onextension.cpp:208:
error: conflicting
types for `Py::AttributeError string_data'
/home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pyth
onextension.cpp:207:
error: previous
declaration as `char*string_data'
line 207 is: char* string_data = ba.data();
line 208 is: Py::AttributeError( string_data );
so.... hmm... thinking about it I'm concluding that the
parameter to
Py::AttributeError is meant to be the variable name of the
created
AttributeError python object. Is this possible?
In which case it is nonsense to put the error description
there, right? What
role has the variable name of such a python object?
Ultimately: what should
be the parameter to Py::AttributeError and similar things ?
Does no one else have this compile error?
Regards,
Raphael
_______________________________________________
koffice-devel mailing list
koffice-devel kde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel
|