We Keep Coding

How to simulate the run button with a command line in Pycharm

I'm working on a script using the PyAutoGUI module. Sometimes the script gets stuck in a while loop because it's looking for pictures/images that are not shown due to connection problems etc. If this happens I want the program to start again from zero, so I want to simulate the play/run-button in Pycharm with a command line. Is this possible?

What it sounds like you want to do is restart your program if it doesnt respond. A similiar question appears to have been posted here: Python help - Need the ability to restart the script when it hangs or automatically set a timer so I would reccommend having a look at that. Simulating the run button in Pycharm might seem like a good idea at first but it is very specific and a bad practice to simulate user actions like that unless there is absolutely no viable alternative.

Thanks to Patel I managed to solve my issue. You can use ctrl+f5 to restart a script so now when I'm stuck in a while loop I'm using this code:
#Click toolbar Pycharm
pyautogui.moveTo(1672,15,1)
pyautogui.click()
#Rerun the script
pyautogui.hotkey("ctrl","f5")

Python GUI using os.system to run python script cause main GUI "Not Responding"

StackOverflow community.
I am writing a python GUI to monitor another program's data in OSX environment and at one point I decide to click one button to open another python script that I wrote. It does work but it also causes a lag problem of the main GUI program as soon as I click the button. For the lag problem I mean the GUI window is "Not Responding" and I need to force quit. The method I use to run the new script is,
def create_html():
os.system('python realtime.py')
My program doesn't have the multiple class structure, just the simple canvas, and framework. I wonder if this is also the problem to cause my program running slow.

The problem is you are using os.system, which is a blocking call. It will not return control to your main code until python realtime.py is done executing and returned.
You need to use a call that will not block the rest of your program, such as subprocess.Popen.
You can also see this QA for further information

Close and update Program Files in Python

So I've tried Googling my problem and looking on SO here, but I can't seem to find anything. Maybe I just really suck at using searches. But anyway here it what I am trying to do.
I have a program written in Python and I am trying to implement a very basic "Update Client" inside of it. The way this "Update Client" is suppose to work, is when the user chooses to update, the main program is closed and all of the files of the program are modified.
The only thing I am trying to figure out right now, is it is possible to close the main thread of a Python Program, using a thread that starts from that main thread? Or should I be structuring my code towards my main program starting a completely separate application when the "Update Client" is meant to be opened?
Thanks for any help.

Writing an active program with wxPython. Where to start?

I spent the last hours trying to get to know wxPython, because I want to write a GUI program. I found some tutorials on that (not too many), but all of them just explain how to add yet another kind of widget, down to fancy things like LED number outputs and mouse gestures (this one e.g. takes it quite far: Another Tutorial). But everything I could find so far does nothing more than create a static GUI, waiting for the user to do something, then execute some handlers and wait again. It took me a while to even find out that wx.App takes a part in all of that, and that you can subclass it.
I want to write a program, that does things without input! The GUI is supposed to be a client that logs in on a server, and when the server sends something, I want the GUI to show what happened. I could not find a single tutorial even mentioning, that such programs exist. How can I write such a thing? How do they integrate with wxpython?
Do I need to span another thread? Is there a way to hook into the MainLoop and have some code executed periodically, that checks for change and then updates some of those fancy GUI things? And is there any page that teaches you, how to do this?

First of all, you should figure out how to do what you want WITHOUT a GUI. In this case, you'll need to figure out how to login to a server. You'll probably need to use something like paramiko for that. See http://www.lag.net/paramiko/
Once you've got that figured out, then you can add it to your GUI. Probably in a button handler so when the user presses a button, it pops up a dialog asking for a user name and password to pass to paramiko to login to the server.
If the server query takes a long time to execute (like say you're querying a database for a huge set of data), then you'll want to run the query in a separate thread. Why? Because that query will block the GUI's main loop and make your app freeze until it finishes. See the following articles for information on wxPython and threads:
http://wiki.wxpython.org/LongRunningTasks
http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/
I wrote up a tutorial on making wxPython talk to a socket server, so you might find that useful: http://www.blog.pythonlibrary.org/2013/06/27/wxpython-how-to-communicate-with-your-gui-via-sockets/
I also have an article on how to make an image viewer, and do CRUD ops to a database on there.

Obscure, repeatable crashes in multi-threaded Python console application using tk

Using tk in my multi-threaded(*) console application causes it to crash without stacktrace, giving the message "Tcl_WaitForEvent: Notifier not initialized Abort trap".
The symptoms were that all my program's functions worked fine, until I brought up the tk window - then the very next operation would cause the crash.
Immediate searching found that Tkinter is not safe with respect to Python threads, so I made sure that I was not calling any Tk functions anywhere other than my main thread. The crashes continued.
I lost several hours because I believed that it was the specific command I was using that crashed the program - but eventually I realized that any keyboard input would crash the program.
After a lot of debugging, I finally boiled it down to a small program that demonstrates the issue, exposing what I believe is a bug or certainly a feature that needs documentation in the Tkinter library.
I was working on this posting I was debugging. I'm going to post it and answer my own question in the hopes that it will prevent the next person from wasting a day on it.
--
(* - Yes, it certainly needs to be multi-threaded. I have a thread for my socket connection, a thread that listens to a mic and finds levels, a thread to drive my serial port and more. In each case, the thing I'm reading on the thread naturally blocks most of the time.)

The solution!
The issue is that tk crashes if you read from Python's raw_input in a different thread from the tk thread!
A small program demonstrating the issue is here. If you run it, it gets keyboard input perfectly happily from the second thread - until you enter the command "tk" when it brings up an empty tk window. You can do whatever you like with that window - until you type in the console window and press return, when the whole program crashes.
Why am I reading from raw_input in a thread that isn't the main thread?
My program is a console application, but I'm controlling a lot of different parts, one of which is the pi3d OpenGL ES 2.0 graphics library which must be updated at or near the frame rate from the main Python thread.
How to work around it?
"Simple" enough - register for tk menu events and just get the keys directly! Except that's a crappy solution, because you have to emulate all those things that the console does for you already - deleting, left and right arrows and that sort of thing. But that's what I'll have to do.
Should the program become a fully-fledged tk application?
But I can't do that - the whole point of this program is that you can run it through a terminal window - often sshing into headless machines. I'm frankly more likely to make it a curses program!
The tk window is a minor part of the whole thing - just a window to show emulated lights when developing if you don't have the hardware hooked up (or don't want to keep flashing yourself in the face). I won't try to bring it up on headless machines, and that's fine.
Is this a bug?
I'm always loathe to attach such a label to software not my own, but I'm hard-pressed to come up with any other description. It causes a crash, and that crash produces no useful information of any type. I consider that Tkinter is somewhat lame for simply crashing when called from different threads, but at least this behavior is documented (if you dig down a little) - in this case, I'm calling a Python built-in, so I have no basis to expect that it will interact with this library at all, and there's no documentation of this problem.
Could there be a workaround?
I'm sort of hoping there will be a work-around - this one-page program was a single item on a long list of features has turned into a full-day head-scratching debugging session and I don't want to have to throw another day at least after this when none of this time is actually producing new features.
The best thing is if the tk team admitted this was a bug and came up with a fix. But I wouldn't expect that at my desktop before a year from now...
So perhaps the real best thing would be if there were some way to get tk to simply ignore the keyboard, and not crash. I did a tiny experiment with tk's "busy" but that didn't work and just doesn't seem to be the right sort of thing.
A little later, I'm now thinking about running the lighting as an independent program, a separate subprocess using Python's Subprocess library, and sending it text commands through stdin. This would be overkill if this were the only problem that was being solved, but in fact
Got it.
Replacing raw_input() with sys.stdin.readline() did the trick - at least in the demo (which I updated). Feel free to download this and experiment with it yourself!
I hope this saves someone else the time.

In my case (as mentioned in the comments under #Tom Swirly's answer) the solution was to switch to a non-interactive backend:
import matplotlib
matplotlib.use('Agg')