Re: [PyKDE] QString in PyQt4 - Request for Comments
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've got used to the value()/setValue() method naming convention for dealing with properties! Some ideas: 1) Native types everywhere. This includes sizes, rects, containers, iterators and whatnot. 2) Properties. I'd also make all the widget constructors accept an optional initial value for all the properties as keyword arguments: QGroupBox(self, insideSpaing=5, columns=4) 3) The signal/slot stuff is a little too complex, with its call to QObject.connect. It inherits from the C++ interface. I'm sure a more Pythonic syntax can be worked out. 4) Layout construction. I wonder why can't we have something which makes your tree clearer: HBoxLayout([ VBoxLayout([ Label(foo), Label(bar) ]), QComboBox(option1 option2 option3.split(), readOnly=True), QButton(self, checked=true, tristate=true) ]) This would also allow to indent your code as to reflect the hierarchy, which makes it much more readable. 5) Accessing a child by name could be magically be done as self.child_name, using __getattr__. This is especially useful for layout constructed as above to access childs to do connections and whatnot. I'm sympathetic to the idea of a Pythonic API to Qt but, like you, I think that it should be provided by a higher level wrapper. There are some really good reasons for this: 1. The low level interface would still be accessible from Python. 2. Anyone concerned about performance can use the low level interface. The people who want a higher level API probably hopefully won't be too bothered by any extra latency that the wrapper will introduce, and they can still use the low level interface (or C++) if it turns out to be a problem. 3. The Pythonic wrapper can be done in Python rather than in the binding layer. This means that it's easier for people to work on it and customize its behaviour. 4. The wrapper doesn't have to be written by Phil. Hopefully, he should be happy about that. ;-) I totally agree with you. 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 as existing Python programmers looking for a decent toolkit, or Qt/KDE programmers looking for a decent programming language. I think the former is a larger group than the latter and this difference will only become more pronounced with the Windows GPL version. 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. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 explained previously: I believe it would just cause more confusion, in the current PyQt design. It's just too handy to go looking to the signature in the Qt Assistant and use it. I don't want to go check in two different manuals. Until now, PyQt's goal has been to adhere as much as possible to Qt, to not confuse existing Qt users and I think it's a noble goal. I also understand that this is not ideal for a Python-only programmer. -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 didn't, because of the reasons explained previously: I believe it would just cause more confusion, in the current PyQt design. It's just too handy to go looking to the signature in the Qt Assistant and use it. I don't want to go check in two different manuals. Until now, PyQt's goal has been to adhere as much as possible to Qt, to not confuse existing Qt users and I think it's a noble goal. I also understand that this is not ideal for a Python-only programmer. 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 change was consistent, you would not need to use a second manual. And it would make it easier to remember some signatures without referring to a manual or wondering whether the parameter was a constant, pointer or reference. Regarding the more general questions, I also think that things should be made a bit more pythonic without deviating much from the Qt API. Python unicode strings should be returned in place of QString, maybe with a way of using a switch to get the QString if desired. And I think that Python containers should be used in place of Qt's template containers. Doug. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 change was consistent, you would not need to use a second manual. And it would make it easier to remember some signatures without referring to a manual or wondering whether the parameter was a constant, pointer or reference. If the change could be made whilst supporting the old fully qualified format, I'm all for it. Regarding the more general questions, I also think that things should be made a bit more pythonic without deviating much from the Qt API. Python unicode strings should be returned in place of QString, maybe with a way of using a switch to get the QString if desired. And I think that Python containers should be used in place of Qt's template containers. These two points I totally support - QString has bitten me more than once, and using the template classes appears somewhat archaic to me - especially because python is so strong and neatly integrated in the field of iterators and so on. Regards, Diez ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 that there have been a number of attempts to add a more Pythonic layer over wxPython, none of which have really succeeded in any significant way. I think its unrealistic to think that a separate API could be created on top of PyQt that would actually gain enough support from the community to be something that large numbers of developers would be willing to take a chance on. Nobody wants to invest in an API that might not have a future. I know I feel that way. People come to PyQt either as existing Python programmers looking for a decent toolkit, or Qt/KDE programmers looking for a decent programming language. I think the former is a larger group than the latter and this difference will only become more pronounced with the Windows GPL version. Again, I agree. And while I'm sympathetic to the C++ programmers who would like to see the same API when they work in Python, I'm more sympathetic to the Python programmers who find C++ to be strange, incomprehensible, or simply painful. I think serious C++ programmers would have a smaller conceptual burden if they had to switch to a more Pythonic API when they work in Python, than if Python programmers had to know a bit about C++ when they work with PyQt. Again, the same thing happens in wxPython - the vast majority of Python programmers have no desire whatsoever to have to deal with concepts from C++. 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 guess I wasn't on the list then, so I'll bite now. Even though I do know enough C++ to be dangerous, I'm much happier when I can live within the safe, dry, warm confines of Python. :-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevohttp://www.schevo.org Pypersyst http://www.pypersyst.org PyDispatcher http://pydispatcher.sourceforge.net ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 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 explained previously: I believe it would just cause more confusion, in the current PyQt design. It's just too handy to go looking to the signature in the Qt Assistant and use it. I don't want to go check in two different manuals. Until now, PyQt's goal has been to adhere as much as possible to Qt, to not confuse existing Qt users and I think it's a noble goal. I also understand that this is not ideal for a Python-only programmer. -- Giovanni Bajo My $0.02 worth of option on this issue. I feel its indeed important that there be a Python interface to Qt that reflects the C++ interface as closely as possible. Whenever I have a problem or need to find out something about a Qt class member I first bring up Assistant and look there. I wouldn't want to have to remember that I'm using PyQt and first look in some other manual. I use another python package which interfaces to a 3rd party add-on package that makes use of Qt (Qwt). There are some calls in PyQwt which do not correspond to the C++ interface (yes, I realize that sometimes modifications cannot be avoided). However I've wasted time in the past trying to figure out why something wasn't working only to have to grope deeply into the PyQwt docs to discover that the Python interface was different to the Qwt C++ method. I have no objection to someone developing a 'Pythonic' (I'm always curious as to exactly what this means) wrapper interface to Qt if they wish, but I think it important that lower level interfaces be available as much as possible. Cheers Tony ___ Tony Willis National Research Council [EMAIL PROTECTED] Box 248 (250)493-2277 Penticton, BC V2A 6J9 fax: 493-7767 Government of CanadaGouvernement du Canada ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 as existing Python programmers looking for a decent toolkit, or Qt/KDE programmers looking for a decent programming language. I think the former is a larger group than the latter and this difference will only become more pronounced with the Windows GPL version. 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. Phil 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 straightforward. I'd like to keep the non-straight-forward mappings in the documentation to a minimum, because no one is going to do as good of a job as writing documentation for an API that is very different from Qt's. --gilbert ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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: Phil Thompson [EMAIL PROTECTED] Cc: pykde@mats.imk.fraunhofer.de Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 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 explained previously: I believe it would just cause more confusion, in the current PyQt design. It's just too handy to go looking to the signature in the Qt Assistant and use it. I don't want to go check in two different manuals. Until now, PyQt's goal has been to adhere as much as possible to Qt, to not confuse existing Qt users and I think it's a noble goal. I also understand that this is not ideal for a Python-only programmer. -- Giovanni Bajo My $0.02 worth of option on this issue. I feel its indeed important that there be a Python interface to Qt that reflects the C++ interface as closely as possible. Whenever I have a problem or need to find out something about a Qt class member I first bring up Assistant and look there. I wouldn't want to have to remember that I'm using PyQt and first look in some other manual. I use another python package which interfaces to a 3rd party add-on package that makes use of Qt (Qwt). There are some calls in PyQwt which do not correspond to the C++ interface (yes, I realize that sometimes modifications cannot be avoided). However I've wasted time in the past trying to figure out why something wasn't working only to have to grope deeply into the PyQwt docs to discover that the Python interface was different to the Qwt C++ method. I have no objection to someone developing a 'Pythonic' (I'm always curious as to exactly what this means) wrapper interface to Qt if they wish, but I think it important that lower level interfaces be available as much as possible. Happy (but sorry for Tony) to see one of my users bring up suffering from 'Pythonic' features because of documentation problems. I do not know exactly what Tony is referring to, but I am sure the feature is more 'Pythonic' and that I have documented it. There is a Pythonic solution for such cases: -- doc strings They have been on the TODO list for a long time. I am using doc-strings all the time, if I can. I fully agree with Toni and Giovanni that a PyQt API close to the C++ API of Qt is important for anybody who makes heavy use of PyQt out of the context of Qt-Designer. Only people with exceptional memories can do that without Qt-Assistant and using two manuals is too much. Some comments on the Giovanni's ideas (hate to see them implemented in a separate Python layer): (1) support for iterators if it can be implemented efficiently. Great. (2) setting of properties by means of keyword arguments. In the days before SIP-4, PyQwt offered this possibility by patching the Python wrapper which imported the library containing the C++ extension It worked for all methods of the form setThing(Thing t, ..). I was obliged to remove this feature when SIP-4 was introduced, with regret because it was a nice way to group all initialization in a single statement. It should not 'simple' to make SIP generate C++ code which does the same. (4) I like this idea of layout construction, enough that it will enter my secret personal toolkit someday. I hate to see QStrings disappear, because I think the alternative will require more memory and for some programs the memory footprint will become excessive. Wouldn't it be possible to control if methods return QStrings or Python strings at runtime on module level or by passing an extra argument? Gerard ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 different names? They can still be built from the same codebase, with %Feature directives. I believe a Python-only implementation would be easier to work on. See also the mail by David Bobble with which I totally agree. This depends on where you draw the line. A total Pythonic implementation of Qt is infeasible. The PyQt community is not large enough to develop a stable and mature API. I do not mean to imply a lack of ability, simply a lack of manpower. The Qt 3.3 docs list 3626 unique method names, with many of them appearing in multiple classes. That's an awful lot of maintenance! I'm far more interested in an API that does not introduce redundant types. Implementing this kind of type conversion directly in Python is both ugly and slow. It requires the implementation to wrap every method that returns a type that should be converted. SIP already has a facility to deal with this: %MappedType. This keeps the documentation problem out of the way as well; provide a list of classes and their Python equivalent. With a little effort, someone could even assemble a post-processor that mutates the Qt/C++ docs into their Python equivalent. If someone wants to take on the task of implementing the truly Pythonic API, they will at least not have to worry about all those wonky Qt/C++ types. James ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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, with %Feature directives. I believe a Python-only implementation would be easier to work on. See also the mail by David Bobble with which I totally agree. This depends on where you draw the line. A total Pythonic implementation of Qt is infeasible. The PyQt community is not large enough to develop a stable and mature API. I do not mean to imply a lack of ability, simply a lack of manpower. The Qt 3.3 docs list 3626 unique method names, with many of them appearing in multiple classes. That's an awful lot of maintenance! 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 way, not wrapping each and every object and each and every method. -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 straightforward. I'd like to keep the non-straight-forward mappings in the documentation to a minimum, because no one is going to do as good of a job as writing documentation for an API that is very different from Qt's. What raises another point: PyQT should include docstrings! Phil, have you considered this? -- Gustavo Sverzut Barbieri --- Computer Engineer 2001 - UNICAMP GPSL - Grupo Pro Software Livre Cell..: +55 (19) 9165 8010 Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] Skype: gsbarbieri GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 way, not wrapping each and every object and each and every method. Which is essentially what I had in mind, wrt to the handling of things like properties, layouts, and keyword based object initialisation. Essentially everything except return types. I don't know how one would convert all the return types from Qt to their Python equivalent, without wrapping every method? James ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 programmers because the mapping from Qt/C++ to PyQt is almost always straightforward. I'd like to keep the non-straight-forward mappings in the documentation to a minimum, because no one is going to do as good of a job as writing documentation for an API that is very different from Qt's. What raises another point: PyQT should include docstrings! Phil, have you considered this? Yes - it's been on the TODO list for a while. Current PyQt documentation is effectively handwritten and (therefore) only describes differences to Qt. I will add automatic generation of documentation to SIP at some point which will describe what is actually implemented using Python data types. It would then be easy enough to generate a summary as docstrings - maybe as a configuration option. (And if anybody has bright ideas about how to automagically generate links to the corresponding bit of Qt documentation, I'd like to hear them.) Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 separatists! But I dont think thats what Giovanni was suggesting (although it took several re-readings of his email to realise it). Trolltech enrich the Qt API as far as C++ allows, but that shouldnt prevent us further enriching the API in areas where Python is richer than C++. 2) Properties. I dont think I agree with all of Giovanni's suggestions, but this is top of his list for being an obviously good idea. There's no good reason to not support Python's property syntax for setting and getting things that Qt documents as being properties. (In addition to the getter/setter function API that C++ is forced to use). -- Toby Dickenson ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 documention is for C++, it's still a handy reference for PyQT programmers because the mapping from Qt/C++ to PyQt is almost always straightforward. I'd like to keep the non-straight-forward mappings in the documentation to a minimum, because no one is going to do as good of a job as writing documentation for an API that is very different from Qt's. What raises another point: PyQT should include docstrings! Phil, have you considered this? Yes - it's been on the TODO list for a while. Current PyQt documentation is effectively handwritten and (therefore) only describes differences to Qt. I will add automatic generation of documentation to SIP at some point which will describe what is actually implemented using Python data types. It would then be easy enough to generate a summary as docstrings - maybe as a configuration option. (And if anybody has bright ideas about how to automagically generate links to the corresponding bit of Qt documentation, I'd like to hear them.) On the Qt3 docs I have, all of the pages are links like .../classname.html#method name basically - it looks a little trickier for ctors or overloaded methods, but at least it's easy to get close. I generate PyKDE docs (which aren't much more than method signatures) from the same code that parses h files - sip files - it's probably easier to spit out HTML than sip syntax. KDE has made the docs more difficult to generate links for though - I think the intrapage links (#) are just numbered sequentially now rather than related to method names. Jim ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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. I agree with you, Phil. If you look at wxPython you'll see that there have been a number of attempts to add a more Pythonic layer over wxPython, none of which have really succeeded in any significant way. That may be so, but what I've heard about wxPython makes me think that the reasons for this lack of success (if that is the case) is different to any problems that a two layer Pythonic wrapper for PyQt might face. My impression is that there are/were competing Pythonic wrappers for wxPython, some of which are perceived as less complete than others, and the resemblance of the wxPython API to the wxWidgets API makes it less attractive to build on than it would be to build on top of a straight set of Qt bindings. I think its unrealistic to think that a separate API could be created on top of PyQt that would actually gain enough support from the community to be something that large numbers of developers would be willing to take a chance on. Nobody wants to invest in an API that might not have a future. I know I feel that way. That's may be why some people aren't sure whether they should use wxPython or Wax. It's worth noting that Wax was represented in the Google Summer of Code programme, so there is some support for that approach. People come to PyQt either as existing Python programmers looking for a decent toolkit, or Qt/KDE programmers looking for a decent programming language. I think the former is a larger group than the latter and this difference will only become more pronounced with the Windows GPL version. Again, I agree. And while I'm sympathetic to the C++ programmers who would like to see the same API when they work in Python, I'm more sympathetic to the Python programmers who find C++ to be strange, incomprehensible, or simply painful. I'm sympathetic, too. I'm just looking for some level of continuity between the two languages. Some changes might just lead to confusion. I think serious C++ programmers would have a smaller conceptual burden if they had to switch to a more Pythonic API when they work in Python, than if Python programmers had to know a bit about C++ when they work with PyQt. Again, the same thing happens in wxPython - the vast majority of Python programmers have no desire whatsoever to have to deal with concepts from C++. That may be so, but you can't completely isolate programmers from non- Pythonic concepts. There are restrictions due to the type system that you can't ignore. For example, you could map QList-based containers to Python lists and provide a Pythonic iterator interface for them, but you still have to ensure that they each item in the list has the same type if you want to pass it back to C++ reliably. Some of these restrictions also help to improve performance or memory usage at the cost of flexibility. There are other features that are probably very strange from the perspective of a Python developer, and there are features that are common to Qt and the Python standard library. That doesn't necessarily mean that the bindings need to be more Pythonic in those areas. 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. Personally, I think it doesn't make sense for Python developers to have to deal with const, pointer or reference notation. However, you are communicating with C++, and the interfaces are defined in terms of non-Python types. Declaring types isn't a natural thing in Python, and many people are going to fall back on the documentation for this, so introducing another convention might actually make it more difficult for some developers. You can provide functions to convert between notations, but you could implement something like this on top of the existing scheme. The above probably seems very unfocused. I'm not against the idea of Pythonic bindings in principle, though I am aware that making things easier for some developers (maybe the majority in the future) can make things difficult for others. David ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 convinced that performance is a compelling argument for the preservation of QString in Python. See performance data: http://www.gotw.ca/gotw/045.htm We're not doing a case about COW-strings (ala QString) vs copied strings. We're just saying that Qt's QString is COW and there are application and real world scenario exploiting this feature If anything, that link shows that we just don't know and can't guess what the performance impact is of different strategies for handling strings. Further more, anyone trying to optimise their code by using QString instead of something had better go collect some imperical data first on what the real impact is for their string handling patterns and combination of memory allocator, threading etc etc. The list of open issues looks something like: * performance (could be worse, might not be a problem) * possible encoding and characterset issues. * QStrings are mutable while Python strings are immutable. (I don't know if this causes any real problems, but still...) 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 types. 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 people) and makes the not so common case possible... 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), On the other hand, there is the argument that if you want code Qt stuff in a C++ kid of way, then maybe you should just use C++. but those can find their place in a library which wraps Qt/PyQt with the goal to provide a more Pythonic API. You want 2 libraries? How practical is it anyway to replace the Python wrapper of QTextEdit, for example, with an extended version (Python code) that adds more Pythonic goodness? cheers, -- Simon Edwards | Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 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 then a unicode string would be returned instead. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString Comments, opinions welcome. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 on the user's machine and whatever incompatible variant of PyQt they compiled. -- S. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 people) and makes the not so common case possible... I wouldn't mind this. I wouldn't even mind a global option like qt.returnQStringPlease(True). but those can find their place in a library which wraps Qt/PyQt with the goal to provide a more Pythonic API. You want 2 libraries? How practical is it anyway to replace the Python wrapper of QTextEdit, for example, with an extended version (Python code) that adds more Pythonic goodness? 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 different project, because you'd get additional new different APIs to create and access the Qt classes. I'm just saying that the scope of PyQt shouldn't be too make a Python version of Qt: it should be to wrap Qt to Python. This string issue is of course very borderline, and I don't think it's inappropriate for PyQt to return Python strings from methods, as long as there is still a way to access QStrings if needed for any reason. -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 different project, because you'd get additional new different APIs to create and access the Qt classes. I'm just saying that the scope of PyQt shouldn't be too make a Python version of Qt: it should be to wrap Qt to Python. 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, with %Feature directives. 'import qt' gets you QStrings and a very C++-esq API. Suitable for prototyping work. 'import pyqt' gets you python strings, dates, collections, etc. More appropriate for pure python work. Lets say both variants share the vast majority of their code, via a .so/.dll that is linked in the traditional way. The .pyd file contains the module structure, which has function pointers to our module's conversion routines. Sounds pretty crazy, eh? James ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 types. Yes, at the moment we are having to write: qt_str = QTextEdit.text() py_str = unicode(QTextEdit.text()) ... but possibly we'd like to write: py_str = QTextEdit.text() qt_str = QString(QTextEdit.text()) ... such that the QString constructor somehow disables the default conversion to a python unicode object and simply returns the original qstring. Of course, this second part is total hand-waving. However, IMHO the syntax is so nice that I thought it worth at least putting it out there. Is there any way something like this could be made to work? -- Baz Walter ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 library which wraps Qt/PyQt with the goal to provide a more Pythonic API. 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've got used to the value()/setValue() method naming convention for dealing with properties! It's probably instructive to look at other attempts to provide high level wrappers for existing bindings. If we're going down this road, we can as well totally remove any kind of Qt container and iterator, and substitute everything with Python concepts. I would probably like an additional PyQt layer for this, but I believe the basic PyQt should fly lower. I'm sympathetic to the idea of a Pythonic API to Qt but, like you, I think that it should be provided by a higher level wrapper. There are some really good reasons for this: 1. The low level interface would still be accessible from Python. 2. Anyone concerned about performance can use the low level interface. The people who want a higher level API probably hopefully won't be too bothered by any extra latency that the wrapper will introduce, and they can still use the low level interface (or C++) if it turns out to be a problem. 3. The Pythonic wrapper can be done in Python rather than in the binding layer. This means that it's easier for people to work on it and customize its behaviour. 4. The wrapper doesn't have to be written by Phil. Hopefully, he should be happy about that. ;-) David ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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, with %Feature directives. I believe a Python-only implementation would be easier to work on. See also the mail by David Bobble with which I totally agree. Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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've got used to the value()/setValue() method naming convention for dealing with properties! Some ideas: 1) Native types everywhere. This includes sizes, rects, containers, iterators and whatnot. 2) Properties. I'd also make all the widget constructors accept an optional initial value for all the properties as keyword arguments: QGroupBox(self, insideSpaing=5, columns=4) 3) The signal/slot stuff is a little too complex, with its call to QObject.connect. It inherits from the C++ interface. I'm sure a more Pythonic syntax can be worked out. 4) Layout construction. I wonder why can't we have something which makes your tree clearer: HBoxLayout([ VBoxLayout([ Label(foo), Label(bar) ]), QComboBox(option1 option2 option3.split(), readOnly=True), QButton(self, checked=true, tristate=true) ]) This would also allow to indent your code as to reflect the hierarchy, which makes it much more readable. 5) Accessing a child by name could be magically be done as self.child_name, using __getattr__. This is especially useful for layout constructed as above to access childs to do connections and whatnot. I'm sympathetic to the idea of a Pythonic API to Qt but, like you, I think that it should be provided by a higher level wrapper. There are some really good reasons for this: 1. The low level interface would still be accessible from Python. 2. Anyone concerned about performance can use the low level interface. The people who want a higher level API probably hopefully won't be too bothered by any extra latency that the wrapper will introduce, and they can still use the low level interface (or C++) if it turns out to be a problem. 3. The Pythonic wrapper can be done in Python rather than in the binding layer. This means that it's easier for people to work on it and customize its behaviour. 4. The wrapper doesn't have to be written by Phil. Hopefully, he should be happy about that. ;-) I totally agree with you. Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 think about manually converting the ones you think you'll need and keeping track of the ones you don't. On the other hand, the idea of dropping it makes me feel uneasy for reasons I'll talk about below. 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. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. I took another look at the QString API in Qt 4 to see whether this would be all that bad. There are a few functions there that provide in-place operations on strings and, although there are no exact equivalents for Python strings, they probably aren't all that relevant in Python. The same is possibly true of conversion functions like toDouble() and fromDouble(). One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. Yes, this is much better. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString This looks strange, but makes some kind of sense if you consider QString to be a more general string type than Python strings. It's standard Python behaviour, it's not something I've specifically implemented. As Gerard pointed out the same happens with ints and floats. Comments, opinions welcome. There are a few areas where we'd need to think about the consequences a bit more, or at least try experimenting with a Pythonic implementation, before deciding whether the suggested behaviour would be an improvement. Off the top of my head, I think we should consider the following things: * Translation with tr() - would it return a QString or a Python unicode string? QString just wouldn't exist in PyQt4. * The types of arguments emitted with signals and the types of values received in slots - declaring arguments as const QString then getting a unicode string might be a bit confusing. This isn't specific to QString - it applies to anything implemented as a %MappedType, ie. it's an existing issue. Whether PyQt4 should take Python types in signal signatures is another debate... * 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 as important for QStrings as it is for, say, QImages. Examples? It would be possible to add an annotation to SIP, something like /GetWrapper/ so that %MethodCode could be given the C++ address as a void *. * Codecs - does Python support the same range of codecs as Qt? As a mono-lingual Brit, that's one of my implied questions - is Python's unicode support good enough to be used instead of Qt's? * QLatin1String and other restricted string types - these are something of an implementation detail, but it's worth thinking about how these would be represented. They wouldn't be wrapped. It would be also interesting to consider whether QStrings could be cached to avoid lots of copying between QString and unicode objects. While it's easy enough to create a sub-type of the Python unicode type that keeps an optional QString copy, I can't see how to make it any easier to use than QString. You'd have to create it with some sort of ctor. The alternative approach of keeping a separate map of string/unicode objects to QStrings gives you problems with garbage collecting the map. (Python string/unicode objects don't support weak references.) Personally, I don't see the problem with having strings arrive in Python functions or methods as unicode objects, but I'd like to see QString kept around for familiarity. 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's an advantage in being able to write code in Python that resembles what you would write in C++. This applies to other classes that would appear to duplicate Python built-in types. I've always promoted PyQt's use as a rapid prototyping tool where you eventually re-write the prototype in C++ - but I'm not convinced that anybody actually does this. With the availability of GPL Qt for Windows I hope/expect that there will be many new users
Re: [PyKDE] QString in PyQt4 - Request for Comments
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's an advantage in being able to write code in Python that resembles what you would write in C++. This applies to other classes that would appear to duplicate Python built-in types. 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 burden on these people and thus alienate them? And what would the downstream effect on PyKDE be? John. Send instant messages to your online friends http://au.messenger.yahoo.com ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 functionality of a built-in type. However, I think that there's an advantage in being able to write code in Python that resembles what you would write in C++. This applies to other classes that would appear to duplicate Python built-in types. 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 burden on these people and thus alienate them? 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. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 it. I do extend SIP-wrapped classes in Python and reimplement the extensions later in C++ and extend the wrappers. Gerard ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 burden on these people and thus alienate them? 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. I do that very often. Even for C++ applications, it happens from time to time to quickly test this or that dialog using PyQt. Just like we use designer to see how things can be arranged, even if we end up writing up the code to build the dialogs, we use PyQt to see how interactive things can be arranged. Anyway, I'm not sure I have ever had issues with strings in these prototypes. Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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: QMapQString, QString with sipBuildResult and sipForceConvertTo_QString? Also, KDE still uses QCString in a bunch of places - will that disappear too? Same question for QStringList, which is also somewhat redundant, but gets used in places KListView. Jim ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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: QMapQString, QString with sipBuildResult and sipForceConvertTo_QString? You'd implement that as a %MappedType as you would today. Also, KDE still uses QCString in a bunch of places - will that disappear too? Same question for QStringList, which is also somewhat redundant, but gets used in places KListView. We're talking PyQt4 - QCString isn't in Qt4. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 as important for QStrings as it is for, say, QImages. Examples? It would be possible to add an annotation to SIP, something like /GetWrapper/ so that %MethodCode could be given the C++ address as a void *. I can't think of any QString examples. There was a problem with QImages and ThumbCreators, but that's a different story. * Codecs - does Python support the same range of codecs as Qt? As a mono-lingual Brit, that's one of my implied questions - is Python's unicode support good enough to be used instead of Qt's? After a brief desperate search at the Python prompt, I searched the web for a page with this information and found this: http://docs.python.org/lib/standard-encodings.html So it seems that Python may support a superset of codecs. The list of codecs supported by Qt 4 can be found on this page: http://doc.trolltech.com/4.0/qtextcodec.html You would need to ask whether people find themselves handling encoded text with Python's built-in types rather than with QString and QTextCodec. It would be also interesting to consider whether QStrings could be cached to avoid lots of copying between QString and unicode objects. While it's easy enough to create a sub-type of the Python unicode type that keeps an optional QString copy, I can't see how to make it any easier to use than QString. You'd have to create it with some sort of ctor. The alternative approach of keeping a separate map of string/unicode objects to QStrings gives you problems with garbage collecting the map. (Python string/unicode objects don't support weak references.) Sounds like more trouble than it's worth. :-/ I've always promoted PyQt's use as a rapid prototyping tool where you eventually re-write the prototype in C++ - but I'm not convinced that anybody actually does this. With the availability of GPL Qt for Windows I hope/expect that there will be many new users for PyQt4 (new to Python as well as new to Qt, and with no experience of C++) so eliminating C++isms is more important to me now than it has been in the past. Apart from vague worries about codec support, I suppose the only concerns I have are about performance and documenting Python-specific behaviour. David ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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: http://www.gotw.ca/gotw/045.htm I guess it comes down to who is the audience. I've already got a todo item in my list to implement QString as a mapped type in PyQt 3. I'll likely end up doing same to QDate and its brethren. James ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 preservation of QString in Python. See performance data: http://www.gotw.ca/gotw/045.htm We're not doing a case about COW-strings (ala QString) vs copied strings. We're just saying that Qt's QString is COW and there are application and real world scenario exploiting this feature (even if it performs worse in the average case -- whatever 'average case' might mean in this kind of benchamarks). By totally hiding QStrings from Python, you're making impossible to replicate this features. By exposing QString, you're just making a little less convenient some uses of strings. 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 library which wraps Qt/PyQt with the goal to provide a more Pythonic API. If we're going down this road, we can as well totally remove any kind of Qt container and iterator, and substitute everything with Python concepts. I would probably like an additional PyQt layer for this, but I believe the basic PyQt should fly lower. Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] QString in PyQt4 - Request for Comments
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 then a unicode string would be returned instead. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString Comments, opinions welcome. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 there. If a QString was returned by a method or an operator then a unicode string would be returned instead. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString Comments, opinions welcome. I very much like QString's api like endsWith instead of endswith. Its small but in the end all those small things matter :) Regards, ismail ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 quite anxious to have to start working with Qt4 as soon as possible. It's coming along. QtCore should be done fairly soon but I'll skip a few things at first - like threading and asynchronous signals. Most of the work so far has been plugging gaps in SIP and making sure you can run PyQt3 and PyQt4 alongside each other. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 much string manipulation in Python? I recognize that Python's method names are not always as consistent as Qt's, but once you are used to Python's anything else feels strange to me. Just curious. :-) I do lots of KDE programming in C++ so when I switch to Python its very comfortable that the api is the same. Because you are used to write endsWith for QString and expect such from a string class. So its just you get used to it. Nothing biggie. Regards, ismail ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 widget1.setCaption( widget2.caption() ) ) would lead to an unnecessary copy. -- Yann Cointepas Tel: +33 1 69 86 78 52 CEA - SHFJ Fax: +33 1 69 86 77 86 4, place du Général Leclerc 91401 Orsay Cedex France ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 list of QFileInfo instead of a QFileInfoList, then why are we using QString? Have we discovered a pattern that we should stick to by now? I say dump qt objects in favor of python objects wherever possible. While consistency with the c++ API is nice/important, python is not c+ +, and eventually anyone learning the nuances of using qt with python is going to get used to a lack of redundant classes. Further, I always saw pyqt as a total semantic improvement on pure c++ qt, so keep chopping! On Oct 18, 2005, at 9:24 AM, 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 a method or an operator then a unicode string would be returned instead. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString Comments, opinions welcome. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 there. If a QString was returned by a method or an operator then a unicode string would be returned instead. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString Comments, opinions welcome. KDE has a lot of template code using QString, as well as DCOP calls that take or return QString. As long as it's possible to handle those, I wouldn't object. I do like the correspondence between the C++ and Python APIs, but that isn't a huge deal. Jim ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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. There's a problem with efficiency. Unless you are doing something magic, you are going to copy the contents of the QStrings into the python object. This might matter in some cases. I'm not sure we should drop this just to avoid calling unicode() explicitally in some cases. It doesn't happen that often anyway. Weird idea: maybe it would be possible to make it a configure-time option? Would that be too much of a burden to maintain? In that case, I'm +1 on making the automatic conversion the default. -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 there. If a QString was returned by a method or an operator then a unicode string would be returned instead. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString Comments, opinions welcome. My immediate thoughts on this are that it is a great idea. Never having to worry again about making explicit conversions between pystrings and qstrings just fills me with joy. I have never found a single reason to prefer qt's string handling to python's - quite the opposite, in fact. Working with qstrings was probably one of the few things I found difficult when starting to use pyqt. I soon learned the best way to handle them, though: immediate conversion to a python unicode object :-) So, a definite +1 from me on getting rid of QStrings. python-comes-before-qt-in-pyqt-ly yours -- Baz Walter ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 there. If a QString was returned by a method or an operator then a unicode string would be returned instead. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. Being very much a newbie at this stuff I have one question. I'm building up nerve to implement a python scripting interface for a fairly large Qt based c++ application. I did some prototyping with Qt3 a while ago where I got the basics working (making calls from python etc...) Now, some of the calls would definitely return QString from the c++ code, would they then return unicode to the python code? Regards, Robert One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString Comments, opinions welcome. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde -- http://spamatica.se/musicsite/ ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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, 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 a string from one widget to another? I'm guessing almost never (never= not often enough to worry about, or be performance critical). The only place that copying might be an issue is in something like Qt's XML parser. Otherwise I say drop QString. The whole add str() thing is a pain in the ass and leads to subtle bugs (espically when you use strings as keys in dictionaries). cheers, -- Simon Edwards | Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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, 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, 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 a string from one widget to another? I'm guessing almost never (never= not often enough to worry about, or be performance critical). The only place that copying might be an issue is in something like Qt's XML parser. Otherwise I say drop QString. The whole add str() thing is a pain in the ass and leads to subtle bugs (espically when you use strings as keys in dictionaries). cheers, -- Simon Edwards | Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 a string from one widget to another? I'm guessing almost never (never= not often enough to worry about, or be performance critical). 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. The whole add str() thing is a pain in the ass and leads to subtle bugs (espically when you use strings as keys in dictionaries). This is an orthogonal issue, and I admit that it can get annoying pretty fast. There is a simple solution though: I have been meaning to suggest Phil to add an exception-raising __hash__ method to QString. Those who want to hash by identify can still do it explicitally (calling id()), instead of relying on it being the default. -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
-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 would be no change there. If a QString was returned by a method or an operator then a unicode string would be returned instead. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString I second the removal of QString in favour of Python strings. Not having to care about whether your strings are of type basetring or QString is well worth it, if there is no considerable loss in functionality. greetings Torsten - -- Torsten Marek [EMAIL PROTECTED] ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDVWCzfMVFHqJEyFgRAr9/AJ46vWDcC/K8RL0aJmWumBG/nP9AAgCcCaGI s/1tcyZ19ccuL/ZmpjUbBWk= =6Qdv -END PGP SIGNATURE- ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 lead to an unnecessary copy. True, but how often do you copy a string from one widget to another? I'm guessing almost never (never= not often enough to worry about, or be performance critical). 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. What I am saying is how cares if it impossible to do, performance is not an issue here. Making the common case work easily, bug free and as expected, is about a million times more important. The whole add str() thing is a pain in the ass and leads to subtle bugs (espically when you use strings as keys in dictionaries). This is an orthogonal issue, and I admit that it can get annoying pretty fast. I still haven't seen a good argument for keeping QString around. out you go! cheers, -- Simon Edwards | Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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. What I am saying is how cares if it impossible to do, performance is not an issue here. You don't care, I care. Don't do the mistake of thinking that your needs are the same of everyone else. Making the common case work easily, bug free and as expected, is about a million times more important. Even right now, the common case works bug free and just as expected. Your expectations are different from mine, but that does not change a thing. I know Qt uses QString and I know PyQt objects accepts and returns QString. There is nothing unexcepted in this. We're just speaking of adding an implicit conversion in the bindings of a language for which explicit is better than implicit is a motto. I'm just saying that we should think twice about it. -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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, it is just a little less convenient for the common case. What I am saying is how cares if it impossible to do, performance is not an issue here. 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 decides to support it in PyQt). cheers, -- Simon Edwards | Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 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 a string from one widget to another? I'm guessing almost never (never= not often enough to worry about, or be performance critical). The only place that copying might be an issue is in something like Qt's XML parser. Otherwise I say drop QString. The whole add str() thing is a pain in the ass and leads to subtle bugs (espically when you use strings as keys in dictionaries). cheers, 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 line). If QString is dropped, textEdit.setText( textEdit.text() + newLine ) will copy the text twice. For big text, it could be a problem. I am not a QString protector (I also had some problems with it at the begining) but I say we should think twice before removing it. -- Yann Cointepas Tel: +33 1 69 86 78 52 CEA - SHFJ Fax: +33 1 69 86 77 86 4, place du Général Leclerc 91401 Orsay Cedex France ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 line). If QString is dropped, textEdit.setText( textEdit.text() + newLine ) The real question here should be: Why don't you use setText(), when QTextEdit has an append()-function? Or is that not available in PyQt (I only checked the Qt3/4 docs). andreas -- Celebrate Hannibal Day this year. Take an elephant to lunch. ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 decides to support it in PyQt). A very simple case which happens often in my software is displaying logs in a text widget. -- Giovanni Bajo ___ 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] QString in PyQt4 - Request for Comments
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 keeping track of the ones you don't. On the other hand, the idea of dropping it makes me feel uneasy for reasons I'll talk about below. 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. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. I took another look at the QString API in Qt 4 to see whether this would be all that bad. There are a few functions there that provide in-place operations on strings and, although there are no exact equivalents for Python strings, they probably aren't all that relevant in Python. The same is possibly true of conversion functions like toDouble() and fromDouble(). One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. Yes, this is much better. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString This looks strange, but makes some kind of sense if you consider QString to be a more general string type than Python strings. Comments, opinions welcome. There are a few areas where we'd need to think about the consequences a bit more, or at least try experimenting with a Pythonic implementation, before deciding whether the suggested behaviour would be an improvement. Off the top of my head, I think we should consider the following things: * Translation with tr() - would it return a QString or a Python unicode string? * The types of arguments emitted with signals and the types of values received in slots - declaring arguments as const QString then getting a unicode string might be a bit confusing. * 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 as important for QStrings as it is for, say, QImages. * Codecs - does Python support the same range of codecs as Qt? * QLatin1String and other restricted string types - these are something of an implementation detail, but it's worth thinking about how these would be represented. It would be also interesting to consider whether QStrings could be cached to avoid lots of copying between QString and unicode objects. Personally, I don't see the problem with having strings arrive in Python functions or methods as unicode objects, but I'd like to see QString kept around for familiarity. 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's an advantage in being able to write code in Python that resembles what you would write in C++. This applies to other classes that would appear to duplicate Python built-in types. David ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
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 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. It sounds appealing but what does it cost in memory when a QString is shared between many other objects? If the conversion for all shared QStrings can be impemented in constant memory, I have less reservations (sometimes I translate between C++ and Python). If not, it may be that PyQt becomes less interesting for certain applications (for instance using qtsql, or with huge quantities of text). Memory footprint does matter. Obviously you would lose all of QString's methods and would have to rely on what Python gives you for manipulating strings. One of the limitations of QString has been that you couldn't do... q = Py + QString(Qt) ...but with current snapshots you can - so this is an argument for keeping QString as it has become easier to use. BTW, the following is a consequence of the additional support... s = Py # s is of type str s += QString(Qt) # s is now of type QString Is this really necessary (causes surprises when passing the result where a Python string is expected)? anInt += aFloat # anInt is of type float aFloat += anInt # aFloat is of type float Gerard ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
