I have been learning Python2.7 for a little bit now. I'm using Windows 7 64 bit BTW. I started learning GUI's and have been trying to use wxpython and IDLE for this. So I type out some code:
import wx
app = wx.App()
win = wx.Frame(None)
win.Show()
app.MainLoop()
I run the program, and the window pops up, but the blue doughnut is there. I try to close the window, and it says that pythonw.exe is not responding. Another window pops up about wxpython. It says:
wxPython stdout/stderr(Not Responding)
Traceback (most recent call last):
**IDLE Internal Exception:
File "C:\Python27\lib\idlelib\run.py", line 93, in main
seq, request = rpc.request_queue.get(block=True, timeout=0.05)
File "C:\Python27\lib\Queue.py", line 177, in get
self.not_empty.wait(remaining)
File "C:\Python27\lib\threading.py", line 263, in wait
_sleep(delay)
typeError: 'int' object is not callable
What is wrong and how do I fix it?
Thanks.
The crash is most likely happening at the point when you try and start the event loop. See this bug report: http://bugs.python.org/issue989712
Seems someone else has gone as far to try and create an extension to handle this ability: http://idlex.sourceforge.net/extensions.html
Basically, don't do this from IDLE. Write a script and run it from the shell or the script directly if in windows, by naming it with a .pyw extension and double clicking it. There is apparently a conflict between IDLE's own event loop and the ones from GUI toolkits.
It seems that something might be polluting variables in the threading library, it looks like _sleep variable is being overwritten with an int value; in which case _sleep(x) will not work since _sleep is an int and ints are not callable.
It may be in your client code or in some framework code or libraries you are importing. Is that all of the code?
Try running this code from a plain python terminal, not from an IDE like IDLE.
Related
I have a very very specific problem.
I am trying to figure out a way to embed an HTML brower in my app, in order to show some generated HTML content with included javascript.
I tried to do it with wx.html2, but the javascript part just seems to not work.
So I decided to give a try to CEFPython by taking example of the provided wxPython.py demo.
At first, it worked great in the UI I designed.
BUT, the problem is that this UI is intended to be called from another application, as a sort of "plug-in UI". And when launching my wxPython UI from this application, it crashes as soon as cef is initialized (through:
sys.excepthook = cef.ExceptHook
settings = {
"debug": True,
"log_severity": cef.LOGSEVERITY_INFO,
"log_file": "debug.log",
}
cef.Initialize(settings=settings)
app = CefApp(False)
app.MainLoop()
del app
cef.Shutdown()
I keep getting this error:
Python exception: AttributeError
'module' object has no attribute 'argv'
Traceback (most recent call last):
File "<string>", line 248, in <module>
File "<string>", line 36, in main
File "cefpython_py27.pyx", line 626, in cefpython_py27.Initialize
(cefpython_py27.cpp:99136)
AttributeError: 'module' object has no attribute 'argv'
So in the end I have 2 questions:
is there a way with wx.html2 to show HTML content embedding javascript
if not, do you have a clue of what would cause the launched UI to crash? I guess it's a threading matter but I'm not even sure.
Please excuse my english mistakes by the way, as I'm not native.
It seems that your Python environment doesn't behave in a standard manner, you don't provide details how is your Python code called.
The error in cefpython is thrown on this line:
if "--debug" in sys.argv:
application_settings["debug"] = True
https://github.com/cztomczak/cefpython/blob/bbf3597ba47f72db66cf304ab8eb3ccfc3a7130c/src/cefpython.pyx#L631
You have to find out why your Python didn't define "sys.argv". You can easily fix this with code like this: sys.argv = [] before calling cef.Initialize, however you may still encounter other issues due to your non-standard Python environment.
[1]
The code is:
import pywinauto
app = pywinauto.Application()
mainApplication = app.window_(title_re = ".*Environment.*")
mainApplication.Minimize()
mainApplication.Edit.SetText("test", with_spaces=True)
mainApplication.Edit.SetText("{ENTER}")
[2]
The output is:
File "C:\Python27\lib\site-packages\pywinauto\application.py", line 239, in __getattr__
ctrls = _resolve_control(self.criteria)
File "C:\Python27\lib\site-packages\pywinauto\application.py", line 754, in _resolve_control
raise e.original_exception
WindowNotFoundError
Note: If I use 'TypeKeys' method I do not encounter any problem, but I want to write in an app. even if focus is not set on it.
Unfortunately cmd.exe has no any controls inside the window. So you cannot send WM_SETTEXT message to it. That's why SetText isn't working. And it will never work for cmd.exe because GUI automation tool is for GUI, not for command line.
Generally you can interact with cmd.exe process through pipes using standard module subprocess (class Popen).
You can try the following:
run cmd.exe through Popen,
Connect(path='cmd.exe') using pywinauto,
call app.Window_().Minimize(),
send keys using p.stdin.write(someInput) where p is a Popen object.
When you're using pipes, there are some pitfalls with potential dead lock of input and output streams.
Here is one method to workaround some issues: Running an interactive command from within python
I am investigating a bug where curses.wrapper does not restore the terminal properly. The issue is shown after a backgrounding/foregrounding sequence.
Consider the following python program saved in myprogram.py:
import curses, subprocess
# Function that does nothing
def f(*args, **kwargs):
pass
curses.wrapper(f)
# Call vi to open a file
subprocess.call("vi /tmp/foo", shell=True)
Steps to repro the issue:
Run the program: python myprogram.py
It starts vi editing the file /tmp/foo
When I hit ctrl-z it brings me back to my shell
When I resume the program with fg
It restarts the editor but the screen is wrong (all black and the editor is not drawn)
Removing the curses.wrapper(f) line makes the program works: the editor is drawn properly when the program is resumed.
I tried multiple things, like replacing the call to curses.wrapper(f) by what it actually does and, the most minimal example (i.e. calling initscr, endwin) leads also to the same issue.
I am running:
zsh 5.0.5, I also tried the latest fish shell version
python 2.7.6
VIM - Vi IMproved 7.3
What am I missing?
This happens to be a bug in curses.wrapper or anything underneath that forgets to restore signal handler to their previous values.
This fixes it:
import curses, subprocess
import signal
# Function that does nothing
def f(*args, **kwargs):
pass
a = signal.getsignal(signal.SIGTSTP)
curses.wrapper(f)
signal.signal(signal.SIGTSTP, a)
# Call vi to open a file
subprocess.call("vi /tmp/oo", shell=True)
The source-code for curses.wrapper does nothing special with signals.
During initialization (such as a call to initscr), the ncurses library adds handlers for these signals: SIGINT, SIGTERM, SIGTSTP, SIGWINCH. For whatever reason (likely because it is an internal detail not directly visible to callers), this is documented mainly in the NEWS file.
Applications which need to add their own signal handler should do this after ncurses' initialization (since ncurses does this only once). Because curses applications can be switched to/from screen-mode, the signal handlers are left active until the program quits. For instance, it would be possible for a Python script to call curses.wrapper more than once (although it probably would not work correctly except with ncurses -- X/Open says that "portable applications must not
call initscr more than once").
Saving and restoring the signal handler state as suggested by #lc2817 will workâbut it is a workaround because it is not elegant. If curses.wrapper were modified to add some state to it, to remember if it was called before, and to save/restore the signal-handlers, the workaround would be unnecessary. To make it really portable, initscr should be called on the first use, and refresh on subsequent uses.
I've got some old Python scripts which used a different version of tkinter than the current systems are equipped with. Back in the old days, a method named _tkinter.createfilehandler() existed and worked. With the current versions this returns with a RuntimeError exception:
Traceback (most recent call last):
File "src/text.py", line 513, in <module>
tkinter.createfilehandler(pipe_r, READABLE, drain_pipe)
RuntimeError: _tkinter.createfilehandler not supported for threaded Tcl
The script I'm trying to get to run is this (shortened version of course):
#!/usr/bin/env python
import os
from Tkinter import *
(pipe_r, pipe_w) = os.pipe()
# ...
def drain_pipe(a, b):
# handle data from pipe_r
# ...
tkinter.createfilehandler(pipe_r, READABLE, drain_pipe)
tk.mainloop()
Is there a simple way to get this running again? I'm sure there is a way to convert the scripts (or maybe write them anew based on a different paradigm), but I'd be happy with a hack to not have to change very much (maybe there's a switch to enable this again somehow) because I've got several such scripts and would prefer not to have to patch a lot.
If tk is a Tk() object, then use tk.createfilehandler instead.
I've been writing a small utility application using Python 3 (the below testcase also works in Python 2, however) and PyQt 4 that uses the code module to spawn a REPL prompt allowing interaction with a Qt window.
Unfortunately I've hit a problem I've been unable to solve: When I exit() the app while code is inside input() (known as raw_input() in Python 2.x), my Linux terminal subsequently no longer echoes typed characters. I.e. the terminal appears to be left in a broken state, presumably due to some escape sequence issued by input().
I've tried a variety of approaches to fix this, from using the curses module and other means to reset the terminal prior to running exit, to trying to emulate the stdin stream to exit by actually handing exit() to input() (unfornunately code.InteractiveConsole.push() does not work that way, as one might think it would), to trying to write my own non-blocking input() using threading, but I've been unable to pull together something working.
Here, here, here and here are discussions of similar problems.
Finally, here is a reduced testcase to demonstrate the problem:
#!/usr/bin/env python3
import code
import sys
from PyQt4.QtGui import QApplication, QWidget
app = QApplication(sys.argv)
app.lastWindowClosed.connect(exit)
widget = QWidget()
widget.show()
code.interact()
For those unfamiliar with (Py)Qt, this will open a blank window, and when it is closed, the connection from app's lastWindowClosed signal will cause a call to the built-in exit() function to happen. This occurs while the code module is executing a call to input() to read from sys.stdin. And here, when I close the window, typing into the terminal afterwards doesn't show any of the types characters.
I'm mainly using Python 3, and the actual app uses Python 3-specific code, but I've tried the testcase in Python 2.7 as well and it shows the same problem.
Try os.system('stty sane'). The stty sane is supposed to reset echo, and some other things apparently.
This is no real solution to the problem, but
if you type "reset" in the terminal after you've closed the app, it goes back to normal.
I had similar issues once when developing a c application that didn't close a pipe correctly.
Maybe something similar is happening here aswell.
The answer from Quentin Engles worked for me too but as a Python neophyte I didn't understand where the stty sane was supposed to go. After some hunting and head scratching I figured out that exit was a reference to the exit() method so I created exiting() and passed a reference to it:
#!/usr/bin/env python3
import code
import sys
from PyQt4.QtGui import QApplication, QWidget
def exiting():
os.system('stty sane')
exit()
app = QApplication(sys.argv)
app.lastWindowClosed.connect(exiting)
widget = QWidget()
widget.show()
code.interact()
I've run in to the same problem using the curses module. Using the other answer on this page, I've sidestepped the problem with import os at the beginning of the program, and then ending the program with os.system('reset').