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

J Barchan jnbarchan at gmail.com
Wed Nov 22 10:13:24 GMT 2017

@Florian & @Phil,

Your posts crossed with my last one above.

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.

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.

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

> On Wed, Nov 22, 2017 at 09:38:21AM +0000, J Barchan wrote:
> > Thank you both, for the same solution.  I had noticed the Union[QWidget,
> > None] construct and wondered if that was the only way/what I'm supposed
> to
> > do in Python.  But it raises two questions, *and only solves one of the
> two
> > problems*:
> As mentioned in an earlier reply, there's Optional[QWidget] which is a
> shorthand for that.
> > 1. I am "surprised" at the need to do this from Python every time an
> object
> > might have value None.  It's "cumbersome" compared to the way NULL/0 is
> > handled from C++, where it's always an acceptable value for any Object*
> > parameter/return value.  Do you guys really write that for every place
> None
> > is acceptable?
> Yes, and it's probably the more correct way, because the caller code *has*
> to
> deal with the value being None.
> > 2. The problem is unsolved where a *PyQt* function accepts/returns None.
> > The second example I gave is calling QWidget.setParent(None).  The
> > declaration of this in QtWidgets.pyi is:
> >
> >     def setParent(self, parent: 'QWidget') -> None:
> >
> > Following your solutions, this *ought* to have been:
> >
> >     def setParent(self, parent: typing.Union['QWidget', None]) -> None:
> >
> > But the problem is that it *isn't* defined like that in the .pyi, and I
> > can't help that.  And it's not just that function, it's lots of others
> too
> > which accept or return None, so this issue keeps arising in my calling
> > code.  Was it PyQt's job to recognise this and generate a different
> > declaration or what?  Given where we are, I don't see any way of avoiding
> > the warning when calling such a PyQt function with None, do you?
> Yes, PyQt should use Optional[QWidget] here. However, there's probably no
> way
> for PyQt to know where None is acceptable and where it isn't...
> FWIW last time I looked at PyQt's type definitions, they were mostly
> intended
> for IDE documentation, and not for typechecking - and mypy (probably the
> most
> widely used type checking tool) didn't like the files at all.
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20171122/139af1fa/attachment.html>

More information about the PyQt mailing list