[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Redundant features in python library, PyQt

On 03/02/2018 04:15 PM, jladasky at itu.edu wrote:
> Python's standard library has (to take three examples) threads,
> processes, and  datetime functions. Meanwhile, PyQt has QThread,
> QProcess, and QDateTime.
> Does this redundancy exist for C++ programmers who are programming Qt
> directly, and who may lack a standard C++ library with these
> features?  Are the Python wrappers simply provided for completeness,
> or do these libraries truly function differently?  When writing a
> PyQt application, how does one choose between the standard library
> and the PyQt library
Yes, when using Qt in C++, you'll be using QThread, QProcess, QDateTime,
etc, even though there are equivalents in the C++ standard library. This
is largely because Qt was created long before the C++ standard library
had many of these things.  But it's also because Qt's versions are
tightly integrated with the Qt object and event machinery.  A QThread
sets up the necessary message queues, for example, whereas a STL thread
will not.

When programming in PyQt, you will also want to use the Qt versions of
primitives when they exist. The primary reason is that the Qt versions
integrate with the Qt event-handling machinery.  As Qt is a C++ library,
it's necessary to wrap each and every Qt class with a Python class.
Thus PyQt often really is just C++ with a Python dialect. In other words
often times you'll be using C++ idioms and C++ data structures even
though Python's idioms and versions would be cleaner and more flexible.
This is the price you pay for using a C++ library that's wrapped using
automated tools for use in Python.  So you'll find api calls that return
a QString, for example, when a python string would be preferred.  Or a
QArray when a list would be better.

This is not just a PyQt thing. Any time you have thin wrappers around C
or C++ libraries, the underlying language idioms are going to bleed
through a bit into Python.