[PyKDE] Auto-connecting Slots

[Andreas Pakulat]

On 28.01.06 16:35:35, Giovanni Bajo wrote:
> Andreas Pakulat <apaku at gmx.de> 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.