[PyKDE] Auto-connecting Slots

[Jim Bublitz]

On Friday 27 January 2006 16:31, 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.
> >
> > See the calculatorform.py example.
>
> 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".

But all you have to do is:

from QtCore import signature

@signature ( ... )
def something ( ... ) :

(unless I'm missing something - I'm not completely up to speed on all of this)

I don't believe Phil is imposing anything as far as coding style beyond what 
Python already requires with methods/functions imported from modules. 
'signature' has to be part of the QtCore module or some other module. The 
alternative to "polluting" the QtCore namespace would be to give signature 
it's own namespace, but I don't think "QtCore.PyQt.signature" or something 
similar is more attractive or intuitive. Where else are you going to import 
it from and how else are you going to specify the module being imported from?

Personally, I'm not sympathetic to users of the "from module import *" 
construct, although I'm sure we all do it at one time or another (although I 
can't think of any place I've used it recently). As they say, "explicit is 
better than implicit", and sooner or later I would bet most people who use 
modules beyond what Python supplies and use 'import *' all over run into name 
clashes. Worse, they can be difficult bugs to track down.

> Also, as others said, replicating the whole signal name really stems out as
> unpythonic. Listing the arguments type could be well enough:
>
> @qtsignature("int")
> def on_spinbox_valueChanged(self, value):
>     # ....
>
> Actually, you might even use the corresponding Python it instead of a
> string:
>
> @qtsignature(int, QString)
>
> or something like that.

As far as the argument name requiring the function name and signature, that's 
consistent with the way signal signatures are specified throughout PyQt and 
PyKDE, eg:

   QObject.connect (self.btnGroup, SIGNAL ("clicked (int)"), self.btnClicked)

I think consistency like that is a Good Thing. It probably allows for some 
common signal handling code in sip, but whether there are other sip 
limitations that make that format preferable I don't know for sure., I expect 
there's more overhead per "emit" given the extra parsing and whatnot that 
would be needed to allow a more "friendly" format. I tend to favor solutions 
that take a little more programmer time initially, but save run time or user 
time, since those occur much more often.

Jim