I have been working with pyplot.imshow() all week.
Everytime I debug and I hit pyplot.imshow(), an image displays. Now, all of a sudden, no image displays until I hit pyplot.show().
What is going on here? What has changed?
Here is my setup:
I was using Pycharm.
I loaded matplotlib, sklearn, numpy, pandas.
I created a couple of classes in a separate file, and was running the classes to produce images in the file in question.
During the production of the images, I had to look up "imshow" (my experience level with python is only a few months). After implementing "imshow", the images appeared when I passed the "imshow" line in a debugging session. That is just the way it behaved.
I used this repeatedly for days. Then, all of a sudden (and I may have closed and reopened Pycharm, I can't remember), the "imshow()" function started intermittently displaying an image (sometimes it did, sometimes it didn't).
So I started adding "show()" beneath the "imshow()" calls...and that worked (sort of). Very soon, however that started working only intermittently. I would pass "show()" during debugging sessions and nothing would show up.
This mysterious behavior just began. I changed zero settings. No one with computer knowledge had any access to the PC (just my parents during the superbowl...).
Whether "imshow()" is supposed to display something or not, "show()" should always work, right? How is it that both of these functions just stopped working as expected, with only a possible IDE restart that I'm reasonably sure didn't happen...(no computer restart)...and no python package installs.
(the only thing I installed was notepadqq...but the functions stopped working properly several hours after that)
I think you may have changed the way you run your script (e.g. from ipython with the --pylab or --matplotlib switches to the standard python interpreter) or have changed version or default mode of ipython.
In any case, if you use pyplot.ion() before calling pyplot.imshow(...), the image should display automatically.
Related
This is my first post on stack overflow so I hope I'm doing it properly.
I am currently working on a Terminal User Interface for python applications. I know that there are many ready-to-use libraries such as npyscreen out there, but I wantend to create one as programming excercice. In particular, I wanted to to play with some architectural patterns to learn them.
All that said, I'm currently facing several problems with python curses library, that I'm using as low level interface to the terminal.
The problems arise when I try to resize my terminal. As you can see from the code (see below), I handle the terminal resizing in the main loop, invoking the getmaxyx()() method of my curses window and redrawing what is on the screen accordingly.
The problem is that the screen seems to flicker when I try to resize the terminal.
Moreover, my "curses application" works fine on MacOS but totally crashes on windows (even after installing windows curses).
To handle that I tried to re-write the low-level interfice by using the blessed library. It solved the windows crashing problem, but the flickering still remains.
I can not figure out what the problem is.
Fore those wishing to help me, here follows the github page of the project: Terminal GUI on GitHub
Thank you in advance.
With curses, there's (at least) 3 things to look for:
ncurses can handle SIGWINCH (PDCurses may not)
some Python configurations interfere with ncurses receiving SIGWINCH. If your program never receives KEY_RESIZE (which it's not checking for...), then it's time to file a bug report for Python to get that fixed.
some programs don't actively read keyboard input (and if KEY_RESIZE isn't read, ncurses won't update the screensize. That would make the program crash.
Okay, so I started a school project where I need to make multiple plots pop up during runtime and each requires an event handler for user input. My main machine is a Mac, and I've got it working without any issue. The problem is that my research lab also has a few linux and windows machines, and I would like to get my program working on them as well. It seems that the underlying culprit is that each operating system uses a different backend for how it plots figures in matplotlib. I'm not a CS student, and thus feel a little unsure how to fix this. Is there a standard backend that windows 10, ubuntu, Mac, etc. that I could hard code into my program to make sure my code runs correctly on all of them?
The main idea of having backends is that you wouldn't need to care about how the plotting is performed and let the backend do everything. That said, you probably wouldn't want to hardcode any specific backend and let matplotlib decide which one to use on each machine.
You also may want to read matplotlib backends - do I care?
There might be some special issues, such that certain things don't work with certain backends, but since there is no information about that given in the question, the general tendency would be not to set any backend at all.
Running on Mac Sierra, the autocompletion in Spyder (from Anaconda distribution), seems quite erratic. When used from the Ipython console, works as expected. However, when used from the editor (which is my main way of writing), is erratic. The autocompletion works (i.e. when pressing TAB a little box appears showing options) for some modules, such as pandas or matplotlib. So writing 'pd.' and hitting TAB, gets the box with options as expected. However, this does not happen with many other objects: for example, after defining a dataframe named 'df', typing 'df.' TAB shows nothing. In the Ipython console, 'df.' TAB would show the available procedures for that dataframe, such as groupby, and also its columns, etc..
So the question is threefold. First, is there any particular configuration that should be enabled to get this to work? I don't think so, given some time spent googling, but just wanna make sure. Second, could someone state what is the official word on what works and what doesn't in terms of autocompletion (e.g. what particular modules do work from the editor, and which ones doesn't?). Finally, what are the technical aspects of the differences between the editor and the Ipython console in the performance of the autocompletion with Spyder? I read something about Jedi vs. PsychoPy modules, so got curious (however, please keep in mind that although I have scientific experience, I am relatively new to computation, so please keep it reasonably simple for an educated but not expert person).
UPDATE: As a side question, it would be great to know why is the autocompletion better in Rodeo (another IDE). It is more new, has way fewer overall options than Spyder, but the autocompletion works perfectly in the editor.
(Spyder developer here)
My answers:
is there any particular configuration that should be enabled to get this to work?
In Spyder 3.1 we added the numpydoc library to improve completions of some objects (like Matplotlib figures and NumPy arrays). If Dataframe completions are not working for you (they are for me), please open an issue in our issue tracker on Github to track and solve this problem.
could someone state what is the official word on what works and what doesn't in terms of autocompletion (e.g. what particular modules do work from the editor, and which ones doesn't?)
The most difficult part is getting completions of definitions when an object is generated by functions or methods developed in C/C++/Fortran and not in Python. I mean, things like
import numpy as np
a = np.array([])
a.<TAB>
As I said, this should be working now for arrays, figures and dataframes, but it doesn't work for all libraries (and most scientific Python libraries are created in C/C++/Fortran and wrapped in Python for speed).
The problem is that the completion libraries we use (Rope and Jedi) can't deal with this case very well because array (for example) can't be introspected in a static way (i.e. without running code involving it). So we have to resort to tricks like analyzing array's docstring to see its return type and introspect that instead.
what are the technical aspects of the differences between the editor and the Ipython console in the performance of the autocompletion with Spyder?
The most important difference is that in the IPython console you have to run your code before getting completions about it. For example, please run this in a fresh IPython console
In [1]: import pandas as pd
...: df = pd.Da<Tab>
and you will see that it won't return you any completions for Da (when it obviously should return Dataframe).
But, after evaluation, it is quite simple to get completions. You can simply run
dir(pd)
to get them (that's what IPython essentially does internally).
On the other hand, Spyder's Editor doesn't have a console to run code into, so it has to get completions by running static analysis tools in your code (like Jedi and Rope). As I said, they introspect your code without running it. While they work very well for pure Python code, they have the problems I described above for compiled libraries.
And trying to evaluate the code you have in the Editor to get completions is usually not a good idea because:
It is not necessarily valid Python code all the time. For example, suppose you left an unclosed parenthesis somewhere, but you want to get completions at some other point. That should work without problems, right?
It could involve a very costly computation (e.g. loading a huge CSV in a Dataframe), so evaluating it every time to get completions (and that's a must because your code is different every time you ask for completions) could consume all your RAM in a blink.
it would be great to know why is the autocompletion better in Rodeo (another IDE)
Last time I checked (a couple of years ago), Rodeo evaluated your code to get completions. However, we'll take a look at what they are doing now to see if we can improve our completion machinery.
Autocompletion works correctly if there are NO white spaces in the project working directory path.
Autocomplete was not working for me at all.
So, I tried Tools -> Reset Sypder to factory defaults and it worked.
I want to use visual for my project. I've used it many times before and everything was just fine, but I recently changed jobs so am using it on a machine that I've never worked on before
The problem is somewhat peculiar: when I run one of the example scripts from /visual/examples everything is just fine. However when I try to run a very simple script:
import visual
visual.sphere(pos=[0.,0.,0.],radius=1.,color=visual.color.red)
it takes a couple minutes to execute. This is completely unacceptable for the project I want to use it for.
I've tried running this sort of scripts from command line and IPython but the behaviour is the same: a visual window appears, Windows tags the window as "not responding" and then, after some painfully long time, the entire scene appears as expected.
This is clearly not a problem with what IDE I use to call visual and I'm seriously clueless about how to solve this. If that's of any importance I'm using a 64 bit Windows (also downloaded 64b visual) and a Python distribution that comes with Anaconda.
An interesting observation: The Python interpreter from which I run the script is not busy, i.e. I can execute other commands in it while the visual scene is not displaying correctly.
Any help or even ideas on what to do to try and resolve this issue would be very much appreciated.
Do you have either a visual.sleep(pause_time) or visual.rate(frequency) line somewhere in your visualization loop? VPython requires one of these two lines to update the animation window.
I would start from scratch with a base python distribution/implementation.
Try downloading first a stock 64-bit Windows Python-2.7.5 : http://python.org/ftp/python/2.7.5/python-2.7.5.amd64.msi
Then download VPython-Win-64 : http://sourceforge.net/projects/vpythonwx/files/6.05-release/VPython-Win-64-Py2.7-6.05.exe/download
If this doesn't work, then it might be an issue with something other than vpython or anaconda.
If you can get it to work properly, then you can isolate the problem to either Anaconda's python implementation or the VPython module itself.
I am running a stand-alone Python v3.2.2/Tkinter program on Windows, not calling any external libraries. Idle has been very helpful in reporting exceptions, and the program has been debugged to the point where none are reported. However, the python interpreter does occasionally crash at non-deterministic times - operations will run fine for a while and then suddenly hang. The crash triggers the standard Windows non-responding process dialog asking if I want to send a crash dump to Microsoft:
"pythonw.exe has encountered a problem and needs to close.
We are sorry for the inconvenience."
Crash reporting in Python says that the interpreter itself rarely crashes. My question is: no matter how many mistakes there are in a python script, is there any way it should in theory be able to crash the interpreter? Since there are no exceptions being reported and the crashes happen at random times, it's hard to narrow down. But if the interpreter is in theory supposed to be crash-proof, then something I'm doing is triggering a bug.
The code (a scrolling strip-chart demonstration) is posted at What is the best real time plotting widget for wxPython?. It has 3 buttons - Run, Stop, Reset. To cause a crash just press the buttons in random order for a minute or so. With no interaction, the demo will run forever without crashing.
Of course, the goal is for something like Python to never crash. Alas, we live in an imperfect world. A more useful question to ask, I think, is "What should I do if Python crashes?". If you want to help make a more perfect world, first make a quick search at the Python issue tracker to see if a similar problem has already been reported and possibly fixed in a newer or as yet unreleased version of Python. If not, see if you can find a way to reproduce the problem with clear directions about steps involved, what OS platform and version, what versions of Python and 3rd-party libraries, as applicable. Then open a new issue with all the details. Keep in mind that Python, like many open source projects, is an all-volunteer project so there can be no guarantee when or if the problem will be more deeply investigated or solved (most issues are resolved eventually) but you can be happy that you have done your part and likely saved someone (maybe many people) time and trouble. If you want other opinions before opening an issue, you could ask about it on the python-list mailing list/news group.
Python isn't indeed 100% crash proof, especially when you using external libraries, which TkInter is.
There is even page dedicated to it: http://wiki.python.org/moin/CrashingPython