I have PyCharm Professional Edition 3.5 5.0 configured to
use IPython when possible
and in my Run/Debug Configurations I set
show interpreter afterwards
I use the interactive Interpreter a lot and I really like IPython, but there are some things that I don't like about the way this is handled in PyCharm:
any input() in my programs return empty strings.
Additionally, when an error occurs I can't interact with the Program anymore. (you can when you run a Python program with the -i flag)
There is a lot of space between the last line in the Console and the current line
In IPython the ...: prompt in a code block isn't indented 2 spaces and therefore not aligned to the In [?]: prompt.
When an error occurs I get something like this:
Traceback (most recent call last):
File "C:\Program Files (x86)\PyCharm\helpers\pydev\pydev_run_in_console.py", line 69, in <module>
globals = run_file(file, None, None)
File "C:\Program Files (x86)\PyCharm\helpers\pydev\pydev_run_in_console.py", line 29, in run_file
pydev_imports.execfile(file, globals, locals) # execute the script
File "C:\Program Files (x86)\PyCharm\helpers\pydev\_pydev_imps\_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File "C:/Users/ca/Python/Bundeswettbewerb Informatik/Aufgabe2/Ameisen.py", line 133, in <module>
function_that_caused_error()
I don't need/want to see the traceback from the internals.
When running a file IPython needs to be started which takes some seconds even if I'm not going use the interpreted afterwards. I would like PyCharm to start IPython after the program has ended or when I start debugging (you can start IPython in an interactive console by doing import IPython; IPython.start_ipython()
There are some other minor things that I don't like:
When IPython is started it prints a lot of text to the console. I don't want to see any of it except maybe the version number (you can usually do this with the --no-banner option, but adding it to the interpreter options doesn't work)
when you type something and press Up it replaces what I have written with the last item of my history instead of replacing it with the last item of my history that start with what I have typed. Plain IPython does this.
I would like to have automatic code completion without having to press Ctrl + Space in the console
The "problems" are ordered by importance. Does anybody know how to change some of them? I could stop using IPython which would solve the second , the third and the fourth problem, but the other ones would still persist. All of this behavior (excluding the IPython stuff) is implemented very well in PyScripter.
EDIT:
I have found solutions to the first two problems and the problem with the IPython banner. The source for the PyDev interactive interpreter (which is used by PyCharm) is located, on Windows, in C:\Program Files (x86)\PyCharm\helpers\PyDev (path my vary of course).
So the first problem can be solved by editing the file _pydev_imps/_pydev_execfile.py. Wrap line 18 (exec(compile(contents+"\n", file, 'exec'), glob, loc)) in a try ... except block with the following code as the exception handler import traceback; traceback.print_exc(). This will terminate your Python program if there is an error while letting you interact with the variable afterwards.
Problem 2 can be solved by editing the fire pydev_run_in_console.py. Add this import at the beginning of the file: from pydev_console_utils import StdIn and insert sys.stdin = StdIn(interpreter, host, client_port) after what was line 61 before adding the import.
In order to solve the problem with the banner you have to download the most recent version of the PyDev source here and replace the files pydev_ipython_console and pydev_ipython_console_011 by their newer versions. In the newer version of the first file the __init__ method in line 22 has a argument called show_banner with the default value True. Change this to False.
This is probably not the answer you are searching for, but based on my experience using IPython on InteliJ products ( PyCharm, Ultimate), I don't recommend using their version of IPython. It's full of bugs, outdated and you'll lose precious time fixing problems instead of coding.
Have you tried jupyter notebook? If you installed python with anaconda, it's already installed. To run it, open the terminal and type:
jupyter notebook
If your browser doesn't open automagically, head to http://localhost:8888
Note:
You can automate this process by creating bat or sh script containing the code above inside your project directory, this way it doesn't start on you home dir, which it does by default.
Resources:
How to Install and Use IPython
nbopen project: Open a Jupyter notebook in the best available server
In all honesty, have you simply tried running a newer version of PyCharm and importing your settings? 3.5 is fairly outdated (I'm on 4.5.3 myself, newest version is 5.0) and I believe more support is offered for IPython in the newer versions. https://www.jetbrains.com/pycharm/help/ipython.html. Especially if you are a student, it might not hurt to give it a shot. I know older versions of PyCharm were more buggy than recent releases.
Related
I am fairly new to programming in python. I installed anaconda and am running iPython (the Jupyter qtconsole) v.4.3.0 and python v.3.6 on a Mac. Currently, I am trying to import a module with functions located in my home directory.
I have looked at stackoverflow and python documentation and found that it could be done with:
%run "Users/myUser/python_functions.py"
or
import python_functions
However, when I try both of these approaches, I get prompted to overwrite the file that I am running or importing:
File `python_functions.py` exists. Overwrite (y/[N])?
This is changing the previous file and not getting the functions I want to be imported.
What may explain this, and what can I do to import my module?
this is wrong but leaving it up for shame
import on ubuntu (and I'm guessing many other unix-like OSs including Mac) is a utility that saves any visible window on an X server and outputs it as an image file. You can capture a single window, the entire screen, or any rectangular portion of the screen.
My guess if you are running the import command in your console, and it's about to take a screenshot and save it over an existing file - python_functions
Before you the use the python import command, start a python interpreter:
$ python
>>>import yourfile
edit: on re-reading your question, I'm not so sure about my guess anymore, but leaving it up until you tell me I'm wrong :)
Running Jupyter qtconsole as an interpreter is likely causing the problem in this scenario. Instead using a IDE or command line interpreter will resolve it .
Since anaconda was installed, trying it with the IDE Spyder executes the code just fine without the overwrite prompt. It works on others (e.g PyCharm, Rodeo, etc.) as well.
I have several python scripts which work just fine but one script has (as of this morning) started giving me this error if I try to run it from the bash:
: No such file or directory
I am able to run the 'broken' script by doing python script_name.py and after looking around a bit the general idea that I picked up was that maybe my line ending of the hashbang got changed (silently) so I looked at the line ending of a working script and a broken script via the :set list option in VI as indicated in this question -> View line-endings in a text file
Both files appear to end using the same character (a $) so I am kind of at a loss on how to proceed from here. Specifically, how to actually 'see' the line ending in case the set list was not the right method.
PS: The script is executable and the shebang is in there, I stated that it's just this 1 script that was working fine before the weekend but it started giving me this error as of this morning.
-- edit: --
Running the script through dos2unix does get it working again but I would like to know of any way to visualize the line ending somehow in VI(M) or why Geany somehow converted the line endings in the first place (as I never work on a dos/windows system anyhow).
From the comments above it looks like you have dos line endings, and so the hashbang line is not properly processed.
Line ending style are not shown with :set list in Vim because that option is only used when reading/writing the file. In memory line endings are always that, line-endings. The line ending style used for a file is kept in a Vim per-file option, weirdly called fileformat.
To see/change the line ending style from Vim, you can use the following commands:
:set fileformat
:set ff
It will show dos or unix. You want unix, of course ;-).
To change it quickly you can save the file with:
:w ++ff=unix
Or if you prefer:
:set ff=unix
And then save the file normally.
So see all the gory details just do :help fileformat, :help file-formats and :help fileformats
You can also use the dos2unix command to convert the file format
dos2unix
This helped me to run the python scripts
This normally happens when we open files in windows do changes and save it.
if you open the file locate the ^M characters at the end of every line
Thanks
Personally, I find it kinda wrong using direct path to python interpreter. As you dont use windows platform, you should have program env, usually in /usr/bin (/usr/bin/env). Try using following shebang:
#!/usr/bin/env python
Different distros store python binary in /bin or /usr/bin (or some weird locations), and this one makes your script config-independent (as far as possible, here we have possibility that env is stored elsewhere; still - it is less possible that env is not in /usr/bin than that python is mislocated).
I had similiar problem (if not exactly the same) and that worked for me.
Also, I have both python interpreters (2.7.x and 3.x) installed, so I need to use "python3" argument for env. AFAIR usually distros link different names to different binaries, so "env python" will run python2.7 on my system, "env python3" (also python33, or smth like that) will run p3k, and "env python2" (also python27, etc) will run python 2.7.x. Declaring which version of interpreter should be used seems like a good idea too.
I came across this problem editing my code on Windows, checking it in with git, and checking out and running it on Linux.
My solution was: tell git to Do The Right Thing. I issued this command on the Windows box:
git config --global core.autocrlf true
Modified the files and checked them in; voila, no such problem any more.
As discussed on the Git documentation.
I would like to add a breakpoint to a pydev project. I am using eclipse with the pydev plugin. I am running Windows 7. The file I want to debug is located at C:\cygwin\workspace\project\main.py .
When I attempt to add the breakpoint by double-clicking to the left of the line on which I want the breakpoint, the breakpoint appears to be visually present in the file, but then I get this error when I click debug:
pydev debugger: warning: trying to add breakpoint to file that does not exist: /workspace/project/C:\cygwin\workspace\project\main.py
Note that the file still appears to run fine both in debug and normal run modes. I can also run the file outside the ide by running python main.py.
I was actually able to get this working. I realize I'm using PyCharm, but the solution should be easily adapted since they both use PyDev. The basic problem is that the IDE is expecting windows paths while PyDev is expecting cygwin paths. I found the appropriate places in PyDev to do those conversions.
Here's my setup
configure your project to use a python for cygwin binary (this may not be necessary)
edit Program Files/JetBrains/PyCharm 2.5/helpers/pydev/pydevd.py. This converts the paths sent to the debugger to cygwin paths. Around line 597, where file = NormFileToServer(file) is located, make the following changes
orig_file = file
file = NormFileToServer(file)
if not os.path.exists(file):
file = orig_file.replace('c:/cygwin','')
file = file.replace('\\','/')
file = file.replace(' ','\ ')
file = NormFileToServer(file)
if not os.path.exists(file):
sys.stderr.write('pydev debugger: warning: trying to add breakpoint'\
' to file that does not exist: %s (will have no effect)\n' % (file,))
sys.stderr.flush()
do the same filename conversion a few lines later under the elif cmd_id == CMD_REMOVE_BREAK statement
edit Program Files/JetBrains/PyCharm 2.5/helpers/pydev/pydevd_comm.py. This converts paths sent back to pycharm into windows paths. Around line 549 alter the code to look like this:
myFile = pydevd_file_utils.NormFileToClient(curFrame.f_code.co_filename)
myFile = "C:\cygwin" + myFile
myFile = myFile.replace('/','\\')
Adjust the paths as needed. The big thing that helped me figure this out was to add PYCHARM_DEBUG=True in the environment variables of the PyCharm run/debug configurations.
Hope this saves someone else the 6 hours I spent figuring this out!
Cygwin is not really properly supported in PyDev, thus, you either must work on windows using a python windows distribution or you must work on Linux using a python for linux...
The real issue is that the paths must be translated back and forth at each step when inside cygwin (to make the communication with the IDE)... some initial work has been done on that front, but it didn't go forward...
One approach I didn't really attempt but which could work could be trying to use all within cygwin (i.e.: use PyDev running inside cygwin too: the linux version of java/eclipse/pydev -- not only the python interpreter, that way both would see paths in the same way), but I haven't really tested that setup, so, I'm not 100% certain it'll work.
pydev debugger: warning: trying to add breakpoint to file that does not exist: /vagrant/pytest/C:\Program Files\Git\vagrant\vagrant\pytest\remote.py (will have no effect)
The above error is keeping on occuring to me. I am using eclipse with pydev installed.
INitiualy I configured the PATHS_FROM_ECLIPSE_TO_PYTHON value wrongly but then updated it. But the updated value is not reflecting in the above error but shows old value only.
How to flush the old configurtion PATHS_FROM_ECLIPSE_TO_PYTHON and make the latest value used when executing the file
On my CentOS5 server, I have both Python2.4 and 2.6 (2.4 is required for yum to work). I'm not sure what happened, but suddenly the system gets very confused every time I try to run a file whose modules are loaded into the 2.4 site-packages directory. I checked the PYTHONPATH/sys.path and it looks like everything was overwritten with 2.6 environment data instead.
It didn't used to do this. I simply declared /usr/bin/python or /usr/bin/python26 in the shebang statement at the beginning of the script and it always found the correct modules just fine.
Is there a way for the PYTHONPATH variable to be dynamic and load different paths based on which python interpreter is running?
Otherwise I'm going to have to manually edit the path in every application, which seems like overkill.
It started after installing web.py (which I love, by the way).
Traceback:
As someone commented below, I changed the shebang to be #!/usr/bin/env python for this program:
Traceback (most recent call last):
File "/usr/bin/linkchecker", line 24, in ?
import codecs
File "/usr/lib/python2.6/codecs.py", line 268
return (b"", 0)
^
Another example, trying to use yum:
Traceback (most recent call last):
File "/usr/bin/yum", line 5, in ?
import yum
File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 21, in ?
import os
File "/usr/lib/python2.6/os.py", line 758
bs = b""
^
I've noticed a couple programs not confounded by the b"" syntax, and all of them are programs meant to use 2.4 that are for some reason using 2.6. If I try to make the program use the 2.6 interpreter it is able to understand that syntax, but then can't find any of the other modules (which are in the 2.4 site-packages directory).
I don't know what that syntax is, as they were written into modules which I got from sourceforge, however they were working last week. I am not sure what changed.
Thanks,
Tom
First of all, use virtualenv to isolate packages for multiple Python installations. Most of your problems will go away immediately.
Second, as Ibp has recommended in his answer, change the shebang line to use the "currently active" python binary so that it will work across multiple interpreters.
Instead of using the shebang (first bytes of the file)
#!/usr/bin/python
use the shebang
#!/usr/bin/env python
Edit: I second Noufal's suggestion to use virtualenv.
I've recently come back to a project having had to stop for about 6 months, and after reinstalling my operating system and coming back to it I'm having all kinds of crazy things happen. I made sure to install the same version(2.6) of python that I was using before.
It started by giving me strange tkinter error that I hadn't had trouble with before, the program is relatively simple and the 2 or 3 bugs that were left when i quit, I had documented and weren't related to the interface.
Things got even weirder when the same error would pop up even after I had removed the offending section of code. In fact, the traceback pointed to a line that didn't even exist in the module it was referencing, eg: line 262 when the module was only 200 lines long.
After just starting a completely new file for the main module and copy/pasting it finally recognized that the offending code was gone and I stopped getting the error only to find that any updates to the code I made in another module didn't show up when I restarted the program through the shell. (I didn't forget to save.) After fiddling with this, of course, the old interface error came back, only in a different section of code that had been working previously.
In fact, if I revert back to the files I had six months ago, the program works fine. As soon as I change anything in the main module, however, the interface bug comes back.
Here's the original error:
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
return self.func(*args)
File "C:\PyStuff\interface.py", line 202, in dispOne
__main__.top.destroy()
File "C:\Python26\lib\lib-tk\Tkinter.py", line 1938, in destroy
self.tk.call('destroy', self._w)
TclError: can't invoke "destroy" command: application has been destroyed
I'm guessing something else is going on here other than my own poor programming. Anyone have any ideas?
Edit: Thinking back, I believe I read something about it being a bad idea to run Tkinter programs through IDLE's shell, and it appears, at least, that the TclError has vanished if I instead start the main module by double clicking the .pyc file. Perhaps my problems were just a combination of that plus the timestamp/PYTHONPATH issues mentioned below by Chris Atlee and Vlad?
I've had something similar happen. The cause for my problems was that my source control software (hg) was setting the date of files to a date in the past. Because of this, python chose to use previously generated .pyc files which had newer timestamps.
The solution was to delete all the .pyc files before testing the code.
Check your PYTHON_PATH variable, you probably have an older version of the file.
Also start your python interpreter and type the following commands to check the path:
import sys
print sys.path
Take a careful look at the output and make sure you don't have any old directories sitting there.