I'm embedding iPython shell in a Django script (with development server, e.g. runserver at localhost) like this:
...
from IPython.Shell import IPShellEmbed
ipshell = IPShellEmbed()
ipshell()
...
which gives me interactive shell at the desired place. Now, if modify the source code, Django automatically reloads, probably without correctly quitting iPython shell, and "breaks" my terminal emulator (xterm, konsole) - text becomes invisible, etc. (same effect if iPython running inside Django is terminated with Ctrl+d).
Any suggestions as what could be causing this? (I'm probably using iPython in a wrong way, but who knows).
I cannot answer the question why it's going wrong, but I can tell you how to recover from it: quit the debugging server and give the reset command.
Another way to prevent this from happening is to use the --reload switch on the runserver command. This means that Django will not reload after a change, but it also doesn't break your debugger.
This issue is already fixed: http://code.djangoproject.com/ticket/15565
Thanks Django.
Related
I was following along this tutorial on Django until minute 28:36 when the teacher uses a quick shortcut that appeared as ^C(trydjango) $ on the terminal, allowing him to continue typing to makemigrations after he did runserver.
When I try to type in the terminal after python manage.py runserver, the enter button does not submit the commands, but rather enters down to a newline making me stuck. I am unsure how to continue with the tutorial, so any help would be greatly appreciated.
allowing him to continue typing to makemigrations after he did runserver.
That is not the case. He used Ctrl+C (this is the origin of the ^C to stop the server).
Ctrl+C [wiki] is a seqeuence that will raise a SIGINT signal [wiki] to the process that is running, telling it you want it to interupt. Most processes will then try to stop running (for example after doing some tasks to store the state of the program).
In a lot of terminals however, you can make use of multiple tabs where one of the tabs is used to run the server whereas others are used to check files, the database, etc. On the Mac OS X Terminal Emulator, you can use ⌘ + T, whereas on LXTerminal and a lot of other Linux terminal emulators, you can use Ctrl + Shift + T.
Hows it going,
You just need to open a second terminal, and leave that one running.
If youre using VSCode or PyCharm then you can just click the plus beside the terminal at the bottom and add another.
First of all, I'm quite new at Python, Stackoverflow and programming in general so please forgive any formal errors I might have made as I'm still trying to grasp many of the required conceptual programming protocols.
Here's the issue:
I'm trying to work around a specific, seemingly simple problem I've been having when using Tkinter: Whenever I'm fiddling with some code that confuses me, it generally takes many attempts until I finally find a working solution. So I write some code, run it, get an error, make some changes, run it again, get another error, change it again... and so on until a working result is achieved.
When the code finally works, I unfortunately also get additional Tkinter main windows popping up for every failed run I've executed. So if I've made, say, 20 changes before I eventually achieve working code, 20 additional Tkinter windows pop up. Annoying...
Now, I was thinking that maybe handling the exceptions with try/except might avoid this, but I'm unsure how to accomplish this properly.
I've been looking for a solution but can't seem to find a post that addresses this issue. I'm actually not really sure how to formulate the problem correctly... Anybody has some advice concerning this?
The following shows a simple but failed attempt of how I'm trying to circumvent this. The code works as is, but if you make a little typo in the code, run it a couple of times, then undo the typo and run the code again, you'll get multiple Tkinter windows which is what I'm trying to avoid.
Any help is, of course, appreciated...
(btw, I'm using Python 2.7.13.)
import Tkinter as tk
class App(tk.Frame):
def __init__(self, parent):
tk.Frame.__init__(self)
self.root = parent
self.canvas = tk.Canvas(self)
self.canvas.pack(expand=1,fill='both')
self.bindings()
def click(self,e):
print 'clicked'
def bindings(self):
self.root.bind('<1>',self.click)
def main():
root = tk.Tk()
app = App(root)
app.pack()
root.mainloop()
if __name__ == '__main__':
try:
main()
except:
print 'Run failed...'
Alright, great. The issue has indeed nothing to do with Tkinter or Python but with the IDE itself. Thank you Ethan for pointing that out.
PyScripter has several modes or engines. I've been running scripts with its internal engine which is faster but does not reinitialize with every run. I believe this causes the problem. The remote engine, on the other hand, does reinitialize with every run. This avoids the failed run popups.
A more in-depth explanation from the PyScripter manual below:
Python Engines:
Internal
It is faster than the other options however if there are problems with
the scripts you are running or debugging they could affect the
reliability of PyScripter and could cause crashes. Another limitation
of this engine is that it cannot run or debug GUI scripts nor it can
be reinitialized.
Remote
This the default engine of PyScripter and is the recommended engine
for most Python development tasks. It runs in a child process and
communicates with PyScripter using rpyc. It can be used to run and
debug any kind of script. However if you run or debug GUI scripts you
may have to reinitialize the engine after each run.
Remote Tk
This remote Python engine is specifically created to run and debug
Tkinter applications including pylab using the Tkagg backend. It also
supports running pylab in interactive mode. The engine activates a
Tkinter mainloop and replaces the mainloop with a dummy function so
that the Tkinter scripts you are running or debugging do not block the
engine. You may even develop and test Tkinter widgets using the
interactive console.
Remote Wx
This remote Python engine is specifically created to run and debug
wxPython applications including pylab using the WX and WXAgg backends.
It also supports running pylab in interactive mode. The engine
activates a wx MainLoop and replaces the MainLoop with a dummy
function so that the wxPython scripts you are running or debugging do
not block the engine. You may even develop and test wxPython Frames
and Apps using the interactive console. Please note that this engine
prevents the redirection of wxPython output since that would prevent
the communication with Pyscripter.
When using the Tk and Wx remote engines you can of course run or debug
any other non-GUI Python script. However bear in mind that these
engines may be slightly slower than the standard remote engine since
they also contain a GUI main loop. Also note that these two engines
override the sys.exit function with a dummy procedure.
If I'm on Python 2.7 and I've just started using the Spyder IDE.
On a terminal python version if I do
any(i ==1 for i in [1,2,3,4])
I get the answer
True
While if I do the same in Spyder I get the response
<generator object <genexpr> at 0x3fc8af0>
Why is it doing that? Am I missing a setting or might this be a different version of Python (it says 2.7)
Here's a quote from another related question about Spyder's Python console behavior:
One of Spyder's primary design goals is to make interactive scientific
computing as painless as possible. To facilitate that, by default
Spyder launches a custom-tailored interactive Python session at
startup. It achieves this customization by setting an environment
variable called PYTHONSTARTUP which specifies the path to a script
that will be executed at interpreter startup. You can control this
setting under Preferences...Console...Advanced settings. By default,
Spyder points to scientific_startup.py, which imports a whole host of
scientific modules and functions directly into the main namespace so
that quick, interactive exploration is easy.
As a consequence, the behavior you are experiencing is because you are actually calling the numpy versions of any and all which have been placed directly into the main namespace. To verify this, call
np.any(i ==1 for i in [1,2,3,4])
or
np.all(i ==1 for i in [1,2,3,4])
in the Spyder Python console, and you'll get the same generator objects being returned. By the way, these last two calls magically work because the startup script also does import numpy as np. For more details on what else is imported, type scientific at the Spyder Python console prompt.
Unless I'm going crazy, I didn't have to do this as of a few days ago. For example, changes to HTML files do not require a server restart to take affect, but when I do simple modifications to, say, my views.py file, I need to restart the server. Is this how it is and I'm am actually going crazy, or is there a configuration that needs fixing?
Also, my debugger stopped working at around the same time. I set breakpoints in functions I know should get touched, but when I debug the code, it stops at "manage.py" in the debug tree. I'm wondering if the two problems are related.
I found the answer to this on a random foot note on a blog some where!
In Aptana under preference (or any where else you deal/launch the run server) do this:
Aptana -> Preference -> Pydev -> Interpreter - Python -> "Environment" tab
add a new variable here called:
PYTHONUNBUFFERED = Y
Name = Value ..
vola! it works now no more reloading of the runserver .. or resaving of your py file to trigger a print out.
First of all, I'm using Windows, just to make that clear. I am using cmd.exe to manage runserver and the server runs just fine. However, sometimes, on a seemingly random basis, Django simply stops writing to stdout! The server responds to my requests and everything, but nothing gets printed.
To make it even clearer, I'm not even talking about print in my Django code, so that cannot be the problem. I'm talking about when it prints e.g. GET /someurl HTTP/1.1, yada-yada... Hitting Ctrl+Break and restarting the server doesn't help. However, if I exit the command prompt and start a new one and run the server in that one, it starts working again.
Any ideas about what's going on? This is with Django 1.0.2 final and Python 2.6.2.
Maybe a bit of a stretch,but under Python 2.6 under Linux using the Twisted framework (instead of Django), I had this behaviour occur anytime my application sent a NULL to stdout and stdout was redirected to syslog. I had assumed this was a bug in the twisted framework's syslog implementation, but maybe its something more. Can you tell from either logging or client activity what the last thing it was doing before losing stdout and see if it is a) always in one of a handful of places and 2) if you are sending anything funky out at the time?
Do you assign something to sys.stdout or sys.stderr at some point in your code?
The development server can act weird sometimes, just stop it with ctrl-break then start it again.
One thing you can try, just to be sure that the server itself didn't stop, is do a hard-refresh (ctrl-F5), if it doesn't respond, then the server is actually dead, and you were just seeing the cached version of the page.
This may seem stupid, but did you check the log files? Also, you could make a lot of requests from urllib, or whatever web client you want, and try to reproduce that. Maybe you'll see a pattern as to why this happens.