[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyQt] Type annotations for pyqtSignals
From:       Florian Bruhin <me () the-compiler ! org>
Date:       2018-11-27 10:46:55
Message-ID: 20181127104655.v4whb73iy4fhuvct () hooch ! localdomain
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Mon, Nov 26, 2018 at 10:03:12PM +0000, Phil Thompson wrote:
> On 26 Nov 2018, at 8:44 pm, Florian Bruhin <me@the-compiler.org> wrote:
> > 
> > Hi,
> > 
> > (last one... for today :D)
> > 
> > Where Qt has signals, PyQt's type annotations seem to say it's a normal
> > function - like with QTimer.timeout:
> > 
> >  class QTimer(QObject):
> > 
> >      [...]
> > 
> >      def timeout(self) -> None: ...
> > 
> > Shouldn't signals rather be defined like "timeout: QtCore.pyqtSignal",
> > which presumably also would make PyCharm suggest their
> > .connect/.disconnect method properly?
> 
> Happy to change it if the behaviour is better (you tell me).

For mypy it'd certainly be - I haven't tried with PyCharm yet. Is there
someone using PyCharm here who can explain what currently happens with
PyCharm's autocompletion/errors when trying to connect to a signal?

> However there are cases where a a signal has the same name (but
> different signature obviously) as an ordinary method. Would that also
> work?

I suppose sip knows which signals behave that way? I guess those could
be defined as:

  signalname: Union[QtCore.pyqtSignal, Callable[[args], ret]]

(with args/ret mirroring the signature of the function)

Florian

-- 
https://www.qutebrowser.org | me@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
         I love long mails! | https://email.is-not-s.ms/

["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt


[prev in list] [next in list] [prev in thread] [next in thread]