Re: [PyKDE] static const member variables
The problem we're having is that without a concept of constness in Python, we have the risk of python-code changing A::zero, A::one or QString::null. Proper support for const has been on the TODO list for a long time - just haven't got around to it yet. Thanks Phil, just checking if there was anything new that we ought to know about... Thanks, Nigel Stewrat ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] C++ wrapper at granularity of Python/C API?
Hi all,
In the context of our C++/Python/Sip/Qt codebase, we've
had some need for Python-aware C++ classes that utilise
the Python/C API, along with the incref and decref pain
that comes along with that.
I've been toying with the use of boost::intrusive_ptr
and/or boost::python::api::object as C++ wrappers for
PyObject * and some of the potential advantages:
- Default constructor to 0 (no uninitialised PyObject *)
- Destructor to decref and set to 0 (no stale PyObject *)
- Safe copying with implicit incref (automatic incref/decref)
However, when it comes to mixing these smart pointer
style wrappers with the Python/C API, there remains
the problem of handling the different scenarios:
- New reference (ref count 1)
- Borrowed reference (ref count 0, incref for long-term use)
So, what would be very nice, would be a whole set of
wrappers for the Python/C API that deal with the reference
counting in a boost::intrusive_ptr or boost::python::api::object
friendly way to make it idiot-proof.
boost::python encourages use of the Python/C API to the
extent of providing access to the PyObject via
boost::python::api::object::ptr(), but doesn't seem to
provide the entire Python/C API
So, one may need to write
PyCallable_Check(o.ptr());
Rather than simply:
o.Callable_Check();
The real value would be in the case of say:
{
...
o = python::List_New(10); // PyList_New produces new reference
a = o.List_GetItem(4); // PyList_GetItem returns borrowed reference
...
// We're all done without a Py_INCREF or PyDECREF, whew!
}
Am I missing something obvious in boost::python?
Kind regards,
Nigel Stewart
___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QStringList QStringList::operator+=(const QString ) missing from PyQt?
I noticed that operator+=(const QString ) doesn't work from Python, even though it is documented as part of the Qt 3.3 API It will be in tonight's PyQt snapshots. Thanks Phil! Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Sip 4.4, PyQt 3.16 - sipSetBool not implemented?
Is it my imagination, or is there no implementation of sipSetBool is Sip 4.4 or sip-snapshot-20060325? Oops, my mistake, it had moved to bool.cpp and our recycled Makefiles hadn't accounted for that. Apologies. Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QStringList QStringList::operator+=(const QString ) missing from PyQt?
I noticed that operator+=(const QString ) doesn't work from Python, even though it is documented as part of the Qt 3.3 API Any chance of this being resolved in Sip 4.4.1 and PyQt 3.16.1? Thanks, Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] How To Publish a pyqt application
The disadvantage is that your tar.gz will be really big. ..and won't work, if arch don't match or gcc/glibc versions differ to much.. Works for us, providing we choose a sufficiently old build host. :-) Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Bug in Sip 4.4 and snapshot-2006-03-25 sipgen/gencode.c
Lines 8231-8235 prcode(fp,,sipMappedType_%T,%s);\n , ad, (isTransferredBack(ad) ? Py_None : NULL)); prcode(fp,);\n ); It appears that the closing ); is written twice in the case that an output parameter is a mapped type. The suggested patch is to remove the last two lines quoted here. If necessary I can provide further details, but the fix seems reasonably clear from local inspection. Regards, Nigel Stewart ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Sip 4.4, PyQt 3.16 - sipSetBool not implemented?
Hi all, Is it my imagination, or is there no implementation of sipSetBool is Sip 4.4 or sip-snapshot-20060325? Is this Sip's way of punishing us for statically linking our sip-generated bindings into the program? :-) Nigel - There are no unresolved sip symbols for sip 4.3.2: [EMAIL PROTECTED] ~/Wares/libs/sip-4.3.2/siplib $ ldd -r sip.so linux-gate.so.1 = (0xe000) ... For 4.4 sipSetBool is unresolved: [EMAIL PROTECTED] ~/Wares/libs/sip-4.4/siplib $ ldd -r sip.so linux-gate.so.1 = (0xe000) ... undefined symbol: sipSetBool(./sip.so) - [EMAIL PROTECTED] ~/Wares/libs/sip-4.3.2/siplib $ grep sipSetBool *.h *.c sipint.h:void sipSetBool(void *ptr,int val); siplib.c: sipSetBool(va_arg(va,void *),(int)v); siplib.c: sipSetBool(va_arg(va,void *),(int)v); [EMAIL PROTECTED] ~/Wares/libs/sip-snapshot-20060325/siplib $ grep sipSetBool *.h *.c sipint.h:void sipSetBool(void *ptr,int val); siplib.c: sipSetBool(va_arg(va,void *),v); siplib.c: sipSetBool(va_arg(va,void *),v); siplib.c: sipSetBool(va_arg(va,void *),(arg == Py_True)); ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] QStringList QStringList::operator+=(const QString ) missing from PyQt?
Hello all, I noticed that operator+=(const QString ) doesn't work from Python, even though it is documented as part of the Qt 3.3 API: http://doc.trolltech.com/3.3/qvaluelist.html#operator+-eq Works: l = QStringList() l.append(Hello) l.append(World) Doesn't work: l = QStringList() l += QString(Hello) l += QString(World) Perhaps it needs to be added to qstringlist.sip PyQt-x11-gpl-snapshot-20060323/sip/qt $ grep operator qstringlist.sip QString operator[](int); QStringList operator[](SIP_PYSLICE); QStringList operator+(const QStringList ); QStringList operator+=(const QStringList ); QStringList operator*(int); QStringList operator*=(int); bool operator==(const QStringList ); bool operator!=(const QStringList ); Since I switch a lot between C++ and Python perhaps I'm more likely than most to discover this kind of issue. :-) We're using Sip 4.3.2 and PyQt 3.15.1 Regards, Nigel Stewart ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] __unicode__ unsupported by sip?
Hello all,
In our mixed C++/python environment we want to interchange strings
between C++ and python as either QString or python unicode strings.
We have some sip bindings providing __str__ conversion to python
strings, but when we converted these to __unicode__ methods producing
python unicode strings, things mysteriously stopped working.
It appears that sip doesn't generate any C++ code for __unicode__
methods, wheras it does for __str__ methods. Grepping sipgen
for the 20060315 sip snapshot seems to confirm this. (see attachment)
Is it reasonable for the MethodCode of a __str__ method to produce
a unicode string, or is it sipgen that needs attention?
There is one __unicode__ method in PyQt, for QString.
PyQt also provides QString::__str__, also returning a
unicode string.
So, why does sip accept __unicode__ if it is ignored?
Regards,
Nigel Stewart
---
[EMAIL PROTECTED] ~/Wares/sip-snapshot-20060315/sipgen $ grep __str__ *.c *.h
parser.c: {__str__, str_slot, TRUE, 0},
[EMAIL PROTECTED] ~/Wares/sip-snapshot-20060315/sipgen $ grep str_slot *.c *.h
gencode.c: return (st == str_slot || st == int_slot || st == long_slot ||
gencode.c: case str_slot:
gencode.c: sn = str_slot;
parser.c: {__str__, str_slot, TRUE, 0},
sip.h: str_slot,
[EMAIL PROTECTED] ~/Wares/sip-snapshot-20060315/sipgen $ grep __unicode__ *.c
*.h
parser.c: {__unicode__, unicode_slot, TRUE, 0},
[EMAIL PROTECTED] ~/Wares/sip-snapshot-20060315/sipgen $ grep unicode_slot *.c
*.h
gencode.c: else if (md - slot != no_slot md - slot !=
unicode_slot)
parser.c: {__unicode__, unicode_slot, TRUE, 0},
sip.h: unicode_slot,
___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] How to contribute to sip ?
I would like sip to have an option to generate a C++ file only if it does not exists or if it is different from the existing one. This would greatly improve compilation time ... That would be very good indeed. Does it need to be optional? We would see some immediate benefits to our build time... Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] How to contribute to sip ?
I wouldn't accept this change as it doesn't really have anything to do with what SIP does (although I readily admit that some of SIP's existing functionality also falls into that category). Phil, It could be argued that SIP is part of a broader toolchain (in our case, gmake and qmake) that would benefit from SIP taking some care not to touch unchanged files. uic and moc avoid touching files unnecessarily, and so could SIP. Currently, our sip-based python bindings are the bottleneck in our incremental builds. We bypass this as much as possible, (cheating the dependencies) but we shouldn't need to be doing that kind of workaround... Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] How to contribute to sip ?
It could be argued that SIP is part of a broader toolchain What does this have to do with SIP again? I don't remember GCC not generating the object files if the source code is not changed. A compiler takes one input file and creates one output file. The granularity of SIP is different, it's taking multiple inputs (via %Import) and creating multiple outputs. This design poses a choke point. I think being time-stamp friendly is a way for SIP to compensate for this. So, why can't you configure your build system so that it doesn't call SIP in the first place if the header file has not changed? Here is the scenario - the header foo.h is changed, triggering SIP to regenerate the bindings. In most cases, the change to foo.h doesn't affect the code that SIP outputs. Of the 250 .cpp files generated by SIP, 10 depend on foo.h. However, all 250 are rebuilt due to SIP changing the time stamp. That's a 25x slowdown that provides me more time to surf the PyKDE mailing list... :-) Perhaps our situation is not typical, it doesn't affect our developers that _depend_ on our SIP bindings. But it certainly affects development _upstream_ of the SIP bindings. Imagine someone hacking away at Qt and depending on PyQt based regression tests to know if they've broken anything... That's my day-to-day situation in a nutshell... Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] How to contribute to sip ?
uic and moc avoid touching files unnecessarily, and so could SIP. I wasn't aware of uic and mock behaving like that. True, it's qmake that is uic and moc dependency aware... A wrapper that generated the .sip files into a temporary directory, compared them against previously generated files and replaced them if they were different isn't very difficult to write. I'll have a fiddle in our gmake Makefile to try this suggestion... I wonder if diff can handle it... Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] How to contribute to sip ?
A wrapper that generated the .sip files into a temporary directory, compared them against previously generated files and replaced them if they were different isn't very difficult to write. Phil, Experimenting here with diff and patch... diff -ruN out tmp | patch -d out However, there is one issue, perhaps SIP could provide an option _not_ to put timestamps in the wrapper code comments... :-) /* * Interface wrapper code. * * Generated by SIP 4.3.2 (4.3.2-SIP-4_3-365) on Tue Feb 28 11:23:21 2006 */ Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Special-case handling for default argument of NULL vs 0?
Hi all, We're observing some issues with methods such as: (a)void foo(const QString * = NULL); (b)void bar(const QString * = 0); We're using Sip 4.3.2, it appears that Sip doesn't support (a), PyQt 3.15.1 doesn't use (a) and the yacc parser that sip uses is confusing NULL for a C++ identifier that the address can be taken of: static PyObject *meth_MyClass_foo(PyObject *sipSelf,PyObject *sipArgs) ... const QString * a0 = NULL; // Can't compile this! static PyObject *meth_MyClass_bar(PyObject *sipSelf,PyObject *sipArgs) ... const QString * a0 = NULL; So, the lesson seems to be that = 0 is good, = NULL is to be avoided, when it comes to sip bindings. But, it would be nice if sip could recogise NULL as a special case, since that is what we encourage in our C++ API, rather than 0. Any thoughts? Cheers, Nigel Stewart ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Special-case handling for default argument of NULL vs 0?
We're observing some issues with methods such as: (a)void foo(const QString * = NULL); (b)void bar(const QString * = 0); So, the lesson seems to be that = 0 is good, = NULL is to be avoided, when it comes to sip bindings. And when it comes to C++ according to Stroustrup. No problem with adding this. Thanks Phil, one less little gotcha to worry about in future... :-) Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
You don't care, I care. Don't do the mistake of thinking that your needs are the same of everyone else. So, why _do_ you care? What's the issue or problem you have in mind? We also care - we're storing the majority of our data in C++ containers of QString. Deep copying from QString - Python - Qt Widget will affect our footprint and latency, without doubt. If we had a quantitative idea of the performance impact, it would be a lot easier to argue one way, or the other. I find it appealing to eliminate QString, but not based on some kind of nobody cares about performance rationale. Nigel Stewart ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Sip support for FILE */PyFileObject
There seems to be an assumption that %ConvertToTypeCode creates
a copy that needs to be deleted and ownership can't be transferred
to C++.
It's not an assumption - it's the return value of %ConvertToTypeCode. Just
make sure it always returns 0.
Yes, that is the solution to the problem.
Many thanks!
Nigel
From the Sip documentation...
If sipIsErr is not NULL then a non-zero value is returned if the mapped
type instance returned through sipCppPtr was created on the heap.
Otherwise zero is returned.
struct FILE
{
%TypeHeaderCode
#include cstdio
using namespace std;
%End
private:
FILE();
FILE(const FILE );
~FILE();
%ConvertToTypeCode
if (sipIsErr == NULL)
return PyFile_Check(sipPy);
if (PyFile_Check(sipPy))
{
*sipCppPtr = PyFile_AsFile(sipPy);
return 0; /* The item was not allocated on the heap */
}
*sipIsErr = 1;
return 0;
%End
};
___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Coerce QString to unicode or str?
That raises two questions - (1) would it be desirable for Python to quietly convert QStrings to unicode as needed, and (2) is it technically possible in Python 2.4, 3.x? It's a SIP limitation that will be fixed in the next version (in fact a partial implementation will be in tonight's snapshot). Phil, Let us know when you think it's ready - it's about time we migrated to the latest Sip/PyQt here. Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Sip support for FILE */PyFileObject
Hello all,
We'd like to be able to mix C++ and Python for reading
and writing of heavy-weight streams of data. Although
QFile can be used across both C++ and Python using PyQt,
it is somewhat more appealing to use native python files
in Python and native FILE * in C/C++.
We've come up with a working solution to convert
a PyFileObject to a FILE * using sip:
MyWriter(SIP_PYOBJECT);
%MethodCode
if (PyFile_Check(a0))
sipCpp = new MyWriter(PyFile_AsFile(a0));
else
{
sipCpp = NULL;
sipIsErr = 1;
PyErr_SetNone(PyExc_TypeError);
}
%End
We can think of two other variations that would
require changes to sip, but would reduce the need
for method code...
(a)
MyWriter(SIP_PYFILE);
%MethodCode
sipCpp = new MyWriter(PyFile_AsFile(a0));
%End
(b)
MyWriter(FILE *);
Another thing we've tried is creating a binding
for struct FILE, but the sip-generated code
is inclined to delete it once passed to
MyWriter...
struct FILE
{
%TypeHeaderCode
#include cstdio
using namespace std;
%End
private:
FILE();
FILE(const FILE );
~FILE();
%ConvertToTypeCode
if (sipIsErr == NULL)
return PyFile_Check(sipPy);
if (PyFile_Check(sipPy))
{
*sipCppPtr = PyFile_AsFile(sipPy);
return 1;
}
*sipIsErr = 1;
return 0;
%End
};
Any hints or suggestions appreciated.
Regards,
Nigel Stewart
___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] QString - python string via QString::latin1()
Hello all, I came across something unexpected recently, that was causing us occasional python exceptions: print type(qt.QString(foo).latin1()) type 'str' print type(qt.QString().latin1()) type 'str' print type(qt.QString.null.latin1()) type 'NoneType' print type(qt.QString().latin1()) type 'NoneType' The type of result returned by the PyQt binding for QString::latin1() depends on whether the string is empty or null. Contrast this with the PyQt binding for the str() converter: print type(str(qt.QString(foo))) type 'str' print type(str(qt.QString())) type 'str' print type(str(qt.QString.null)) type 'str' print type(str(qt.QString())) type 'str' In this case, conversion to a python string always succeeds, and never results in a NoneType. PyQt is checking for the QString::null in this case, but for latin1() is defaulting to the behaviour of PyString_FromString: PyObject *PyString_FromString(const char *v) Return value: New reference. Returns a new string object with the value v on success, and NULL on failure. The parameter v must not be NULL; it will not be checked. Overall, a bug, or a feature? I would certainly prefer that PyQt always returned a python string, treating QString::isNull() and QString::isEmpty() as the same case. I'm interested in the broader PyKde/PyQt opinion, is it pythonic to return different types of objects, depending on the input? I'm using Python 2.4, Sip 4.1.1 and PyQt 3.13. Regards, Nigel Stewart ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString - python string via QString::latin1()
Hi Phil, I certainly see what you mean, the counter-argument here is motivated from a pragmatic point of view - I don't want to be writing Python code to check the return type of every call to QString::latin1(). Overall, a bug, or a feature? Feature. I would certainly prefer that PyQt always returned a python string, treating QString::isNull() and QString::isEmpty() as the same case. Null and empty QStrings are different and the PyQt behaviour reflects the Qt behaviour. True, that's the QString convention. I am not aware of such a convention existing in Python for python strings. It could be argued that the PyQt behaviour is escalating a fine-grained QString semantic into a Python error-state: PyObject *PyString_FromString(const char *v) Return value: New reference. Returns a new string object with the value v on success, and NULL on failure. The parameter v must not be NULL; it will not be checked. So a QString.latin1() returning NULL (which is not documented as an error condition) is treated by PyQt as an error condition, rather than converting into a zero-length Python string. I'm interested in the broader PyKde/PyQt opinion, is it pythonic to return different types of objects, depending on the input? str() is defined to return a string object. If there is a bug then it's that str() of a null string should raise an exception. I'd be willing to implement that for PyQt4 I think it would be preferable for the QString::isNull / QString::isEmpty semantic to be ignored - if the python side is interested in isNull/isEmpty it should be asking the QString. It seems to me quite a burden to need to check the return type of every call to QString::latin1() via PyQt. Raising an exception would be even more cumbersome, from the point of view of delivering robust python code. As it turns out, we can migrate to using str() or unicode() rather than latin1() - so I'm flagging this as an issue we came across, not something that affects our project adversly. Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Importing sip-generated module into multiple interpreters
If you use the Python API to import the module then the init function will only be called once, no matter how many times it is imported. You were calling the init function explicitly. We prefer to link our module statically, rather than as a .pyd, that's why we rely on the explicit init. We would prefer to leave things this way, but we'll do some experiments to avoid the explicit initialisation. Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Importing sip-generated module into multiple interpreters
Hi, I'm trying to encapsulate a script into a seperate Python interpreter. The idea is that these scripts are safely isolated from the rest of the system, except for our sip-generated module API. 1Py_BEGIN_ALLOW_THREADS 2PyThreadState *pi = Py_NewInterpreter(); 3initsip(); 4initmodule(); 5PyRun_SimpleString(...); 6Py_EndInterpreter(pi); 7Py_END_ALLOW_THREADS I get the following error in response to line 4, perhaps sip isn't designed to deal with multiple interpreters? RuntimeError: the sip module has already registered a module called icecore Any info would be appreciated, especially if there is another way to achieve a sandbox sharing the same interpreter. Regards, Nigel Stewart ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Sip bindings for HDF5?
We're interesting in using the HDF5 (Hierarchical Data Format 5) libraries with our C++/Python/PyQt based applications. There are some hand-coded Python bindings, by the Swedish Meteorological and Hydrological Institute but these havn't been maintained since around 2002: ftp://ftp.ncsa.uiuc.edu/HDF/HDF5/contrib/hl-hdf5/README.html Has anyone come across sip-based bindings for HDF5 (commercial or open source)? Thanks, Nigel Stewart ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Sip bindings for HDF5?
Are you aware of http://pytables.sourceforge.net ? It is not exactly what you are asking for: it may be to high level (you can do all in Python using numarray). PyTables looks interesting, but it this stage we mostly want to interchange heavyweight data between C, C++ and Python applications. Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Sip wishlist item: Parameter typechecking enhancement
I'm not clear what it is you are really doing, but you can specify something similar... Bar(SIP_PYOBJECT) [(Foo )]; ...but you still might have to provide %MethodCode. Phil, I delved back into the Sip documentation: method ::= type name ( [argument-list] ) [const] [exceptions] [= 0] [function-annotations] [c++-signature] ; [%MethodCode] c++-signature ::= [ type ( [argument-list] )] I can't find any explanation of the c++-signature in the documentation, but I'll dig around and see if it helps. In a nutshell, I want a wrapped constructor to pass a wrapped Foo as a PyObject parameter, but I'd prefer sip to do the typecheck that PyObject is a Foo, rather than trying to deal with it on the C++ side. Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Sip wishlist item: Parameter typechecking enhancement
In a nutshell, I want a wrapped constructor to pass a wrapped Foo as a PyObject parameter, but I'd prefer sip to do the typecheck that PyObject is a Foo, rather than trying to deal with it on the C++ side. How about the GetWrapper annotation? Nearly! Annotating the parameter with GetWrapper makes the PyObject available as a0Wrapper, and doing the type check... ...but a0 is being passed as the argument, rather than a0Wrapper. Is there a way to avoid maintaining method code to pass q0Wrapper rather than a0? Bar(Foo /GetWrapper/); Bar(Foo /PassWrapper/); ?? Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Sip wishlist item: Parameter typechecking enhancement
Just for the record, here is the solution that is working for us with sip 4.1.1. It is far better than needing to worry in C++ about the PyObject parameter not being a Foo wrapper... Nigel ... Bar(Foo /GetWrapper/, const QString , const QString = QString::null); %MethodCode sipCpp = new Bar(a0Wrapper,*a1,*a2); %End ... ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Sip wishlist item: Parameter typechecking enhancement
Bar(Foo /GetWrapper/); Bar(Foo /PassWrapper/); ?? No. I think this is too specialised a requirement to justify automating it. Just to explain our motivation for having this... We have a container that can intermix C++ and python wrapped Foo in a way that observes python reference counting for python-side items, deletion for dynamically allocated C++ items, and no deletion of items managed elsewhere. This results in nice consistant behaviour across C++ and Python code, but means some Python C API creeping into our own framework. The GetWrapper annotation certainly helps minimise what our MethodCode needs to deal with, perhaps we're being a bit too far on the bleeding edge making our framework so python-friendly... With thanks, Nigel Stewart ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Sip wishlist item: Parameter typechecking enhancement
Ideally, we would be able to do some kind of annotation
that the parameter is Foo, but should be passed to the
PyObject version of the constructor:
class Bar
{
public:
Bar(Foo /PyObject/);
...
}
Hello all,
In our integration of Python with C++ we're sometimes
doing python reference counting integrated into our
native C++ data structures. Is what we're doing
relatively unusual, compared to the majority of
PyQt/sip based applications?
Nigel STewart
___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] Sip wishlist item: Parameter typechecking enhancement
Hello all,
We have a C++ constructor that takes either a Foo pointer
or PyObject pointer as an argument. The PyObject needs
to be python-wrapped Foo, a runtime check is applied and
an assertion raised if the python object can't be cast
to a Foo.
The reason for this arrangement is that we want to do
some reference counting for python managed instances
of Foo.
Ideally, we would be able to do some kind of annotation
that the parameter is Foo, but should be passed to the
PyObject version of the constructor:
class Bar
{
public:
Bar(Foo /PyObject/);
...
}
Currently we are accepting a SIP_PYOBJECT, but properly
handling the typechecking is going to require custom
%MethodCode.
class Bar
{
public:
Bar(SIP_PYOBJECT);
...
}
There is possibly an elegant exception handling solution to
this too, does anyone else see a benefit in sip providing
typechecking of generic python parameters in this annotated
kind of manner. (Rather than bugging Phil directly!)
Nigel
___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
