Hi All,
I am hoping someone can jump in here and help (Detlev?). Please ???
I thought I would have a go at implementing the kind on functionality that I
was after but don't seem to be able to
get it to work correctly. I thought that I would try the straight forward
logical approach which is
I am considering translating a few functions of our large PyQt application to
C (or, probably, pyrex) as a performance optimisation, but I have stumbled at
the first hurdle. How do you convert a PyObject pointer to a PyQt object into
a pointer to the Qt C++ object?
Thanks in advance,
--
Toby
Toby Dickenson [EMAIL PROTECTED] wrote:
I am considering translating a few functions of our large PyQt
application to C (or, probably, pyrex) as a performance optimisation,
but I have stumbled at the first hurdle. How do you convert a
PyObject pointer to a PyQt object into a pointer to the Qt
When I understand your question right, this example will be the answer.
PyObject*myPyType;
// convert a PyObject pointer to MyPythonType-Pointer object
// cppType will be the known CPP-Type which is the base of MyPythonType
myPyType = sipBuildResult(NULL,M,cppType,sipClass_MyPythonType)
Hi Baz,
Thanks for your suggestion it was very helpful. I tried Ctrl-clicking the
class fold marker and as you suggest it colapses all of the child folds. I
also tried the Ctrl and Shift but this is the same as the toggle all folds
menu option (class gets folded but the children don't).
On Tuesday 18 October 2005 01:44, elho wrote:
When I understand your question right, this example will be the answer.
PyObject*myPyType;
// convert a PyObject pointer to MyPythonType-Pointer object
// cppType will be the known CPP-Type which is the base of MyPythonType
myPyType =
On Tuesday 18 October 2005 5:39 pm, Jim Bublitz wrote:
On Tuesday 18 October 2005 00:44, Toby Dickenson wrote:
I am considering translating a few functions of our large PyQt
application to C (or, probably, pyrex) as a performance optimisation, but
I have stumbled at the first hurdle. How do
I'm wondering whether QString should be dropped in PyQt4 in order to make it
more Pythonic.
At the moment Python strings and unicode strings are automatically converted
to QStrings when passed as arguments - so there would be no change there. If
a QString was returned by a method or an
On Tuesday 18 October 2005 20:24, Phil Thompson wrote:
I'm wondering whether QString should be dropped in PyQt4 in order to make
it more Pythonic.
At the moment Python strings and unicode strings are automatically
converted to QStrings when passed as arguments - so there would be no
change
On Tuesday 18 October 2005 6:41 pm, Patrick K. O'Brien wrote:
Phil Thompson wrote:
I'm wondering whether QString should be dropped in PyQt4 in order to make
it more Pythonic.
Sounds good to me. Any word on when we might expect a functioning
PyQt4? I don't know about anyone else, but I'm
On Tuesday 18 October 2005 20:45, you wrote:
İsmail Dönmez wrote:
I very much like QString's api like endsWith instead of endswith. Its
small but in the end all those small things matter :)
Not to pick a fight or anything, but how is this an advantage? Is it
the case that you don't do
Le Mardi 18 Octobre 2005 19:24, Phil Thompson a écrit :
I'm wondering whether QString should be dropped in PyQt4 in order to make
it more Pythonic.
Would it mean that QString content would always be copied when used in
Python ? If yes, copying a QString from a widget to another (for example
I don't see how losing QString would cause any problems. I always
convert QString objects immediately to a python string using str().
Would it reduce code bloat? It seems like there should be a rule
here. If certain methods take python lists as arguments in place of
QStringList or return a
On Tuesday 18 October 2005 10:24, Phil Thompson wrote:
I'm wondering whether QString should be dropped in PyQt4 in order to make
it more Pythonic.
At the moment Python strings and unicode strings are automatically
converted to QStrings when passed as arguments - so there would be no
change
Phil Thompson [EMAIL PROTECTED] wrote:
At the moment Python strings and unicode strings are automatically
converted
to QStrings when passed as arguments - so there would be no change there.
If
a QString was returned by a method or an operator then a unicode string
would be returned instead.
On Tuesday 18 Oct 2005 18:24, Phil Thompson wrote:
I'm wondering whether QString should be dropped in PyQt4 in order to make
it more Pythonic.
At the moment Python strings and unicode strings are automatically
converted to QStrings when passed as arguments - so there would be no
change
Hi,
On Tuesday 18 Oct 2005 19:24, Phil Thompson wrote:
I'm wondering whether QString should be dropped in PyQt4 in order to make
it more Pythonic.
At the moment Python strings and unicode strings are automatically
converted to QStrings when passed as arguments - so there would be no
change
On Tuesday 18 October 2005 20:01, Yann Cointepas wrote:
Le Mardi 18 Octobre 2005 19:24, Phil Thompson a écrit :
I'm wondering whether QString should be dropped in PyQt4 in order to make
it more Pythonic.
Would it mean that QString content would always be copied when used in
Python ? If
Yes. Ideally a string would always just be a string; a string should
not be a string and this other thing, too.
A list should be a list, not a list and a list that can only hold
this other thing, too.
On Oct 18, 2005, at 11:53 AM, Simon Edwards wrote:
On Tuesday 18 October 2005 20:01,
Phil Thompson [EMAIL PROTECTED] wrote:
It will be fixed in tonight's snapshot.
It will now raise an exception saying that Foo should be derived from
sip.wrapper. If you change it so it is, hasattr() returns False as
expected.
I have not tried that snapshot yet. Anyway, I noticed this
Simon Edwards [EMAIL PROTECTED] wrote:
Would it mean that QString content would always be copied when used in
Python ? If yes, copying a QString from a widget to another (for example
widget1.setCaption( widget2.caption() ) ) would lead to an unnecessary
copy.
True, but how often do you copy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phil Thompson schrieb:
I'm wondering whether QString should be dropped in PyQt4 in order to make it
more Pythonic.
At the moment Python strings and unicode strings are automatically converted
to QStrings when passed as arguments - so there
On Tuesday 18 October 2005 9:13 pm, Giovanni Bajo wrote:
Phil Thompson [EMAIL PROTECTED] wrote:
It will be fixed in tonight's snapshot.
It will now raise an exception saying that Foo should be derived from
sip.wrapper. If you change it so it is, hasattr() returns False as
expected.
I
On Tuesday 18 October 2005 22:42, Giovanni Bajo wrote:
Simon Edwards [EMAIL PROTECTED] wrote:
Would it mean that QString content would always be copied when used in
Python ? If yes, copying a QString from a widget to another (for example
widget1.setCaption( widget2.caption() ) ) would
Simon Edwards [EMAIL PROTECTED] wrote:
I'm not saying it happens often. I'm saying that we the proposed change
it
would be *impossible* to do it. On the other hand, with the current
interface it is possible to do exactly what you want, it is just a little
less convenient for the common case.
On Tuesday 18 October 2005 23:24, Giovanni Bajo wrote:
Simon Edwards [EMAIL PROTECTED] wrote:
I'm not saying it happens often. I'm saying that we the proposed change
it
would be *impossible* to do it. On the other hand, with the current
interface it is possible to do exactly what you want,
Le Mardi 18 Octobre 2005 21:53, Simon Edwards a écrit :
On Tuesday 18 October 2005 20:01, Yann Cointepas wrote:
Le Mardi 18 Octobre 2005 19:24, Phil Thompson a écrit :
I'm wondering whether QString should be dropped in PyQt4 in order to
make it more Pythonic.
Would it mean that
On 18.10.05 23:59:56, Yann Cointepas wrote:
If it means that the too few people that may care about the copy cost should
be ignored then QString can be dropped. However, there is a simple case where
the copy can be a problem. I use QTextEdit in a kind of log system (adding
text line by
Phil Thompson [EMAIL PROTECTED] wrote:
behaviour:
import sip
isinstance(sip.wrapper, object)
True
issubclass(sip.wrapper, object)
True
Dunno if it's related to the fix.
Why is it strange?
It's uncommon for an object to both be an instance *and* a subclass of a
given class. What
Simon Edwards [EMAIL PROTECTED] wrote:
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?
The best example I can think of involves the XML parser in Qt (assuming
Phil
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 -
On Tuesday 18 Oct 2005 14:36, Brad Ralph wrote:
Hi Baz,
Thanks for your suggestion it was very helpful. I tried Ctrl-clicking the
class fold marker and as you suggest it colapses all of the child folds. I
also tried the Ctrl and Shift but this is the same as the toggle all folds
menu
Phil Thompson wrote:
I'm wondering whether QString should be dropped in PyQt4 in order to make it
more Pythonic.
At the moment Python strings and unicode strings are automatically converted
to QStrings when passed as arguments - so there would be no change there. If
a QString was returned by
On Tue, 18 Oct 2005 18:24:08, Phil Thompson wrote:
I'm wondering whether QString should be dropped in PyQt4 in order to make
it more Pythonic.
On one hand, it sounds like a nice idea. It would mean that you don't
have to think about manually converting the ones you think you'll need
and
On Tue, 18 Oct 2005 18:24:08 +0100
Phil Thompson [EMAIL PROTECTED] wrote:
I'm wondering whether QString should be dropped in PyQt4 in order to make it
more Pythonic.
At the moment Python strings and unicode strings are automatically converted
to QStrings when passed as arguments - so
35 matches
Mail list logo
