[PyKDE] Auto-connecting Slots

Andreas Pakulat apaku at gmx.de
Sat Jan 28 11:43:59 GMT 2006

On 28.01.06 12:29:13, Giovanni Bajo wrote:
> Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
> >>> The QtCore.signature() decorator takes a single argument which is,
> >>> in effect, the C++ signature of the method which tells the
> >>> auto-connect
> >>> code which signal to connect. For example...
> >>>
> >>>     @QtCore.signature("on_spinbox_valueChanged(int)")
> >>>     def on_spinbox_valueChanged(self, value):
> >>>         # value will only ever be an integer.
> >>
> >> Notice that naming it "signature" is a namespace violation from
> >> those using "from QtCore import *". OTOH, you shouldn't impose this
> >> code style of prefixing each and every name with the QtModule name:
> >> I personally hate it, and I can't see why Python code should get 3
> >> times more verbose than the corresponding C++ code. Having 'Q' at
> >> the beginning of the word is enough namespace for me and for every
> >> C++ Qt project out there. Specifically, Qt itself does not expose
> >> anything but symbols which begins with "Q" (or fullly-uppercase
> >> macros and similar things).
> >>
> >> I'd really prefer to have it named something like "qtsignature".
> >
> > 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++.

> If Trolltech added a "signature()" function, people would complain.
> Trolltech doesn't use standard C++ namespaces, but they have their own
> namespace: they prefix every class name with uppercase Q, and every
> function name with lowercase q.

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).

> 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).

> So, if you're going to add a PyQt-specific name, please make it follow the
> Trolltech's convention. QtCore.qSignature would surely be better (there are pre
> cedence of global functions named qFooBar in Qt's API).

Huh? When PyQt follows TT naming scheme there _will_ be a clash when TT
introduces a qSignature() and all PyQt4 programs need to change. Using
QtCore.signature() this will probably never happen.


You'll be called to a post requiring ability in handling groups of people.

More information about the PyQt mailing list