[PyKDE] Auto-connecting Slots
rasky at develer.com
Sat Jan 28 11:29:13 GMT 2006
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
>>> code which signal to connect. For example...
>>> 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. 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. 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 *"
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).
> The reason for doing it the way I did was to allow the following...
> def handle_int(self, val):
> def handle_QString(self, val):
> I can't think of a real-world use case for this - but that's your
> job, not mine.
> What I can do is to make the function name optional in the signature,
> so you can use the short version most of the time but you can still
> have the flexibility of the above.
OK, fine by me as long as the repetition isn't necessary (and the decoration
isn't necessary if not for disambiguation).
More information about the PyQt