On 28.01.06 16:35:35, Giovanni Bajo wrote: > Andreas Pakulat <[EMAIL PROTECTED]> wrote: > > >>> A decorator is just a function and needs to reside in a namespace. > >>> While I could put the signature() function in the global namespace, > >>> that would be dumb. > >> > >> You can put it within the QtCore namespace, but please consider that many > >> people *will* use "from QtCore import *", as it's the default way to make > >> the code similar to the C++ counterpart. > > > > Actually making the code _not_ similar to C++ version is the reason for > > me to use PyQt. Else I could just use C++. > > Then you are using the wrong package.
:-) > PyQt design is made to make the code as much similar as possible to > its C++ counterpart. I don't think so, especially not with PyQt4. You can use QList as if it were a python list - at least to some extent. You can handle a QString as if it where a python string or unicode-string. > Otherwise, there is room for *big* changes if we were to make a > Pythonic Qt API (using properties, more pythonic syntax for window > construction, for signal connections and what not). Of course there are limits to how pythonic PyQt4 feels, because its main goal is to provide a wrapper around Qt4 that is as thin as possible and with as little hand-written code as possible. At least that's how I understood it. It's not to provide a Python Version of Qt. Anyway, the statement was that PyQt4 is much more pythonic than a "simple" wrapping around Qt4. That was the case with PyQt3 I think, where you'd have to do a str() for every QString. > > Could you read this again for yourself please? If TT always prefixes a > > "q", then why should they introduce signature()? They will most probably > > introduce qSignature, just as they switched from SIGNAL to qSIGNAL (or > > was it QSIGNAL, just check the changes from 4.0 to 4.1). > > That is exactly my point. I'm saying that Trolltech *is* being consistent > (and it's even fixing mistakes in consistencies which are years old). > Trolltech has its own namespace, which is made of symbols beginning with 'q' > (either uppercase or lowercase). This is why it *is* good practice to use > "from QtCore import *" in your Python code: you still get a "namespace" for > Qt symbols. > > This is also why I'm complaining if PyQt adds a "signature" name in its > module: that *would* pollute my namespace. "pyqtSignature" as suggested by > Phil doesn't. And it doesn't risk to conflict with a future qSignature added > by TT. Missed that side of the medal. Yep, I do agree and actually I don't really mind how the signature-function is called as long as I can do a sed 's/oldname/newname/' on my files :-) > >> This is why I think PyQt is going the wrong way if it starts > >> suggesting to explicitally use QtCore before everything and/or makes > >> it harder for people to use the "from QtCore import *" form. > > > > Actually signature is the only way according to TT naming rules, because > > it will assure that signature is always PyQt specific. > > > > BTW: I do like the naming/module/package scheme of PyQt4 more, than the > > one of PyQt3. I'm mostly using QtCore.<blah> instead of from QtCore > > import *, only classes I need really frequently are importet into the > > current namespace (from QtCore import QString for example). > > Fine. I would hate code which is not consistent with itself like you're > doing, but hey. ?? Why is my scheme non-consistent? I always use QtXXX.QYYY as long as I don't have to type it a 100 times within 1 source file. IIRC I read that this is "common style" in the python tutorial or some such "official" python documentation. > I mostly dislike the packing scheme of PyQt4, but I see where it's coming > from, and as long as I'm allowed to use the "from QtCore import *" without > polluting the global namespace, it's still good. Adding "signature" would be > a serious problem. Again, I do see your point (now) and I do agree, that PyQt4 should not "forbid" the from QtCore import * by using such a general name for a function. Andreas -- Your supervisor is thinking about you. _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
