from PyQt5.Qt import *

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

from PyQt5.Qt import *

iMath
I  wrote these import statements in one of my PyQt5 project 
from PyQt5.QtCore import *
from PyQt5.QtGui import *
from PyQt5.QtWidgets import *
from PyQt5.QtNetwork import *
from PyQt5.QtWebSockets import *

but now I could replace all of them with only " from PyQt5.Qt import * ", and the code still work , one example as following 

import sys
# from PyQt5.QtWebEngineWidgets import QWebEngineView
# from PyQt5.QtWidgets import QApplication
from PyQt5.Qt import *
app = QApplication(sys.argv)
browser = QWebEngineView()
browser.load(QUrl('https://www.youtube.com/watch?v=YORWJTOCHu4'))
browser.show()
app.exec_()

any drawback along with the single line import ?





 


_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: from PyQt5.Qt import *

iMath
Sorry , I got my answer from the doc
http://pyqt.sourceforge.net/Docs/PyQt5/Qt.html#PyQt5-Qt



在2018年06月28 13时25分, "Zhao Lee"<[hidden email]>写道:

I  wrote these import statements in one of my PyQt5 project 
from PyQt5.QtCore import *
from PyQt5.QtGui import *
from PyQt5.QtWidgets import *
from PyQt5.QtNetwork import *
from PyQt5.QtWebSockets import *

but now I could replace all of them with only " from PyQt5.Qt import * ", and the code still work , one example as following 

import sys
# from PyQt5.QtWebEngineWidgets import QWebEngineView
# from PyQt5.QtWidgets import QApplication
from PyQt5.Qt import *
app = QApplication(sys.argv)
browser = QWebEngineView()
browser.load(QUrl('https://www.youtube.com/watch?v=YORWJTOCHu4'))
browser.show()
app.exec_()

any drawback along with the single line import ?





 



 


_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: from PyQt5.Qt import *

Kyle Altendorf
In reply to this post by iMath
On 2018-06-28 01:25, Zhao Lee wrote:
> but now I could replace all of them with only " from PyQt5.Qt import *
> "

> any drawback along with the single line import ?

The doc you linked explained the memory cost of importing anything via
the PyQt5.Qt module.  There are additional reasons that from imports are
somewhat risky and * imports are generally fairly questionable.

When you `from x import y` you are making a new name (`y`) referencing
the object referenced by `x.y` at that point in time.  Generally, module
globals (such as `y` in this example) should not be reassigned but it
can and does happen.  Then when you use `y` you will still get the old
object, not the new.

https://repl.it/@altendky/why-not-to-from-import

`from x import *` has the same issue, but additionally people reading
the code don't know where names came from.  With a single `import *`
it's annoying, with two...  we end up having to add diagnostics to the
code and run it ourselves to figure out where the otherwise unknown
variables came from.  Dumping things into the module scope with this
hazards some confusing behavior with some packages like numpy that have
lots of things with fairly 'normal' names in them.  You end up with
collisions and some names being unexpectedly overwritten possibly
depending on the order of imports.

Admittedly, Qt suffers from mostly the opposite namespacing issue in
that you end up triple namespaced because each layer of
PyQt5.QtWidgets.QApplication has the indicative Q in it.  Still, these
problems are generally relevant to `from` and `*` imports.

Cheers,
-kyle
_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: from PyQt5.Qt import *

Christian Tismer
On 28.06.18 13:27, Kyle Altendorf wrote:

> On 2018-06-28 01:25, Zhao Lee wrote:
>> but now I could replace all of them with only " from PyQt5.Qt import * "
>
>> any drawback along with the single line import ?
>
> The doc you linked explained the memory cost of importing anything via
> the PyQt5.Qt module.  There are additional reasons that from imports are
> somewhat risky and * imports are generally fairly questionable.
>
> When you `from x import y` you are making a new name (`y`) referencing
> the object referenced by `x.y` at that point in time.  Generally, module
> globals (such as `y` in this example) should not be reassigned but it
> can and does happen.  Then when you use `y` you will still get the old
> object, not the new.
>
> https://repl.it/@altendky/why-not-to-from-import
>
> `from x import *` has the same issue, but additionally people reading
> the code don't know where names came from.  With a single `import *`
> it's annoying, with two...  we end up having to add diagnostics to the
> code and run it ourselves to figure out where the otherwise unknown
> variables came from.  Dumping things into the module scope with this
> hazards some confusing behavior with some packages like numpy that have
> lots of things with fairly 'normal' names in them.  You end up with
> collisions and some names being unexpectedly overwritten possibly
> depending on the order of imports.
>
> Admittedly, Qt suffers from mostly the opposite namespacing issue in
> that you end up triple namespaced because each layer of
> PyQt5.QtWidgets.QApplication has the indicative Q in it.  Still, these
> problems are generally relevant to `from` and `*` imports.

You are generally very right concerning "from xxx import *".
People should avoid that feature, at least in all scripts.

There is just a single exception that I built explicitly
into our new PySide2 version:

It allows to write "from PySide2 import *".
This is very handy and very clean, because everybody knows
that you will get all the QtXXX modules which are available.

Cheers -- Chris

--
Christian Tismer-Sperling    :^)   [hidden email]
Software Consulting          :     http://www.stackless.com/
Karl-Liebknecht-Str. 121     :     http://pyside.org
14482 Potsdam                :     GPG key -> 0xE7301150FB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023


_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

signature.asc (507 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

how does qApp work in Python? (was Re: from PyQt5.Qt import *)

Kyle Altendorf
On 2018-06-28 08:37, Christian Tismer wrote:
> There is just a single exception that I built explicitly
> into our new PySide2 version:
>
> It allows to write "from PySide2 import *".

Since this just came up recently in #pyqt, how do you handle qApp?  Same
question for PyQt actually.  It didn't seem to be working as expected.  
I also wouldn't expect it to work with the * imports in any case.

     from PyQt5 import QtWidgets

     class ObviouslyNewApp(QtWidgets.QApplication):
         pass

         def abc(self):
             pass

     print(QtWidgets.qApp)
     app = ObviouslyNewApp([])
     print(QtWidgets.qApp)
     print(app)
     print(app.abc)
     print(QtWidgets.QApplication.instance().abc)
     print(QtWidgets.qApp.abc)


Which outputs:

     <PyQt5.QtWidgets.QApplication object at 0x7fa70fd82ee8>
     <PyQt5.QtWidgets.QApplication object at 0x7fa70fd82ee8>
     <__main__.ObviouslyNewApp object at 0x7fa70fd82f78>
     <bound method ObviouslyNewApp.abc of <__main__.ObviouslyNewApp
object at 0x7fa70fd82f78>>
     <bound method ObviouslyNewApp.abc of <__main__.ObviouslyNewApp
object at 0x7fa70fd82f78>>
     Traceback (most recent call last):
       File "x.py", line 15, in <module>
         print(QtWidgets.qApp.abc)
     AttributeError: 'QApplication' object has no attribute 'abc'

It seems that qApp would have to be a special attribute of the module or
just be made callable instead to work properly in Python.  For
reference, here's (one of?) the C++ macro definition(s).

https://github.com/qt/qtbase/blob/a37dd93defd91b79fb6730d0ff0515a66a0d3972/src/widgets/kernel/qapplication.h#L70

     #define qApp (static_cast<QApplication
*>(QCoreApplication::instance()))

Cheers,
-kyle
_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt
Reply | Threaded
Open this post in threaded view
|

Re: how does qApp work in Python? (was Re: from PyQt5.Qt import *)

Christian Tismer
On 28.06.18 14:52, Kyle Altendorf wrote:

> On 2018-06-28 08:37, Christian Tismer wrote:
>> There is just a single exception that I built explicitly
>> into our new PySide2 version:
>>
>> It allows to write "from PySide2 import *".
>
> Since this just came up recently in #pyqt, how do you handle qApp?  Same
> question for PyQt actually.  It didn't seem to be working as expected. 
> I also wouldn't expect it to work with the * imports in any case.
>
>     from PyQt5 import QtWidgets
>
>     class ObviouslyNewApp(QtWidgets.QApplication):
>         pass
>
>         def abc(self):
>             pass
>
>     print(QtWidgets.qApp)
>     app = ObviouslyNewApp([])
>     print(QtWidgets.qApp)
>     print(app)
>     print(app.abc)
>     print(QtWidgets.QApplication.instance().abc)
>     print(QtWidgets.qApp.abc)
>
>
> Which outputs:
>
>     <PyQt5.QtWidgets.QApplication object at 0x7fa70fd82ee8>
>     <PyQt5.QtWidgets.QApplication object at 0x7fa70fd82ee8>
>     <__main__.ObviouslyNewApp object at 0x7fa70fd82f78>
>     <bound method ObviouslyNewApp.abc of <__main__.ObviouslyNewApp
> object at 0x7fa70fd82f78>>
>     <bound method ObviouslyNewApp.abc of <__main__.ObviouslyNewApp
> object at 0x7fa70fd82f78>>
>     Traceback (most recent call last):
>       File "x.py", line 15, in <module>
>         print(QtWidgets.qApp.abc)
>     AttributeError: 'QApplication' object has no attribute 'abc'
>
> It seems that qApp would have to be a special attribute of the module or
> just be made callable instead to work properly in Python.  For
> reference, here's (one of?) the C++ macro definition(s).

Yes, I know that problem, and I worked quite heavily on it.

Not sure whether I was a bit too painstaking, but I thought
to mimic a macro as far as possible in Python.

Therefore, qApp is a singleton object which can be reached
as an attribute of Q*Application, but also as a member of the
__builtins__ entries, so you can simply write "qApp" and it will
give you what you expected.

No idea if PyQt wants to go this route, on better avoid this
macro completely. I was just curious how far it goes, but
probably won't write that again :-)

Cheers -- Chris

--
Christian Tismer-Sperling    :^)   [hidden email]
Software Consulting          :     http://www.stackless.com/
Karl-Liebknecht-Str. 121     :     http://pyside.org
14482 Potsdam                :     GPG key -> 0xE7301150FB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023


_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

signature.asc (507 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: how does qApp work in Python? (was Re: from PyQt5.Qt import *)

Christian Tismer
On 28.06.18 15:42, Christian Tismer wrote:

> On 28.06.18 14:52, Kyle Altendorf wrote:
>> On 2018-06-28 08:37, Christian Tismer wrote:
>>> There is just a single exception that I built explicitly
>>> into our new PySide2 version:
>>>
>>> It allows to write "from PySide2 import *".
>>
>> Since this just came up recently in #pyqt, how do you handle qApp?  Same
>> question for PyQt actually.  It didn't seem to be working as expected. 
>> I also wouldn't expect it to work with the * imports in any case.
Addendum:
Yes, it works with (and without) "from PySide2 import *" because that
is unrelated:
Things which are added to __builtins__ are always found without
any extra import. It is sufficient to import any PySide2 module.

Cheers -- Chris
--
Christian Tismer-Sperling    :^)   [hidden email]
Software Consulting          :     http://www.stackless.com/
Karl-Liebknecht-Str. 121     :     http://pyside.org
14482 Potsdam                :     GPG key -> 0xE7301150FB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023


_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

signature.asc (534 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: from PyQt5.Qt import *

iMath
In reply to this post by Kyle Altendorf
You are absolutely right on the `import *` relevant issue .
I also agree with the "Importing Objects" part of book Rapid GUI Programming with Python and Qt: The Definitive Guide to PyQt 
https://books.google.com/books?id=9oRa4WJLlGkC&lpg=PP1&pg=PT33#v=onepage&q&f=false

I choose to use the `import *` style in PyQt for the sake of brevity, and use the plain import syntax for other modules .



在2018年06月28 19时27分, "Kyle Altendorf"<[hidden email]>写道:

On 2018-06-28 01:25, Zhao Lee wrote:
> but now I could replace all of them with only " from PyQt5.Qt import *
> "

> any drawback along with the single line import ?

The doc you linked explained the memory cost of importing anything via
the PyQt5.Qt module.  There are additional reasons that from imports are
somewhat risky and * imports are generally fairly questionable.

When you `from x import y` you are making a new name (`y`) referencing
the object referenced by `x.y` at that point in time.  Generally, module
globals (such as `y` in this example) should not be reassigned but it
can and does happen.  Then when you use `y` you will still get the old
object, not the new.

https://repl.it/@altendky/why-not-to-from-import

`from x import *` has the same issue, but additionally people reading
the code don't know where names came from.  With a single `import *`
it's annoying, with two...  we end up having to add diagnostics to the
code and run it ourselves to figure out where the otherwise unknown
variables came from.  Dumping things into the module scope with this
hazards some confusing behavior with some packages like numpy that have
lots of things with fairly 'normal' names in them.  You end up with
collisions and some names being unexpectedly overwritten possibly
depending on the order of imports.

Admittedly, Qt suffers from mostly the opposite namespacing issue in
that you end up triple namespaced because each layer of
PyQt5.QtWidgets.QApplication has the indicative Q in it.  Still, these
problems are generally relevant to `from` and `*` imports.

Cheers,
-kyle


 


_______________________________________________
PyQt mailing list    [hidden email]
https://www.riverbankcomputing.com/mailman/listinfo/pyqt