I recently tried switching from using python-mode.el to python.el for editing python files in emacs, found the experience a little alien and unproductive, and scurried back. I've been using python-mode.el for something like ten years, so perhaps I'm a little set in my ways. I'd be interested in hearing from anyone who's carefully evaluated the two modes, in particular of the pros and cons they perceive of each and how their work generally interacts with the features specific to python.el.
The two major issues for me with python.el were
Each buffer visiting a python file gets its own inferior interactive python shell. I am used to doing development in one interactive shell and sharing data between python files. (Might seem like bad practice from a software-engineering perspective, but I'm usually working with huge datasets which take a while to load into memory.)
The skeleton-mode support in python.el, which seemed absolutely gratuitous (python's syntax makes such automation unnecessary) and badly designed (for instance, it has no knowledge of "for" loop generator expressions or "<expr 1> if <cond> else <expr 2>" expressions, so you have to go back and remove the colons it helpfully inserts after insisting that you enter the expression clauses in the minibuffer.) I couldn't figure out how to turn it off. There was a python.el variable which claimed to control this, but it didn't seem to work. It could be that the version of python.el I was using was broken (it came from the debian emacs-snapshot package) so if anyone knows of an up-to-date version of it, I'd like to hear about it. (I had the same problem with the version in CVS emacs as of approximately two weeks ago.)
For what it's worth, I do not see the behavior you are seeing in issue #1, "Each buffer visiting a python file gets its own inferior interactive python shell."
This is what I did using python.el from Emacs 22.2.
C-x C-f foo.py
[insert: print "foo"]
C-x C-f bar.py
[insert: print "bar"]
C-c C-z [*Python* buffer appears]
C-x o
C-c C-l RET ["bar" is printed in *Python*]
C-x b foo.py RET
C-c C-l RET ["foo" is printed in the same *Python* buffer]
Therefore the two files are sharing the same inferior python shell. Perhaps there is some unforeseen interaction between your personal customizations of python-mode and the default behaviors of python.el. Have you tried using python.el without your .emacs customizations and checking if it behaves the same way?
The major feature addition of python.el over python-mode is the symbol completion function python-complete-symbol. You can add something like this
(define-key inferior-python-mode-map "\C-c\t" 'python-complete-symbol)
Then typing
>>> import os
>>> os.f[C-c TAB]
you'll get a *Completions* buffer containing
Click <mouse-2> on a completion to select it.
In this buffer, type RET to select the completion near point.
Possible completions are:
os.fchdir os.fdatasync
os.fdopen os.fork
os.forkpty os.fpathconf
os.fstat os.fstatvfs
os.fsync os.ftruncate
It'll work in .py file buffers too.
I can't reproduce this behavior on Emacs v23.1, this must have been changed since then.
Forget about any mode's skeleton support and use the hyper-advanced and extensible yasnippet instead, it's really worth a try!
Note nearly everything said here is obsolete meanwhile as things changed.
python-mode.el commands are prefixed "py-" basically, you should be able to use commands from both, nonewithstanding which one was loaded first.
python-mode.el does not unload python.el; beside of python-mode-map, which is re-defined.
The diff is in the menu displayed and keysetting however, the last one loaded will determine.
python-mode.el is written by the Python community. python.el is written by the emacs community. I've used python-mode.el for as long as I can remember and python.el doesn't even come close to the standards of python-mode.el. I trust the Python community better than the Emacs community to come up with a decent mode file. Just stick with python-mode.el, is there really a reason not to?
python-mode.el has no support triple-quoted strings, so if your program contains long docstrings, all the syntax coloring (and associated syntaxic features) tends to break down.
my .02
Debian has deleted the python-mode package, alas, so I felt compelled to try python.el. I loaded it and ran "describe-bindings". It appeared to be designed for elisp coders who think c-X ; is the intuitive binding for commenting a line of Python code. (Wow.) Also, I found no way at all to comment a region of code, or, rather, no binding with the strings "region" and "comment" in it.
Good old python-mode can still be cloned via git clone https://gitlab.com/python-mode-devs/python-mode.git. It was last edited a week ago at this writing, so it's safe to assume it's not abandoned.
Related
I am working on a project whereby I need to embed Python within a Verilog file. The Python isn't really intended for execution in the normal sense as it will be read by a secondary tool. The Python will be written blocks that have some fixed demarcation (such as #+BEGIN_SRC, in org-babel).
module name ();
#+BEGIN_SRC python
def my_function ():
...
#+END_SRC
always #(posedge clk)
...
endmodule
Within Emacs this causes havoc, although Python-mode and Verilog-mode work fine, when combining both in the same file things quickly break-down as one would expect. Indentation is hopelessly broken as is syntax-highlighting. I understand this is a very weird thing to do, and I understand that there will almost certainly never been any real need to do this under normal circumstances, however for this particular case it is necessary.
My question: is there anyway within Emacs to specify multiple major modes within the same file. For example, is there some way that I can write a file using Verilog-mode as my major mode, but use Python-mode within the predefined blocks that are then ignored in the reset of the file.
There are a number of possibilities listed here:
http://emacswiki.org/emacs/MultipleModes
I've used multi-mode with latex and haskell, and it works OK.
Is there a debugger that can debug the Python virtual machine while it is running Python code, similar to the way that GDB works with C/C++? I have searched online and have come across pdb, but this steps through the code executed by the Python interpreter, not the Python interpreter as its running the program.
The reference implementation of Python, CPython, is written in C. You can use GDB to debug it as you would debug any other program written in C.
That said, Python does have a few little helpers for use in GDB buried under Misc/gdbinit. It's got comments to describe what each command does, but I'll repeat them here for convenience:
pyo: Dump a PyObject *.
pyg: Dump a PyGC_Head *.
pylocals: Print the local variables of the current Python stack frame.
lineno: Get the current Python line number.
pyframe: Print the source file name, line, and function.
pyframev: pyframe + pylocals
printframe: pyframe if within PyEval_EvalFrameEx; built-in frame otherwise
pystack: Print the Python stack trace.
pystackv: Print the Python stack trace with local variables.
pu: Print a Unicode string.
It looks like the Fedora project has also assembled their own collection of commands to assist with debugging which you may want to look at, too.
If you're looking to debug Python at the bytecode level, that's exactly what pdb does.
If you're looking to debug the CPython reference interpreter… as icktoofay's answer says, it's just a C program like any other, so you can debug it the same way as any other C program. (And you can get the source, compile it with extra debugging info, etc. if you want, too.)
You almost certainly want to look at EasierPythonDebugging, which shows how to set up a bunch of GDB helpers (which are Python scripts, of course) to make your life easier. Most importantly: The Python stack is tightly bound to the C stack, but it's a big mess to try to map things manually. With the right helpers, you can get stack traces, frame dumps, etc. in Python terms instead of or in parallel with the C terms with no effort. Another big benefit is the py-print command, which can look up a Python name (in nearly the same way a live interpreter would), call its __repr__, and print out the result (with proper error handling and everything so you don't end up crashing your gdb session trying to walk the PyObject* stuff manually).
If you're looking for some level in between… well, there is no level in between. (Conceptually, there are multiple layers to the interpreter, but it's all just C code, and it all looks alike to gdb.)
If you're looking to debug any Python interpreter, rather than specifically CPython, you might want to look at PyPy. It's written in a Python-like language called RPython, and there are various ways to use pdb to debug the (R)Python interpreter code, although it's not as easy as it could be (unless you use a flat-translated PyPy, which will probably run about 100x too slow to be tolerable). There are also GDB debug hooks and scripts for PyPy just like the ones for CPython, but they're not as complete.
I've been all over the web trying to find a way to get VIM to have code completion similar to PyDev. It doesn't seem like it is possible!
-I have tried to use the omnicompletion suggested at this link: http://blog.dispatched.ch/2009/05/24/vim-as-python-ide/ .
-I have tried several addons to alleviate the problem, none work.
The "omnicomplete" functionality is NOT what I am looking for. It just takes all the words in the file you are working on and uses those to try and complete what I am doing. For example if I wrote:
import numpy
a_single_array = range(100)
np.a#[then I hit cntrl+n to code complete]
It would spit out "a_single_array" as a possible completion -- but that is absurd! That is not a valid completion for "numpy.a ..."
What is the issue here? All the addon would have to do is run a dir(work you want to find) from the folder you are in and then filter the output! This cannot be that difficult! (I suppose you would also have to read the file you are currently editing and filter that as well to take note of name changes... but that's pretty much it!)
Speaking of how easy it would be... if there isn't anything already made, I was thinking of writing the script myself! Any guides on how to do THAT?
No, the omni completion functionality is EXACTLY what you are looking for.
You are using <C-n> instead of <C-x><C-o>:
type <C-n> & <C-p> to complete with words from the buffer (after and before the cursor respectively)
type <C-x><C-o> to complete method/properties names
It's specifically explained in the article you linked:
In V7, VIM introduced omni completion – given it is configured to recognize Python (if not, this feature is only a plugin away) Ctrl+x Ctrl+o opens a drop down dialog like any other IDE – even the whole Pydoc gets to be displayed in a split window.
Ctrln is insert-completion.
Ctrlx Ctrlo is omni-completion.
I remap omnicompletion to CtrlSpace:
inoremap <C-Space> <C-x><C-o>
You could also try SuperTab.
I have no idea about the various completion options for Python in Vim. But if you want to roll your own you'd be well advised to study and modify one of the existing ones, like this:
http://www.vim.org/scripts/script.php?script_id=1542
Also, if all your omnicompletion is doing is listing words in current file then you don't have it set up properly for Python-specific completion. . . . Not sure how good the specialized Python completion systems get, but they certainly does compete based on Python units external to your current file. . . .
I am using the python.el from fgallina python.el github There is a long list of features but I am unaware of how to use them.
EDIT: Found this mode was working, however didn't automatically open the interpreter went the information was sent there. How can I send/load my current python buffer to be evaluated? I am trying to use C-c C-c but I don't get any output.
Python shell integration and shell completion? Do I need to add something beside the standard load-path and require statements for this?
Imenu support this isn't showing for me either.
Edit I tried adding this to my emacs but that hasn't worked.
add-hook 'python-mode-hook 'imenu-add-menubar-index)
I am using emacs 23 on ubuntu
For your first question: Usually you can load a buffer/file using C-c C-l. (Just tested this for python.el, and it works for this one as well) This will send the file to the inferior python process -- so you should open the *Python* buffer to see the results. The *Python* buffer is also your regular python interpreter/shell/REPL. C-M-x is bound to python-send-defun which sends a method/function definition to the interpreting process. For other bindings just hit M-x describe-bindings and then look for "python-" (under "Major Mode Bindings") in the opened *Help* buffer window.
There is some more documentation at the beginning of python.el if you want to know more about completion:
Quote:
Shell completion: hitting tab will try to complete the current
word. Shell completion is implemented in a manner that if you
change the python-shell-interpreter to any other (for example
IPython) it should be easy to integrate another way to calculate
completions. You just need to specify your custom
python-shell-completion-setup-code and
python-shell-completion-string-code.
Quote:
Symbol completion: you can complete the symbol at point. It uses
the shell completion in background so you should run
python-shell-send-buffer from time to time to get better results.
Skeletons: 6 skeletons are provided for simple inserting of class,
def, for, if, try and while. These skeletons are integrated with
dabbrev. If you have dabbrev-mode activated and
python-skeleton-autoinsert is set to t, then whenever you type
the name of any of those defined and hit SPC, they will be
automatically expanded.
The imenu entry shows up for me without adding the hook, just (require 'python) in a configuration file.
I'm noticing that even for system modules, code completion doesn't work too well.
For example, if I have a simple file that does:
import re
p = re.compile(pattern)
m = p.search(line)
If I type p., I don't get completion for methods I'd expect to see (I don't see search() for example, but I do see others, such as func_closure(), func_code()).
If I type m., I don't get any completion what so ever (I'd expect .groups(), in this case).
This doesn't seem to affect all modules.. Has any one seen this behaviour and knows how to correct it?
I'm running Vim 7.2 on WinXP, with the latest pythoncomplete.vim from vim.org (0.9), running python 2.6.2.
Completion for this kind of things is tricky, because it would need to execute the actual code to work.
For example p.search() could return None or a MatchObject, depending on the data that is passed to it.
This is why omni-completion does not work here, and probably never will. It works for things that can be statically determined, for example a module's contents.
I never got the builtin omnicomplete to work for any languages. I had the most success with pysmell (which seems to have been updated slightly more recently on github than in the official repo). I still didn't find it to be reliable enough to use consistently but I can't remember exactly why.
I've resorted to building an extensive set of snipMate snippets for my primary libraries and using the default tab completion to supplement.