[PyQt] PyQt/PyCharm/PEP problem with PyQt types
jnbarchan at gmail.com
Wed Nov 22 10:46:44 GMT 2017
> 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 :)
> Qt uses pointers pretty much everywhere in its API, probably for historical
> 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
> > >> whether a "QObject *" does or does not accept NULL/None, because it
> > >> automatically *does*. As I wrote, if it does *not*, the correct Qt
> > >> declaration would have been "QObject &", and that was up to the Qt
> > >> not PyQt to guess.
> > >
> > > Qt uses pointers pretty much everywhere in its API, probably for
> > > reasons.
> > >
> > > I don't claim that's a good idea, but it means you can't just pass
> > > (i.e. None) everywhere and expect that to work (or even to not
> > >
> > > Then again, PyQt could probably just mirror that and allow people to
> > > themselves in their feet ;-)
> > >
> > >> Having said that, I realise we are where we are. (Unless PyQt wants
> > >> 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
> > >> 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
> > >
> > > 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
> to at least check for *some* types being correct trumps not being able to
> it at all, IMHO. It's probably the whole idea behind gradual typing, that
> just check the parts you can easily express in types, and fall back on
> dynamic/unchecked typing for the rest.
> But yeah, that's a different goal than having types which are as accurate
> possible for IDE completion, and it's a shame it's currently not possible
> accomodate both with one set of type files.
> 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 --------------
An HTML attachment was scrubbed...
More information about the PyQt