[PyKDE] Dropping SIGNAL() and SLOT() in PyQt4?

[Patrick Stinson]

As I wrote to a friend recently, qt has always been more of a good interface
than a chunk of unique functional code. IMO, the reason qt is so successful
is that it defines a standard way  to do all the usual stuff, and that makes
our code easier to read, and easier to understand while writing it. f.ex, I
implemented something like the resource system with pyqt3, but theirs is
much simpler, and a very acceptible way of doing things. also, the

Using something like SIGNAL and SLOT is conceptually and syntactically much
cleaner than templates, and that's what a lot of (most?) people look for.
glib just uses a string for their connections, as in

self.connect('message', self.on_message)

which I consider to be very pythonic. Both pygtk and pyqt offer quite a lot
of improvements over their c/c++ orignals, and I think these improvements
should each be considered. Leaving SIGNAL in as an options sounds like a
good comprimise.

On 2/19/06, David Boddie <david at boddie.org.uk> wrote:
>
> On Sun Feb 19 15:30:53, Giovanni Bajo wrote:
>
> > Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
> >
> > > (In fact I don't see why Qt still needs SIGNAL() and SLOT() - maybe
> > > the speed penalty of the alternative is more an issue at the C++
> > > level.)
> >
> > Nah. There's boost::signal, which is a full-blown signal/slot
> implementation
> > which works totally at compile time and has zero overhead. In fact,
> there is
> > technically *nothing* that moc does which cannot be done with C++ and
> some
> > advanced tecniques. But Trolltech seems to like the separate compilation
> > step more than templates.
>
> Indeed, but see these documents for a more complete discussion:
>
> http://doc.trolltech.com/4.1/templates.html
> http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html
>
> I think one of the motivations for using a preprocessor-based approach is
> the continued lack of support for certain C++ advanced techniques with
> some
> compilers. Nonetheless, the first document aims to provide other
> justifications for using moc.
>
> > > So, what so you think? Is dropping them to much of a cultural change?
> > > (Of course they could also be made optional.)
> >
> > I'm fine with dropping them as long as they're optional.
>
> I also think it's fine to make them optional. Some people might appreciate
> the explicit nature of SIGNAL and SLOT in their code.
>
> I imagine it's still possible to distinguish between signals and slots
> with
> this method, and continue to allow signals to be connected to signals
> without
> ambiguity.
>
> David
>
> _______________________________________________
> PyKDE mailing list    PyKDE at mats.imk.fraunhofer.de
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
>



--
Patrick Kidd Stinson
http://pkaudio.sourceforge.net/
http://pksampler.sourceforge.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20060219/81bd781e/attachment.html