On Fri, 21 Oct 2005 07:21:46, Patrick K. O'Brien wrote:
> Phil Thompson wrote:
> > I'm totally unsympathetic to the idea of a *separate* Pythonic API to Qt.
> > The Python GUI toolkit "market" is fragmented enough as it is - this
> > would only add more confusion for (relatively) little benefit.
>
On Friday 21 October 2005 16:02, Phil Thompson wrote:
> On Friday 21 October 2005 8:03 pm, Gustavo Sverzut Barbieri wrote:
> > On 10/21/05, Gilbert Ramirez <[EMAIL PROTECTED]> wrote:
> > > For me, one of the strong points of Qt is that the documentation for
> > > it is great. Although the documenti
On Friday 21 October 2005 09:02, Phil Thompson wrote:
> I'm totally unsympathetic to the idea of a *separate* Pythonic API to Qt.
> The Python GUI toolkit "market" is fragmented enough as it is - this would
> only add more confusion for (relatively) little benefit.
Yes! down with the API separatis
On Friday 21 October 2005 8:03 pm, Gustavo Sverzut Barbieri wrote:
> On 10/21/05, Gilbert Ramirez <[EMAIL PROTECTED]> wrote:
> > For me, one of the strong points of Qt is that the documentation for
> > it is great. Although the documention is for C++, it's still a handy
> > reference for PyQT progr
> Maybe I wasn't clear. What I was proposing was *not* to create a full Qt
> wrapper, but to introduce *helpers* to manage normal Qt objects in a more
> Python way. If you look into the examples I wrote down yesterday, you'll see
> it's mostly about creating or accessing Qt objects in more pythonic
On 10/21/05, Gilbert Ramirez <[EMAIL PROTECTED]> wrote:
> For me, one of the strong points of Qt is that the documentation for
> it is great. Although the documention is for C++, it's still a handy
> reference for PyQT programmers because the mapping from Qt/C++ to PyQt
> is almost always straightf
James Emerton <[EMAIL PROTECTED]> wrote:
>>> That's a valid point, but I don't think it needs to be a 'totally
>>> separate project.' I understand the potential for incompatibility
>>> with two versions of PyQt, but what if they had different names? They
>>> can still be built from the same code
On 10/20/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> James Emerton <[EMAIL PROTECTED]> wrote:
>
> > That's a valid point, but I don't think it needs to be a 'totally
> > separate project.' I understand the potential for incompatibility
> > with two versions of PyQt, but what if they had differe
On Fri, 21 Oct 2005 08:28:30 -0700 (PDT)
Tony Willis <[EMAIL PROTECTED]> wrote:
> > Date: Fri, 21 Oct 2005 11:35:55 +0200
> > From: "Giovanni Bajo" <[EMAIL PROTECTED]>
> > Subject: Re: [PyKDE] QString in PyQt4 - Request for Comments
> > To: &qu
On 10/21/05, Phil Thompson <[EMAIL PROTECTED]> wrote:
> I'm totally unsympathetic to the idea of a *separate* Pythonic API to Qt.
> The Python GUI toolkit "market" is fragmented enough as it is - this would
> only add more confusion for (relatively) little benefit.
>
> People come to PyQt either a
> Date: Fri, 21 Oct 2005 11:35:55 +0200
> From: "Giovanni Bajo" <[EMAIL PROTECTED]>
> Subject: Re: [PyKDE] QString in PyQt4 - Request for Comments
> To: "Phil Thompson" <[EMAIL PROTECTED]>
> Cc: pykde@mats.imk.fraunhofer.de
> Message-ID: <[EMAI
Phil Thompson wrote:
>
> I'm totally unsympathetic to the idea of a *separate* Pythonic API to Qt.
> The Python GUI toolkit "market" is fragmented enough as it is - this would
> only add more confusion for (relatively) little benefit.
I agree with you, Phil. If you look at wxPython you'll see th
> I disagree with Giovanni. I signal signatures could be made somewhat
> more pythonic without the adverse impact. For example, it could remove
> the C++ constant, pointer and reference indicators ("const", "*" and
> "&") that Python-only programmers don't really understand. As long as
> the cha
Giovanni Bajo wrote:
> Phil Thompson <[EMAIL PROTECTED]> wrote:
>
> > I'm completely open to making the existing API more Pythonic - this is the
> > time to do it. For example, I did casually float the idea of not using C++
> > types in signal signatures in a previous post - but nobody bit.
>
> I
Phil Thompson <[EMAIL PROTECTED]> wrote:
> I'm completely open to making the existing API more Pythonic - this is the
> time to do it. For example, I did casually float the idea of not using C++
> types in signal signatures in a previous post - but nobody bit.
I didn't, because of the reasons exp
> David Boddie <[EMAIL PROTECTED]> wrote:
>
>> I wonder what it means to have a Pythonic API. Apart from transparent
>> use of native types and classes, how could you make it so much more
>> Pythonic? Allow direct access to properties as attributes? Change
>> method names to lower case with undersc
David Boddie <[EMAIL PROTECTED]> wrote:
> I wonder what it means to have a Pythonic API. Apart from transparent
> use of native types and classes, how could you make it so much more
> Pythonic? Allow direct access to properties as attributes? Change
> method names to lower case with underscores? I
James Emerton <[EMAIL PROTECTED]> wrote:
> That's a valid point, but I don't think it needs to be a 'totally
> separate project.' I understand the potential for incompatibility
> with two versions of PyQt, but what if they had different names? They
> can still be built from the same codebase, wi
On Thu, 20 Oct 2005 03:21:33, Giovanni Bajo wrote:
> In my humble opinion, PyQt should stay as close to C++ Qt as possible. It's
> a binding. There are many, many, many places where the Qt API could be made
> more Pythonic (just stretch your imagination), but those can find their
> place in a libr
On Thursday 20 Oct 2005 07:51, Simon Edwards wrote:
>
> If methods like QTextEdit.text() could magically read minds and return a
> Python string or a QString when desired, then everyone would be happy. :-)
> Really, what we have in PyQt3 works fine with string except for in the case
> of return typ
> Yes, I believe it would good to have two libraries. It's orthogonal to this
> string issue though, but I wouldn't mind a more Pythonic way to use Qt. I'm
> sure there are dozen of things that could be done easily in Python and are
> harder in Qt because of C++. Of course, this is a totally differ
Simon Edwards <[EMAIL PROTECTED]> wrote:
> We could do something ugly like make QTextEdit.text() return a Python
string
> (which is what most people want most of the time), and then add a keyword
> argument "qstring_please" for the case where QString is desired...
optimises
> the common case (for
I heard Mike Tammerman said:
> I don't know how difficult or feasible it is, but I would suggest
> using macros, so people can choose whether to use QString or python
> str while compiling pyqt.
Please, no!
If we do that, we'll never be able to release a PyQt program and be
certain it'll work o
I don't know how difficult or feasible it is, but I would suggest
using macros, so people can choose whether to use QString or python
str while compiling pyqt.
Just an idea.
Mike
On 10/18/05, Phil Thompson <[EMAIL PROTECTED]> wrote:
> I'm wondering whether QString should be dropped in PyQt4 in or
On Thursday 20 October 2005 03:21, Giovanni Bajo wrote:
> James Emerton <[EMAIL PROTECTED]> wrote:
>
> > I'm very in favour of the automatic conversion of QStrings into native
> > Python strings. I always thought that multiple string types was an
> > annoyance exclusive to C++. I'm also not conv
James Emerton <[EMAIL PROTECTED]> wrote:
> I'm very in favour of the automatic conversion of QStrings into native
> Python strings. I always thought that multiple string types was an
> annoyance exclusive to C++. I'm also not convinced that performance
> is a compelling argument for the preserva
I'm very in favour of the automatic conversion of QStrings into native
Python strings. I always thought that multiple string types was an
annoyance exclusive to C++. I'm also not convinced that performance
is a compelling argument for the preservation of QString in Python.
See performance data:
On Wednesday 19 October 2005 09:47, Phil Thompson wrote:
> On Wednesday 19 October 2005 1:17 am, David Boddie wrote:
> > * Maintenance of QStrings passed to Python implemented methods -
> > sometimes it's good to keep things in the same form that they were
> > supplied in, although maybe it's not
On Wednesday 19 October 2005 5:23 pm, Jim Bublitz wrote:
> On Wednesday 19 October 2005 00:47, Phil Thompson wrote:
> > QString just wouldn't exist in PyQt4.
>
> Would there still be something to allow me to handle something like:
>
> QMap
>
> with sipBuildResult and sipForceConvertTo_QString?
On Wednesday 19 October 2005 00:47, Phil Thompson wrote:
> QString just wouldn't exist in PyQt4.
Would there still be something to allow me to handle something like:
QMap
with sipBuildResult and sipForceConvertTo_QString?
Also, KDE still uses QCString in a bunch of places - will that disap
As I've said, I have made that selling point many times - mainly as a sop to
C++ programmers and avoid religious my-language-is-better-than-yours
arguments. However, I don't know of anybody who has actually done it.
We selectively port from Python to C++, depending on the broader
mod
Phil Thompson <[EMAIL PROTECTED]> wrote:
>> Being a newb here, I could be way off base, but one of the selling
>> points I keep reading for using PyQt and PyKDE are for rapid
>> prototyping apps that later get converted to C++. Would getting rid
>> of QStrings not impose a greater conversion burd
On Wed, 19 Oct 2005 09:56:27 +0100
Phil Thompson <[EMAIL PROTECTED]> wrote:
>
> As I've said, I have made that selling point many times - mainly as a sop to
> C++ programmers and avoid religious my-language-is-better-than-yours
> arguments. However, I don't know of anybody who has actually done
On Wednesday 19 October 2005 8:09 pm, John Layt wrote:
> On Wed, 19 Oct 2005 00:17, David Boddie wrote:
> > I think that there are two groups of people who expect different things,
> > and QString is possibly controversial to many people because it's
> > peculiar to see a class that duplicates the
On Wed, 19 Oct 2005 00:17, David Boddie wrote:
> I think that there are two groups of people who expect different things,
> and QString is possibly controversial to many people because it's peculiar
> to see a class that duplicates the functionality of a built-in type.
> However, I think that there
On Wednesday 19 October 2005 1:17 am, David Boddie wrote:
> 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 thin
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 - s
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 keepi
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 ->
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 (assumin
El Martes 18 Octubre 2005 18:59, Yann Cointepas escribió:
> 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 tex
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 l
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
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 wh
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 comm
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() )
-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
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
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, Ya
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 ?
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
> ch
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
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 inste
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
> cha
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
İ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 much string manipulation in Python? I
recognize t
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
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
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, b
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 quite anxious to have to
start working with Qt4 as soon as possib
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
> cha
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 operator
62 matches
Mail list logo
