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

[J Barchan]

@Phil write:

> I'm happy to change things so they work better. I don't use them myself so
> other people need to come to a consensus about any changes. When I added
> support I tried to get the PyCharm people to comment and/or verify the
> decisions I took but they were completely unresponsive.
>

Gosh, it sounds like you are the author of PyQt --- I am humbled/honored!
And it's very impressive.  I would have "been responsive", but I've only
just started on all things Python/PyQt/PyCharm :)

@Florian wrote:

> 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 ;-)
>

Yes, to my mind it's not PyQt's job to try to protect people from whatever
the Qt C++ functions allow as parameters, it's just to reflect them in
Python.  If it segfaults with None from Python it will segfault with NULL
from C++.  And actually there are plenty of places where Qt does
deliberately specify a QObject& instead of a QObject* argument.  Is it
comprehensive/consistent?  Doubtless not....

Listen, I'm sure you experts have good reasons for the way it is, be it
historical/compatibility, or that Python type annotations are not
necessarily aimed at the same goal as C++ ones.  And I respect that.  As I
said, now that I know the situation and I'm not missing something easy, I
can move forward.  Thanks again for all your responses.



On 22 November 2017 at 10:33, Florian Bruhin <me at the-compiler.org> wrote:

> 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/
>



-- 
Kindest,
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20171122/599681e2/attachment.html>