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
[PyKDE] rotated CanvasText
Helo dear python-hackers,
im quite new to python and pyqt and stumbled across a problem
which seems unsolvable for me. I wrote a little test application
using the canvas painting facility and wanted to rotate a canvasText.
But i cant figure how to get it properly repainted after i moved
the view or the whole window.
The rotated Text always looks dirty or doesnt get repainted at all.
Here's the code:
from qt import *
from qtcanvas import *
import sys
## let pyqt say which name an event has!
## borrowed this class from:
##
http://mats.imk.fraunhofer.de/pipermail/pykde/2003-October/006212.html
class _qtEvent:
_qtEventDict = {
0: "None",
12: "Paint",
13: "Move",
14: "Resize",
15: "Create",
16: "Destroy",
17: "Show",
18: "Hide"
}
def types(self):
return self._qtEventDict.keys()
def which(self, t):
try:
if t in self._qtEventDict.keys():
return self._qtEventDict[t]
except:
return "Unknown";
qte = _qtEvent()
class TestCanvas(QCanvas):
def __init__(self, parent, *args):
QCanvas.__init__(self, *args)
self.parent=parent
self.setDoubleBuffering(0)
## ROTATED TEXT CLASS
class TestTextItem(QCanvasText):
def __init__(self, text, x, y, degree, parent,*args):
QCanvasText.__init__(self,parent,*args)
self.degree=degree
self.parent=parent
self.text=QString(text)
self.x=x
self.y=y
#font debug info
print "Using font-family: ",self.font().family()
qfm = QFontMetrics(self.font())
print "font specs: ",qfm.height(),qfm.width(self.text)
#getting text-bounding-box from fontmetrics
self._bndrect=QRect(0,0,qfm.width(self.text),qfm.height())
#do the rotation and translation
wm = QWMatrix()
wm.rotate(self.degree)
wm.translate(self.x,self.y)
self._bndrect=wm.mapRect(self._bndrect)
print "Inital bounding: ",self._bndrect.left()\
,self._bndrect.top(),self._bndrect.right(),self._bndrect.bottom()
def boundingRect(self):
return self._bndrect
def draw(self, qp):
qp.save()
wm = QWMatrix()
qp.setWorldMatrix(wm.rotate(self.degree))
qp.setWorldMatrix(wm.translate(self.x,self.y))
self.setText(self.text)
QCanvasText.draw(self,qp)
qp.restore()
qp.drawRect(self._bndrect)
class TestCanvasView(QCanvasView):
def __init__(self, *args):
QCanvasView.__init__(self,*args)
def paintEvent(selv,ev):
QFrame.paintEvent(ev)
p=QPainter(self)
p.setClipRegion(ev.region())
for i in self.canvas().canvItems:
canvItems.show()
#just for tracing the event handling
def eventFilter(self, qobj, qev):
if qev.type()==QEvent.Paint:
print "TestCanvasView(QCanvasView) Event:"\
,qte.which(qev.type())
print "repaintRect(x1,y1,x2,y2) ="\
,qev.rect().x(),qev.rect().y()\
,qev.rect().x()+qev.rect().width(),qev.rect().y()+qev.rect().height()
else:
print "TestCanvasView(QCanvasView) Event: "\
,qte.which(qev.type())
return QCanvasView.eventFilter(self,qobj,qev)
class TestClass(QMainWindow):
def __init__(self) :
self.canvItems=[]
QMainWindow.__init__(self)
self.canv=TestCanvas(self,640,480)
self.canvView=TestCanvasView(self.canv,self)
def show(self):
QMainWindow.show(self)
self.canvView.resize(self.width(),self.height())
self.setCentralWidget(self.canvView)
for i in range(5):
item=QCanvasRectangle(0,0,100+5*i,100+5*i,self.canv)
item.show()
self.canvItems.append(item)
item=TestTextItem("Text "+str(i), 100+5*i,5*i, 12*i\
,self.canv)
item.show()
print "TestClass: bdBox:"\
,item.boundingRect().left(),item.boundingRect().bottom()\
,item.boundingRect().right(),item.boundingRect().top()
self.canvItems.append(item)
self.canv.update()
self.canvView.show()
def main(args):
app=QApplication(args)
testObj=TestClass()
app.setMainWidget(testObj)
testObj.show()
app.exec_loop()
if __name__ == "__main__":
main(sys.argv)
___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] eric3 default font can't be changed!
The usual way of changing the default font in eric3 doesn't seem to be working. I select Preferences->Editor->Highlighting Style->Python->Default and then change the font colour or font itself and nothing changes in the editor. Now the weird thing is that I *am* able to change any of the other syntax elements... I can make Keywords appear in orange, or change the font of a Comment Block. It's just the "Default" option which doesn't seem to work. There's one little clue which may help identify exactly what's going wrong. If I change the background colour of the default font then that colour appears in the spaces *between* words. The words themselves don't change font or background colour, but all the spaces around them are recognised and have the new default background colour applied. Any idea what's going on? It's as if the parser isn't recognising the text as "Default", or else the font is being overridden. I'm using Eric 3.6.2 and Qt 3.3.4. BTW, changing the qtconfig fonts doesn't have any affect either. Thanks for your help! Cheers, Solly ___ 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] About problem in open a form into other form
I can't open a Form builded in QtDesigner, into other form too builded in qtdesigner. Ex the code: from qt import * from Form_principal import Form_principal from Form_imagem_Impl import Form_imagem_Impl class Form_principal_Impl(Form_principal): def __init__(self,parent = None,name = None,fl = 0): Form_principal.__init__(self,parent,name,fl) # public slot def fileNew(self): #here the problem figura = Form_imagem_Impl() figura.show() print "Form_principal_Impl.fileNew(): Not implemented yet" # public slot The software just don't open the new dialog! -- --Jefferson Luiz BosaUNIOESTE - Universidade Estadual do Oeste do ParanáBacharelado em Informática (4º Ano)MSN: [EMAIL PROTECTED]Seja Livre, use GNU/Linux e seja feliz! ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] PyQt C API
> This is the inner loop of the rendering code for a custom graph widget. The > optimisation target isnt the PyQt code itself, but rather the next layer up, > which calls PyQt. It will be much more convenient for this C (or C++, or > pyrex) code to call the Qt C++ API directly. Now, I've never touched Pyrex, so my understanding here may be a little wonky. I think you should be able to accomplish the same thing with straight-up SIP, and reduce the number of dependencies to boot. You can implement your code entirely in the .sip file, as well. (See %MethodCode) The sip preprocessor will handle all the generation of type conversion code for you. James ___ 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] Re: QString in PyQt4 - Request for Comments
I heard Michael Thompson said: > No, the goal should be to work away at making QString interacted with > str/unicode more invisibly/naturally - where possible. Yeah, I'd sort of second that. The 'pythonic' way is pretty much duck typing, I think, in this sort of situation. How difficult would it be to wrap QString in a class that would also implement all that str (or unicode) does? Possibly by wrapping QString methods, in fact, for performance. That way, you get something that looks like a str, acts like a str, smells like a str, and really is a QString under the hood. Grooviness. That'd make me Happy(tm). (And just so I know, how far up my butt have I stuck my head there?) Ta ta, -- S. ___ 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
[PyKDE] sender() and PYSIGNALs
Hello, It appears that QObject::sender() returns None when called from a slot invoked through a PYSIGNAL. Is there a way to access the information also for PYSIGNALs? Would it be possible to modify sender() so that it works also for PYSIGNALs? -- Giovanni Bajo ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] eric3, qscintilla and code folding
On Tuesday 18 Oct 2005 14:36, Brad Ralph wrote:
>
> The problem is I seem to be too fussy. When you fold all of the children
> (Ctrl - Click) it becomes a bit annoying to have to unfold the if
> statements and triple quoted strings of any method that you are working in.
> I know that this can be turned off in the settings (so that strings are
> not folded) but then we loose the option to do so if you want to on a case
> by case basis.
>
I thought it might be possible to get a bit closer to what you want if
QScintilla had a "foldChildren" method, so I wrote one. You could use this to
add a "Toggle Child Folds" and "Collapse Child Folds" to eric3's View Menu.
If you also created keyboard shortcuts for these new menu items, it might
make quite a nice improvement to the user interface.
This function should be added to eric3's QScintilla.Editor class:
def foldChildren(self, line, toggle=True):
if toggle:
btnstate = QextScintilla.SCMOD_CTRL
else:
btnstate = QextScintilla.SCMOD_SHIFT
linepos = self.SendScintilla(
QextScintilla.SCI_POSITIONFROMLINE, line, 0)
self.emit(
SIGNAL('SCN_MARGINCLICK(int,int,int)'),
(linepos, btnstate, 2))
(A ctrl+click toggles all the child-folds of a foldable line.
A shift+click expands all the child-folds of a foldable line).
HTH
--
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 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? 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 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 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
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 modularity considerations of our mixed C++/Python environment. I would say it is the exception, rather than the rule. From our perspective, Python unicode <-> QString conversion would be an inconvenience, but not a barrier. Nigel ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] PyQt C API
On Tuesday 18 October 2005 18:02, Phil Thompson wrote: > Or you can use the lower level sipConvertToCpp() which skips some error > checking. Thanks. One other problem is how to get the sipWrapperType pointer A sip generated extension module gets these pointers via api_export_module, but that is documented as a sip-private API. The non-obvious answer (but easy once you know it) is that these sipWrapperTypes are the same objects as stored in qt module python namespace. Thanks again, On Tuesday 18 October 2005 08:54, Giovanni Bajo wrote: > I also think that the performance sensitive parts > shouldn't have anything to do with PyQt in the first place. We use Pyrex > exactly for this purpose, but the parts we optimize are far far far from the > package which imports and uses PyQt. This is the inner loop of the rendering code for a custom graph widget. The optimisation target isnt the PyQt code itself, but rather the next layer up, which calls PyQt. It will be much more convenient for this C (or C++, or pyrex) code to call the Qt C++ API directly. -- 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
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 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
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 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
[PyKDE] Windows version of eric3 won't start.
Hi there. I installed the GPL QT package for windows from the download section of the eric3 homepage and the newest eric3 version 3.7.2 from sf.net. I am running Active Python 2.4.1. Eric throws me an exception when i start eric3.py in the commandline. (eric3.pyw which is started through the icon doesn't print any error messages, so i chose eric3.py) The message is the following: --- C:\Python24\Lib\site-packages\eric3>eric3.py Traceback (most recent call last): File "C:\Python24\Lib\site-packages\eric3\eric3.py", line 23, in ? from Utilities import Startup File "C:\Python24\Lib\site-packages\eric3\Utilities\Startup.py", line 18, in ? import Preferences File "C:\Python24\Lib\site-packages\eric3\Preferences\__init__.py", line 1461, in ? from Shortcuts import readShortcuts, saveShortcuts, exportShortcuts, importS hortcuts File "C:\Python24\Lib\site-packages\eric3\Preferences\Shortcuts.py", line 20, in ? from XML.XMLErrorHandler import XMLErrorHandler, XMLFatalParseError File "C:\Python24\Lib\site-packages\eric3\XML\XMLErrorHandler.py", line 10, in ? from xml.sax.handler import ErrorHandler ImportError: No module named sax.handler C:\Python24\Lib\site-packages\eric3> --- So.. I tried to check this (as a python newbie) by writing a small... from xml.sax.handler import ErrorHandler print "Hello" ... script and check if it would throw a similar error, which it does not. It runs without problems. So, has anyone an idea what might be going wrong during the start of eric on my system? Please enligten me :) cheers... bjoern ___ 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
actual
Re: [PyKDE] segfault using hasattr on a wrappertype class
On Tuesday 18 October 2005 11:12 pm, Giovanni Bajo wrote: > Phil Thompson <[EMAIL PROTECTED]> wrote: > >> behaviour: > > import sip > > isinstance(sip.wrapper, object) > >> > >> True > >> > > issubclass(sip.wrapper, object) > >> > >> True > >> > >> Dunno if it's related to the fix. > > > > Why is it strange? > > It's uncommon for an object to both be an instance *and* a subclass of a > given class. What other object in Python has the same property? isinstance(type([]), object) True issubclass(type([]), object) True isinstance(type(1), object) True issubclass(type(1), object) True ...etc, etc. Phil ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
