[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: [PyQt] PyQt/PyCharm/PEP problem with PyQt types
From: J Barchan <jnbarchan () gmail ! com>
Date: 2017-11-22 10:46:44
Message-ID: CABz3M__ske1-ezTySJpV8_B7FHL=P5GOzJbZh6AypYuvVv59OA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
@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@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@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@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
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic