[PyQt] PyQt/PyCharm/PEP problem with PyQt types

[Florian Bruhin]

On Wed, Nov 22, 2017 at 10:26:41AM +0000, Phil Thompson wrote:
> On 22 Nov 2017, at 10:22 am, Florian Bruhin <me at the-compiler.org> wrote:
> > 
> > On Wed, Nov 22, 2017 at 10:13:24AM +0000, J Barchan wrote:
> >> Technically as I wrote there, one does *not* have to "go through Qt reading
> >> whether a "QObject *" does or does not accept NULL/None, because it
> >> automatically *does*.  As I wrote, if it does *not*, the correct Qt C++
> >> declaration would have been "QObject &", and that was up to the Qt people,
> >> not PyQt to guess.
> > 
> > Qt uses pointers pretty much everywhere in its API, probably for historical
> > reasons.
> > 
> > I don't claim that's a good idea, but it means you can't just pass nullptr
> > (i.e. None) everywhere and expect that to work (or even to not segfault).
> > 
> > Then again, PyQt could probably just mirror that and allow people to shoot
> > themselves in their feet ;-)
> > 
> >> Having said that, I realise we are where we are.  (Unless PyQt wants to
> >> change the declarations at the next release.)  I am concerned about what I
> >> can do moving on.  You guys have clarified to me that I am not "missing
> >> something" which would have solved this neatly.  I now can declare *my own*
> >> function parameters/returns with Union; I am stuck with where a PyQt
> >> function does not do so and so I will get a warning on my calling code, but
> >> at least I know where I am.  So thank you all.
> > 
> > FWIW I've intended for quite some time to introduce more type annotations into
> > my project (qutebrowser). Once I get to that, I plan to maintain to create and
> > maintain type annotations for PyQt which work correctly with mypy at least.
> > 
> > However, it'll probably still take some time until I get to that.
> 
> You won't be able to do that. mypy only works with a subset of Python API patterns and parts of PyQt fall outside of that.

I guess falling back to typing.Any is always an option. Being able to use mypy
to at least check for *some* types being correct trumps not being able to use
it at all, IMHO. It's probably the whole idea behind gradual typing, that you
just check the parts you can easily express in types, and fall back on fully
dynamic/unchecked typing for the rest.

But yeah, that's a different goal than having types which are as accurate as
possible for IDE completion, and it's a shame it's currently not possible to
accomodate both with one set of type files.

Florian

-- 
https://www.qutebrowser.org  | me at 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20171122/5d9262db/attachment.sig>