机械唯物主义 : linjunhalida wrote:
> In my opinion,
> app = QApplication(sys.argv) >> app = QApplication()
>
> hides the detail of sys.argv may cause problem, and hard to debug.
>
> I think
> app = QApplication([]) >> app = QApplication()
> may better.
Good point, but on the other hand the C++ Qt documentation seems to strongly
imply that you really should pass the true argc and argv: they require that
argc>0, so you can't just pass NULL for argv. To avoid that you would have to
do something a bit hackish like:
int main(int argc,char**argv) {
int fake_argc = 1; // we need to declare a variable as it is passed by
reference
QApplication app(fake_argc, argv);
So I think that what they had in mind was to strongly discourage not passing
the true argv, because on some platforms it's important to be able to pass
arguments to Qt (such as -display on X11).
But it's true that a plain QApplication() constructor can look a bit too
innocuous.
On the other hand, what I think are the two best solutions
# "with" method
with QApplication: # note the lack of () as we don't provide a default
constructor
...
and
# "decorator" method
@QMainFunction
def main():
...
main()
are much clearer about the fact that Qt takes control at this point and will do
various low-level initializations, which may include parsing sys.argv.
> for myself,
> - I do not care about what exec_() returns for mainwindow,
> - and I don't think hide sys.exit in execute is a good idea: people
will confuse if the code after execute isn't run.
Perhaps I should have put the problem this way: currently, there are two ways
of exiting a PySide app. One is the Qt way, QCoreApplication.exit, and the
other is the Python way, sys.exit.
But, a major problem is that if the programmer is incorrectly expecting the app
to terminate only with sys.exit, he could forget to correctly handle the value
returned by app.exec_(), and any error value thrown by QCoreApplication.exit
will be ignored.
So my proposal is to simply translate all QCoreApplication.exit calls into
sys.exit so that the programmer only has to deal with one unified system. And
since Python provides an easy way of catching SystemError if needed, this is
not a problem.
If we want to distinguish between QCoreApplication.exit and sys.exit instead of
merging them together, it's even possible to subclass SystemError and to raise
this subclass instead of SystemError.
For the purpose of backward-compatibility, this translation would not occur
with app.exec_() but only with app.execute().
> any way, you can write this kind of code for yourself, create a
> QApplication wrapper..
You're missing the point: obviously I'm not complaining about any missing
functionality, the point is just to make it easier, fool-proof and better
adapted to Python.
I would like to add that the decorator method does have one drawback, mainly
that because main() will already have stopped running when the bulk of the
program executes, it can't catch exceptions, so you would need another function
to do the catching. The "with" method doesn't have this drawback.
Cheers,
Farsmo
_______________________________________________
PySide mailing list
PySide@lists.openbossa.org
http://lists.openbossa.org/listinfo/pyside
