<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">@Phil write:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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 :)<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">@Florian wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">Qt uses pointers pretty much everywhere in its API, probably for historical<br>
reasons.</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">I don't claim that's a good idea, but it means you can't just pass nullptr<br>
(i.e. None) everywhere and expect that to work (or even to not segfault).<br>
<br>
Then again, PyQt could probably just mirror that and allow people to shoot<br>
themselves in their feet ;-)</div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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 <span style="font-family:monospace,monospace">None</span> from Python it will segfault with <span style="font-family:monospace,monospace">NULL</span> from C++.  And actually there are plenty of places where Qt does deliberately specify a <span style="font-family:monospace,monospace">QObject&</span> instead of a <span style="font-family:monospace,monospace">QObject*</span> argument.  Is it comprehensive/consistent?  Doubtless not....</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 November 2017 at 10:33, Florian Bruhin <span dir="ltr"><<a href="mailto:me@the-compiler.org" target="_blank">me@the-compiler.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Nov 22, 2017 at 10:26:41AM +0000, Phil Thompson wrote:<br>
> On 22 Nov 2017, at 10:22 am, Florian Bruhin <<a href="mailto:me@the-compiler.org">me@the-compiler.org</a>> wrote:<br>
> ><br>
> > On Wed, Nov 22, 2017 at 10:13:24AM +0000, J Barchan wrote:<br>
> >> Technically as I wrote there, one does *not* have to "go through Qt reading<br>
> >> whether a "QObject *" does or does not accept NULL/None, because it<br>
> >> automatically *does*.  As I wrote, if it does *not*, the correct Qt C++<br>
> >> declaration would have been "QObject &", and that was up to the Qt people,<br>
> >> not PyQt to guess.<br>
> ><br>
> > Qt uses pointers pretty much everywhere in its API, probably for historical<br>
> > reasons.<br>
> ><br>
> > I don't claim that's a good idea, but it means you can't just pass nullptr<br>
> > (i.e. None) everywhere and expect that to work (or even to not segfault).<br>
> ><br>
> > Then again, PyQt could probably just mirror that and allow people to shoot<br>
> > themselves in their feet ;-)<br>
> ><br>
> >> Having said that, I realise we are where we are.  (Unless PyQt wants to<br>
> >> change the declarations at the next release.)  I am concerned about what I<br>
> >> can do moving on.  You guys have clarified to me that I am not "missing<br>
> >> something" which would have solved this neatly.  I now can declare *my own*<br>
> >> function parameters/returns with Union; I am stuck with where a PyQt<br>
> >> function does not do so and so I will get a warning on my calling code, but<br>
> >> at least I know where I am.  So thank you all.<br>
> ><br>
> > FWIW I've intended for quite some time to introduce more type annotations into<br>
> > my project (qutebrowser). Once I get to that, I plan to maintain to create and<br>
> > maintain type annotations for PyQt which work correctly with mypy at least.<br>
> ><br>
> > However, it'll probably still take some time until I get to that.<br>
><br>
> 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.<br>
<br>
</div></div>I guess falling back to typing.Any is always an option. Being able to use mypy<br>
to at least check for *some* types being correct trumps not being able to use<br>
it at all, IMHO. It's probably the whole idea behind gradual typing, that you<br>
just check the parts you can easily express in types, and fall back on fully<br>
dynamic/unchecked typing for the rest.<br>
<br>
But yeah, that's a different goal than having types which are as accurate as<br>
possible for IDE completion, and it's a shame it's currently not possible to<br>
accomodate both with one set of type files.<br>
<div class="HOEnZb"><div class="h5"><br>
Florian<br>
<br>
--<br>
<a href="https://www.qutebrowser.org" rel="noreferrer" target="_blank">https://www.qutebrowser.org</a>  | <a href="mailto:me@the-compiler.org">me@the-compiler.org</a> (Mail/XMPP)<br>
   GPG: 916E B0C8 FD55 A072  | <a href="https://the-compiler.org/pubkey.asc" rel="noreferrer" target="_blank">https://the-compiler.org/<wbr>pubkey.asc</a><br>
         I love long mails!  | <a href="https://email.is-not-s.ms/" rel="noreferrer" target="_blank">https://email.is-not-s.ms/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-family:tahoma,sans-serif">Kindest,</span></div><div><span style="font-family:tahoma,sans-serif">Jonathan</span></div></div></div></div></div>
</div>