[PySide] using QProcess to run python function
Frank Rueter | OHUfx
frank at ohufx.com
Fri Jan 24 05:49:54 CET 2014
thanks, and my apologies again for not thinking before posting
On 24/01/14 17:48, Sean Fisk wrote:
> Oh, I see. I just misunderstood. Good luck with it!
>
>
> --
> Sean Fisk
>
>
> On Thu, Jan 23, 2014 at 11:39 PM, Frank Rueter | OHUfx
> <frank at ohufx.com <mailto:frank at ohufx.com>> wrote:
>
> What you are suggesting is exactly how it works. Pyside will
> import the other python module and runs it's main function via one
> extra QThread.
> That function will import other python code, some of which runs
> subprocess on the external program.
> The latter has to report back to PySide and drive the debug output
>
>
>
>
>
>
>
> On 24/01/14 17:30, Sean Fisk wrote:
>> On Thu, Jan 23, 2014 at 10:39 PM, Frank Rueter | OHUfx
>> <frank at ohufx.com <mailto:frank at ohufx.com>> wrote:
>>
>> I might have lead you on a wild goose chase:
>>
>> I have working python code that calls external process (using
>> subprocess.Popen) and now I am writing a UI for it.
>>
>> To get started I wrote a simple UI that connected to one of
>> those external programs directly to establish the frame work
>> for the new code and figure out how to properly handle the
>> external programs stdout and stderr, be able to display
>> things and cancel it from within my UI.
>> After getting all that to work I thought all I have to do is
>> connect to my actual python code rather than directly to the
>> external program, and that is where I assumed QProcess to be
>> able to do this, when instead I shuold simlpy switch to use
>> QThread and reire that to give me access to stdout, be able
>> to cancel it etc.
>> So what I am trying to do is simply this:
>>
>> PySide UI --- calls --> pure python --- calls --> pure python
>> --- calls --> external program
>>
>> With the stdout of external program and the pure python apps
>> being piped into the PySide UI for processing.
>>
>> I assume each of these is in its own process:
>>
>> ||process| | process | | process | | process |
>> PySide UI -> pure Python -> pure Python -> external program|
>>
>> Since creating processes is somewhat expensive, have you
>> considered the following?
>>
>> || process | | process |
>> PySide UI -> pure Python -> pure Python -> external program
>> ^ ^ ^
>> imports imports subprocess|
>>
>> This would be ideal if import is a possibility. Apologies for the
>> crude drawings :)
>>
>>
>>
>> Sorry if I wasted your time :/
>>
>>
>>
>>
>> frank
>>
>>
>>
>>
>> On 24/01/14 16:22, Sean Fisk wrote:
>>>
>>> Are you wanting to use |QProcess| or |QThread| because your
>>> GUI is blocked (aka frozen, not responding)?
>>>
>>>
>>>
>>> --
>>> Sean Fisk
>>>
>>>
>>> On Thu, Jan 23, 2014 at 10:06 PM, Frank Rueter | OHUfx
>>> <frank at ohufx.com <mailto:frank at ohufx.com>> wrote:
>>>
>>> Actually, it's dawning on me that QProcess may be the
>>> wrong thing to use here, I guess I should consider using
>>> QThread instead, seeing all the code I need to run is
>>> Python anyway!?
>>> I was just experimented with QProcess running the
>>> external programs directly for testing so I kinda got
>>> stuck in thinking this is the way to go (since I got it
>>> all wired up to my UI already).
>>>
>>>
>>>
>>>
>>>
>>> On 24/01/14 15:42, Frank Rueter | OHUfx wrote:
>>>> Thanks Sean and Ryan,
>>>>
>>>> I'm still not quite clear on how this ties into
>>>> QProcess.start()
>>>> I do have a if __name__ ... block in the script in
>>>> question.
>>>> An example would certainly be awesome, but if it's less
>>>> hassle, explaining how your and Ryan's advise helps use
>>>> QProcess on a python module might already suffice.
>>>> Maybe a simlpe example says it all though?!
>>>> I'm not using python 3 btw
>>>>
>>>> Thanks guys for your help!!
>>>>
>>>> frank
>>>>
>>>> On 24/01/14 15:33, Sean Fisk wrote:
>>>>>
>>>>> Hi Frank,
>>>>>
>>>>> You should definitely avoid calling Python as a
>>>>> subprocess if you can. As far as Ryan’s example, I
>>>>> agree with the |if __name__...| but I think that using
>>>>> the |imp| module is a bit overkill. I would recommend
>>>>> using Setuptool’s |entry_points| keyword
>>>>> <http://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation>.
>>>>> Or distutils’ |scripts| keyword
>>>>> <http://docs.python.org/2/distutils/setupscript.html#installing-scripts>,
>>>>> if you must.
>>>>>
>>>>> An example of a well-known Python package which does
>>>>> this is Pygments
>>>>> <https://bitbucket.org/birkenfeld/pygments-main>,
>>>>> which has a large “library” component but also comes
>>>>> with the |pygmentize| command-line script. The
>>>>> Pygments codebase is pretty large, so if you would
>>>>> like me to whip up a simpler example I’d be glad to do so.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --
>>>>> Sean Fisk
>>>>>
>>>>>
>>>>> On Thu, Jan 23, 2014 at 9:17 PM, Frank Rueter | OHUfx
>>>>> <frank at ohufx.com <mailto:frank at ohufx.com>> wrote:
>>>>>
>>>>> Sorry if I'm being thick, but I'm not quite
>>>>> understanding how this helps to connect a python
>>>>> function to qprocess?! All your code does is
>>>>> execute the script, right?!
>>>>> I can already call myscript.main() straight up,
>>>>> but maybe I'm missing the point as I'm unfamiliar
>>>>> with the imp module.
>>>>>
>>>>> Let me elaborate a little bit more:
>>>>> myscript.main() calls a bunch of other python
>>>>> scripts that (directly or through other scripts
>>>>> again) execute external programs to do some
>>>>> conversion work. Those external programs spit out
>>>>> their progress to stdout which I can see fine when
>>>>> I run myscript.main() manually in a python terminal.
>>>>>
>>>>> Now I need run myscript.main() via QProcess and
>>>>> grab stdout to do be able to show a progress bar
>>>>> as well as show stdout and stderr in a debug
>>>>> window inside my QT code.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> frank
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 24/01/14 14:58, Ryan Gonzalez wrote:
>>>>>> If you put an "if __name__ == '__main__'" and a
>>>>>> main functions, you could always import the
>>>>>> script from the GUI frontend. Example:
>>>>>>
>>>>>> myscript.py
>>>>>>
>>>>>> def main(argv):
>>>>>> do_cool_stuff()
>>>>>> return 0
>>>>>>
>>>>>> if __name__ == '__main__':
>>>>>> sys.exit(main(sys.argv))
>>>>>>
>>>>>> mygui.py(Python 2):
>>>>>>
>>>>>> import imp
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> main = imp.load_module('myscript',
>>>>>> *imp.find_module('myscript'))
>>>>>>
>>>>>> main.main(my_argv)
>>>>>>
>>>>>> mygui.py(Python 3):
>>>>>>
>>>>>> import importlib.machinery
>>>>>>
>>>>>> main =
>>>>>> importlib.machinery.SourceFileLoader('myscript',
>>>>>> 'myscript.py').load_module('myscript')
>>>>>>
>>>>>> main.main(my_argv)
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 23, 2014 at 7:48 PM, Frank Rueter |
>>>>>> OHUfx <frank at ohufx.com <mailto:frank at ohufx.com>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I got a little code design question:
>>>>>>
>>>>>> I have a python script that does a lot of file
>>>>>> processing/converting/uploading etc and I'd
>>>>>> like to write a decent
>>>>>> interface for it now.
>>>>>> The main goal is to be able to show the user
>>>>>> detailed info about the
>>>>>> current step and progress as well as clean up
>>>>>> properly in case the whole
>>>>>> thing is cancelled.
>>>>>>
>>>>>> My existing python code needs to stay
>>>>>> independent of QT so any
>>>>>> application that supports python can use it.
>>>>>> I am wondering now how to best connect the
>>>>>> python script and the PySide
>>>>>> code. Should I just run the script as an
>>>>>> argument to the python
>>>>>> interpreter like I would with any other
>>>>>> program? E.g.:
>>>>>>
>>>>>> process = QtCore.QProcess(self)
>>>>>> process.start(<path_to_python>,
>>>>>> <path_to_python_script>)
>>>>>>
>>>>>> As simple as this seems, it feels odd to use
>>>>>> python to call itself as an
>>>>>> external program.
>>>>>>
>>>>>>
>>>>>> I'm happy to go that way but am curious how
>>>>>> others are doing this?!
>>>>>>
>>>>>> Cheers,
>>>>>> frank
>>>>>>
>>>>>> _______________________________________________
>>>>>> PySide mailing list
>>>>>> PySide at qt-project.org
>>>>>> <mailto:PySide at qt-project.org>
>>>>>> http://lists.qt-project.org/mailman/listinfo/pyside
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ryan
>>>>>> If anybody ever asks me why I prefer C++ to C, my
>>>>>> answer will be simple: "It's
>>>>>> becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I
>>>>>> don't think that was nul-terminated."
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PySide mailing list
>>>>> PySide at qt-project.org <mailto:PySide at qt-project.org>
>>>>> http://lists.qt-project.org/mailman/listinfo/pyside
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PySide mailing list
>>>> PySide at qt-project.org <mailto:PySide at qt-project.org>
>>>> http://lists.qt-project.org/mailman/listinfo/pyside
>>>
>>>
>>> _______________________________________________
>>> PySide mailing list
>>> PySide at qt-project.org <mailto:PySide at qt-project.org>
>>> http://lists.qt-project.org/mailman/listinfo/pyside
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20140124/9aeafe0b/attachment.html>
More information about the PySide
mailing list