New to python, do I need an IDE or is vim still good enough?

[python培训]

too much ide for python
PyCharm
PyDev(Eclipse)
Pyscripter

Sublime Text
TextMate UliPad
Vim

for beginner best choice idle

 

[Westley Martínez]

'Aloha!

I'm new to python, got 10-20 years perl and C experience, all gained on unix alike machines hacking happily in vi, and later on in vim.

Now it's python, and currently mainly on my kubuntu desktop.

Do I really need a real IDE, as the windows guys around me say I do, or will vim, git, make and other standalone tools make it the next 20 years too for me?

Oh, by the way, after 7 days I'm completely in love with this python thing. I should have made the switch much earlier!

/mogul %-)

I only use vim for everything. IDEs just seem to get in my way.

 

[Chris Angelico]

I only use vim for everything. IDEs just seem to get in my way.

I've just (like ten minutes ago) come across a perfect example of what
makes an IDE useful. My mother maintains a collection of documents
(book indexes, historical records, catalogs of items the society owns,
etc) in a word processor called DeScribe. She just wanted to add a
plain text file to the collection, such that she can search it for a
text string (it's an OCR transcription of an old book, I think), and
put it into DeScribe even though it doesn't need any of its
facilities, just so it'd be there with all her others. An IDE is the
right thing for her. For me, though, it's no value.

ChrisA

 

[Monte Milanuk]

I'm new to python, got 10-20 years perl and C experience, all gained
on unix alike machines hacking happily in vi, and later on in vim.

Do I really need a real IDE, as the windows guys around me say I do,
or will vim, git, make and other standalone tools make it the next 20
years too for me?

If you've been using vi/vim happily, then I'd assume you're fully
comfortable setting it up to do what ever you need. In that case... I'd
say stick with what you know.

Me, I have less 'invested' in any particular editor or environment, and
I certainly don't 'need' a lot of the fancy extras that a lot of IDEs
have... but setting up pydev/eclipse or spyder takes care of pretty much
all that I need/want easily, and I can setup a fresh environment the way
I want inside five minutes with a mouse, fairly intuitively, without
having to go digging through config scripts and the web and books and
such to figure out what does what. I'd rather spend that time working
on projects, not 'programming' my text editor. It's neat and all if it
works for you, but just doesn't turn my crank, personally.

I know a lot is made of the speed with which things can be done with vim
and similar pure text editors... which is all well and good, but
somewhere in the not-so-distant past I saw a comment which hit home for
me. Maybe its because I'm still just a hobbyist when it comes to
coding, but I spend far more time 'thinking' about what I'm doing than
typing things in... so shaving a few seconds here and there are less
important to me.

YMMV,

Monte

 

[Chris Angelico]

Maybe its because I'm still just a hobbyist when it comes to coding, but I
spend far more time 'thinking' about what I'm doing than typing things in...
so shaving a few seconds here and there are less important to me.

The value of a good editor isn't just in saving seconds. A couple of examples:

* Bracket matching helps to catch errors. Especially helpful when
combined with...
* Language-sensitive auto-indentation. If the editor detects that the
last line isn't complete (maybe you opened a parenthesis that you
didn't close...
... like that...)
and automatically indents, then you have instant feedback, before you
even run the program.
* Rapid location of relevant code. In SciTE, I can put the cursor on a
word and hit Ctrl-F3 to search for other occurrences of it - for
instance, put the cursor on a function name and find its definition.
(A strict declare-before-use policy helps here, as you can be fairly
sure that the first occurrence of that word will be the one you want.)
* Highlighting of comments and quoted strings, including all the
esoteric rules about line continuation and nesting.

Several of these points are more important to the polyglot than to
someone who uses only one language ever. For instance, in Python and
C, this would show an error, but in bash and PHP, it's not:

"asdf
qwer"

The difficulty of debugging varies directly with the time between
making and discovering the error. Finding a problem by compiling,
running, and using a program is good (better than it staying till
production); finding that same problem while you're in the
"compilation stage" is better; finding it right at that instant while
you're typing makes the correction trivial. That's why spell-checkers
have migrated from "press Ctrl-Q to check this document" to "red
squiggly lines underneath your text if the computer thinks it's
wrong". (That said, the number of spelling errors in published
documents hasn't gone down since red squigglies were invented, so
instant feedback isn't a panacea!)

Of course, editors are as much a matter of taste as they are science...

ChrisA

 

[Grant Edwards]

I'm new to python, got 10-20 years perl and C experience, all gained
on unix alike machines hacking happily in vi, and later on in vim.

Now it's python, and currently mainly on my kubuntu desktop.

Do I really need a real IDE, as the windows guys around me say I do,
No.

or will vim, git, make and other standalone tools make it the next 20
years too for me?

I've been writing Python programs for 10-12 years, and I use the same
"IDE" I use for everything else: Emacs, svn/git/whatever and a command line.

I do use the "meld" visual diff program quite a bit...

 

[Mitya Sirenef]

Maybe its because I'm still just a hobbyist when it comes to coding, but I spend far more time

'thinking' about what I'm doing than typing things in... so shaving a
few seconds here and there are less important to me.


I think the general idea is that with editors like Vim you don't get
distracted by having to do some kind of an editor task, letting you keep
your full attention on the code logic. For instance, if I need to change
a block inside parens, I type ci) (stands for change inside parens),
while with a regular editor I'd have to do it manually and by the time
I'm done, I'd forget the bigger picture of what I'm doing with the code.
Another example: >ap stands for "indent a paragraph (separated by blank
lines)". And there are many dozens if not hundreds such commands that
let you stay focused on the logic of your code.

The trade-off, of course, is that you have to remember all (or most) of
the commands, but I figured if I spend the next 20-30+ years programming
in some version of Vim, it's well worth the initial investment.

By the way, to help me remember the commands, I wrote a small script
that lets me type in a few characters of a command or its description
and filters out the list of matching commands. It really helps,
especially when I change a lot of my mappings.

- mitya

 

[Roy Smith]

If more "professional" programmers spent more time thinking and less
type typing, the world would be a better place. Keep doing what you're
doing. Really.

Bracket matching
Language-sensitive auto-indentation
and automatically indents

Yeah, what he said, plus syntax coloring. And keyword highlighting.
And autocompletion of variable names.

And parsing of error messages.

I'll pause a moment to let that sink in. Grok the fullness of just how
awesome a feature it is.

In emacs, for example. I'll do C-C M (which I have bound to M-X
Compile). This runs a command and captures the output in a buffer. If
the output happens to contain something like:

Traceback (most recent call last):
File
"/home/roy/production/python/local/lib/python2.7/site-packages/nose/case.
py", line 197, in runTest
self.test(*self.arg)
File "/home/roy/songza/api2/test_api2.py", line 16, in test_get_api
data = requests.get(url('api/v2/')).json
File "/home/roy/songza/api2/test_common.py", line 13, in url
assert route.startswith('/')
AssertionError

emacs will parse that, highlight the filenames and line numbers and if I
type M-`, it'll take me to the line of the next error (including opening
the file if it's not already open).

I assume other smart editors have similar capabilities. Different tools
have different combinations of these, or slightly different
implementations. Find one you like and learn all of it's capabilities.
It makes a huge difference in how productive you are.

 

[Monte Milanuk]

Yeah, what he said, plus syntax coloring. And keyword highlighting.
And autocompletion of variable names.

I'll probably get dog-piled by the vim/emacs folks again here... but
isn't that something most decent text editors do?

And parsing of error messages.

I'll pause a moment to let that sink in. Grok the fullness of just how
awesome a feature it is.

In emacs, for example. I'll do C-C M (which I have bound to M-X
Compile). This runs a command and captures the output in a buffer. If
the output happens to contain something like:

Traceback (most recent call last):
File
"/home/roy/production/python/local/lib/python2.7/site-packages/nose/case.
py", line 197, in runTest
self.test(*self.arg)
File "/home/roy/songza/api2/test_api2.py", line 16, in test_get_api
data = requests.get(url('api/v2/')).json
File "/home/roy/songza/api2/test_common.py", line 13, in url
assert route.startswith('/')
AssertionError

emacs will parse that, highlight the filenames and line numbers and if I
type M-`, it'll take me to the line of the next error (including opening
the file if it's not already open).

I assume other smart editors have similar capabilities. Different tools
have different combinations of these, or slightly different
implementations. Find one you like and learn all of it's capabilities.
It makes a huge difference in how productive you are.

While I probably don't use the vast majority of the 'fancy' features of
most IDEs - most of what I do barely requires any real 'project
manangement'... there are a couple things that I've gotten *very* used
to with an IDE.

One is having it run pylint and pep8 checks against code, display the
output in a friendly format with links straight to the offending items
and even displaying colored carats in the gutter region and
high-lighting them.

The other is having it parse my imports, and use them for the
'auto-complete' aka 'code intelligence' features - and not just the
standard library stuff, but also GUI toolkits like PyQt4.

I'm pretty sure those things can be done, or something fairly close at
least, in editors like vim or emacs... but the few times I looked into
it for vim, it was enough to send me running back to Eclipse/PyDev, even
if it is kind of an 800lb gorilla otherwise.

It's still on my 'one of these days' list of things to do, though

 

[Chris Angelico]

Yeah, what he said, plus syntax coloring. And keyword highlighting.
And autocompletion of variable names.

Syntax coloring I kinda touched on in different pieces; keyword
highlighting isn't, imho, all that important. Apart from reminding you
that the variable name you planned to use is an obscure keyword, it
doesn't save all that much time. Auto-complete is handy, but not
critical.

And parsing of error messages.

I'll pause a moment to let that sink in. Grok the fullness of just how
awesome a feature it is.

And how glaring an omission from my list. Yes. This one *definitely*
belongs there. Though unlike most of the other examples, it's not as
language-specific; you can cover a huge number of utilities by simply
recognizing:

filename:line: message

Coupled with a helpful C compiler, this lets you jump around pretty
easily. For instance, gcc will (if I recall correctly - haven't had to
use this feature in a while, something to do with writing more code in
Python and Pike than C, but anyway), if the arguments to a function
mismatch, show error lines highlighting both the invocation *and* the
declaration, so you can quickly compare (even if they're in different
files).

emacs will parse that, highlight the filenames and line numbers and if I
type M-`, it'll take me to the line of the next error (including opening
the file if it's not already open).

I assume other smart editors have similar capabilities.

Yeah, SciTE has F4 and Shift-F4 to cycle forwards/backwards through
messages, and I expect it's pretty much standard among editors that
can invoke external tools. It's extremely handy; not only errors from
compilation/execution, but things like a 'git grep -n' fit too.

ChrisA

 

[Roy Smith]

Auto-complete is handy, but not critical.

You just wait until your finger joints get to be my age and tell me that
auto-complete isn't critical

It's extremely handy; not only errors from
compilation/execution, but things like a 'git grep -n' fit too.

Emacs has integrations with many version control systems. Over the
years, I've gone back and forth over whether I do my version control
from within emacs or at the command line.

These days (with mercurial), I tend to do most vc-things at the command
line. But, I'm addicted to C-x v = (hg diff). It diffs the current
buffer against the last checked-in version of the file, and can take me
directly to any particular changed line.

Again, I would imagine any decent editor these days would have something
similar. It just blows my mind when I see people editing program text
with NotePad or some similar piece of crap.

Oh, yeah, one other thing I forgot. You want to use an editor which can
(preferably as something you can turn on and off easily) put line
numbers down the left margin of the screen. For solo editing, it's kind
of silly. But if you're doing any kind of pair programming, code
review, or presentation to a group, it's invaluable. Compare and
contrast:

"In the big for loop, a couple of lines down, no, not there, the other
for loop, yeah, now go down a couple of lines, no that's too far, back
up one. Yeah there. On that line, why do you ..."

with:

"On line 647, why do you ..."

 

[Mitya Sirenef]

"In the big for loop, a couple of lines down, no, not there, the other
for loop, yeah, now go down a couple of lines, no that's too far, back
up one. Yeah there. On that line, why do you ..."

with:

"On line 647, why do you ..."

It's even better when it prints line # from top of screen, I have a
handy mapping that jumps directly to a line # and it's much easier to
type 23<space> or 9<space> when you jump around a lot.

- mitya

 

[Chris Angelico]

Emacs has integrations with many version control systems. Over the
years, I've gone back and forth over whether I do my version control
from within emacs or at the command line.

My point was that it fits _many_ tools, without specific integration
with the tool. But yes, version control integration is a useful tool
(though not one I've personally made use of - I just run git commands
from the command line).

Again, I would imagine any decent editor these days would have something
similar. It just blows my mind when I see people editing program text
with NotePad or some similar piece of crap.

Yes. And then hopping over to Stack Overflow and trying to figure out
why their PHP script won't create HTTP headers. Combination of poor
language and poor editor...

Oh, yeah, one other thing I forgot. You want to use an editor which can
(preferably as something you can turn on and off easily) put line
numbers down the left margin of the screen. For solo editing, it's kind
of silly. But if you're doing any kind of pair programming, code
review, or presentation to a group, it's invaluable. Compare and
contrast:

"In the big for loop, a couple of lines down, no, not there, the other
for loop, yeah, now go down a couple of lines, no that's too far, back
up one. Yeah there. On that line, why do you ..."

with:

"On line 647, why do you ..."

Absolutely! Though it's roughly as good to have the current cursor
position shown in a status line somewhere, and takes up less real
estate. But yes, vital to be able to see that. Even when I'm sitting
*right next to* my boss and communicating verbally, I'll talk about
the code by quoting line numbers. "Let me explain. (No, there is too
much. Let me sum up.) Pull up foobar dot jay ess and go to line
254-ish - see how the frobnosticator always gets called with a quuxed
argument?"

ChrisA

 

[Mitya Sirenef]

Absolutely! Though it's roughly as good to have the current cursor
position shown in a status line somewhere, and takes up less real
estate.

I have to disagree -- if someone is standing next to you
and they want to refer to a particular line, they can't
really tell you "move the cursor to that line there, so I
can read its line number from status line and then tell
you I'm referring to that line".

- mitya

 

[Chris Angelico]

I have to disagree -- if someone is standing next to you
and they want to refer to a particular line, they can't
really tell you "move the cursor to that line there, so I
can read its line number from status line and then tell
you I'm referring to that line".

Ah, to clarify: We have our separate computers in front of us. So when
I quote a line number, it's by looking at my screen, and allows him to
synchronize his display.

Of course, if you can afford the real estate, and as long as they're
not distracting, a column of numbers doesn't hurt.

ChrisA

 

[Tim Johnson]

I've been using vim for 12 years now. And it works pretty good for
me as an "IDE". I've written a lot of vimscripts to make vim
better do my bidding and made generous use of contributed scripts.

I see no reason to think that I would be more productive using
anything else, but that is just me.

Along the way, I did use emacs as well and ended doing quite a bit
of elisping.

Elisp does have the advantage of asynchronously running the
interpereter inside of the editor.... Just one thing that I
wouldn't mind seeing in vim.....

I do find vim a bit more nimble than emacs, but each to his/her
own. It's wonderful to have all of the choices.

"""
They'll take away my vim when they pry it from my cold, dead
fingers.
"""

 

[Chris Angelico]

Along the way, I did use emacs as well and ended doing quite a bit
of elisping.

elispsis. n. the intentional omission of unnecessary work which can be
inferred by the editor; often indicated with three consecutive
parentheses ((( )))

ChrisA

 

[Adam Tauno Williams]

'Aloha!
I'm new to python, got 10-20 years perl and C experience, all gained
on unix alike machines hacking happily in vi, and later on in vim.
Now it's python, and currently mainly on my kubuntu desktop.
Do I really need a real IDE, as the windows guys around me say I do,

You don't need one.

You are crazy if you don't WANT one.

Check out geany <http://www.geany.org/>

 

[Hans Mulder]

You don't need one.
+1

You are crazy if you don't WANT one.

ITYM: you'd be crazy if you'd want one.

Check out geany <http://www.geany.org/>

Don't bother: Python comes with a free IDE named IDLE. Try it
for a few minutes, and you'll find that most of the features
that make vim so wonderful, are missing from IDLE.

Just stay with vim.

-- HansM

 

[Chris Angelico]

And any decent Unix-alike (most OSen apart from Windows) comes with its
own IDE: the shell, a good text editor (Vim or Emacs being the primary
candidates), and a terminal multiplexor (such as ‘tmux’ or GNU Screen).

Learning to use that development environment will benefit you far more
than any language-specific tool.

And more than that: Learning to use that development environment gives
you the flexibility to swap out components individually. "The shell"
could be one of several (though bash seems to be the most popular),
the editor is one of many, and there are a good few options for
terminal arrangement (tmux, screen, gnome-terminal, etc). So what if
you decide you don't like vim OR emacs - you can still use the "Unix
IDE" with some other editor. Most IDEs don't have that facility.

It's a question of freedom. Would you let someone else choose what
shoes you're allowed to wear? Then why cede over the choice of
development software? No matter how awesome those shoes are, it's an
unnecessary restriction in freedom.

Of course, you're free to use an IDE if you want to, too. I don't see
much point in it, but if that's how you swing, go for it.

ChrisA