how do "real" python programmers work?

[Tom Anderson]

well, we need a term for development environment built out of Unix
tools....

Disintegrated development environment? Differentiated development
environment? How about just a development environment?

tom

 

[Tom Anderson]

We already have one. The term is "emacs".

Emacs isn't built out of unix tools - it's a standalone program.

Ah, of course - to an true believer, emacs *is* the unix toolset.



tom

 

[Dan Sommers]

Ah, of course - to an true believer, emacs *is* the unix toolset.

To the true believer, unix runs under emacs.

Regards,
Dan

 

[Mike Meyer]

We already have one. The term is "emacs".

So people using a development environment built around vim's pyhon
mode are using emacs?

<mike

 

[Mike Meyer]

Disintegrated development environment? Differentiated development
environment? How about just a development environment?

I'd like the term to distinguish it from a standalone integrated
development environment, which lets out the last one. How about
"interconnected development enviroment" so we can reasonably suggest
it whenever someone asks for an IDE?

<mike

 

[fynali]

Love it.

 

[Alex Martelli]

There are a lot of us who use a test-first process:

Yep, I'm one of those ("TDD", "test-driven development", is the acronym
-- I think concept and monicker are both due to Kent Beck). I also
strive to convince anybody else to do that if I have any stake in the
success of their programming -- if they're emacsers, bully for them, but
I'm a vi'er myself (I keep telling myself I should learn emacs, but
then, I also tell myself I should stop smoking, and I don't actually DO
anything about that, either;-), and TDD can be used with any editor or
IDE, anyway.


Alex

 

[kpd]

I have a python file type setup in Vim. When I hit F9, it saves the
file and executes it in a python shell.

My _vimrc:

filetype on
autocmd FileType python call FileType_Python()

" Python coding
function! TryPython()
:w!
:!python %
endfunction

function! FileType_Python()
map <F9> :call TryPython()<cr>
map! <F9> <esc>:call TryPython()<cr>
set makeprg=python\ %
set errorformat=\ \ File\ \"%f\",\ line\ %l,
so ~/vimfiles/indent/python.vim
so ~/vimfiles/bike.vim
so ~/vimfiles/python_calltips.vim
endfunction

 

[Stormcoder]

I might be a little late to the party but my comments may still be
valuable.

I write Python code in emacs. Emacs has an great python-mode. The code
I write can range from a GUI apps to server side code and emacs works
just as well in all cases. Some of the features that make emacs a good
Python editor is a built in code browser, embedded interactive shell,
evaluation of python code in either a region, class, function or the
whole buffer. I can force a reimport of the code in a buffer to the
interactive interpreter. Add onto those features all the nifty emacs
text editing features plus the ability to build tools on top of emacs
and you have a really good development system. I've used a number of
commercial and open source tools including Slickedit, and pretty much
all the Python specific tools out there and have come back to emacs
because it does what I need without getting in my way.

The way I work in this environment is that I will open my project files
then start an interpreter within emacs. So the way it looks when I
start is that I have a split window with my Python buffers on top with
a tab for each one. In emacs you can enable grouping for the tabs so
that when I am editing a certain kind of file only those tabs are
immediately visible. The bottom window has my interpreter. When I think
I am finished with a block of code (function, class etc) I will
evaluate it and make sure that it doesn't have any syntax errors. I can
then go down to the interactive interpreter that is in the bottom
window and test the function or class etc. I then go back up to the
editor and write more code, rinse repeat. This works extremely well for
me. I've written some large Python apps this way.

 

[Fernando Perez]

Hello,

Let me start by saying that I am coming from a background using Matlab
(or Octave), and C++. I am going to outline the basic nuts-and-bolts
of how I work in these languages, and ask for some help to find out how
the same thing is done in Python. I am not sure what the standard is.

In C++, I open up an editor in one window, a Unix shell in another. I
write the code in the editor, then switch to the shell window for
compile and run. I then go back to the editor for modifications, and
then compile and run in the shell window.

In Matlab, I do much the same thing, except there is no compile phase.
I have the editor on one window, the Matlab interactive shell in the
other. I often make a bunch of small scripts for exploration of a
problem, before writing any larger apps. I go back and forth editing
the current file, and then running it directly (Matlab looks at the
time stamp, and automagically reloads the script when I modify it).

You may be interested in looking at the ipython+matplotlib combo:

http://ipython.scipy.org
http://matplotlib.sf.net

If you start

ipython -pylab

you'll get an interactive shell that allows you to run scripts via a 'run'
command (for quick reloading), while giving you direct plotting (thanks to
matplotlib) and shell-like features (!cmd goes directly to the shell, and
many useful things like cd and ls are builtin).

This environment was specifically modeled after things like the Mathematica
and IDL shells (I don't use matlab myself), to try to make this kind of
workflow (typical of everyday scientific computing) as efficient and
pleasant and possible.

My normal workflow is a split screen with Xemacs on the left (pick your
favorite good editor) and a terminal on the right running ipython, both in
full-vertical-maximize mode. I edit in Xemacs, save and alt-tab to the
terminal to run the code (type 'r' and up-arrow to retrieve the previous
command starting with 'r'). Play with the resulting data from the run,
test, plot, etc. Edit, repeat.

You can also enable ipython to be the interactive shell inside emacs if you
want.

I hope this is useful,

f