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

Phil Thompson phil at riverbankcomputing.com
Wed Nov 22 10:26:41 GMT 2017

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.


More information about the PyQt mailing list