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

[xDog Walker]

“I bought some powdered water, but I don't know what to add.â€

Suggest to Stephen Wright to add hot coffee.

 

[Steven D'Aprano]

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.

See, by the time I remembered what obscure (to me) command to type, or
searched the help files and the Internet, I'd have forgotten what the
hell it was I was trying to do. Well, almost. My memory is not quite that
bad, but it would certainly be a much bigger disruption to my coding than
just doing the edit by hand.

I do love the power of command line tools, but I think that for rich
applications like editors, the interface is so clunky that I'd rather use
a less-powerful editor, and do more editing manually, than try to
memorize "hundreds" of commands.

With a GUI app, I can run the mouse over the menus and see a high-level
overview of everything the app can do in a matter of a second or two.
(Perhaps three or five seconds if the app over-uses hierarchical menus.)
But with a text interface, commands are much less discoverable. I can
also use *spacial* memory to zero in on commands much more easily than
verbal memory -- I have no idea whether the command I want is called
"Spam" or "Ham" or "Tinned Bully Beef", but I know it's in the top
quarter of the "Lunch" menu, and I will recognise it when I see it.

On the other hand, it's a lot harder to use a GUI app over a slow SSH
connection to a remote machine in a foreign country over a flaky link
than it is to use a command line or text-interface app.

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.

Ah yes, the famous "a for indent" mnemonic. *wink*

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.

It seems to me, that by the time I would have searched for the right
command to use, decided which of the (multiple) matching commands is the
right one, then used the command, it would have been quicker and less
distracting to have just done the editing by hand. But now I'm just
repeating myself.

 

[Steven D'Aprano]

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?"

I call shenanigans

I don't expect that you keep in your head the line numbers (even the line
numbers-ish) of interesting or pertinent features of your code,
*especially* while the code is in active development and the line numbers
are rapidly changing. I think it is far more likely that you keep
function, class or method names in your head (after all, you are
presumably reading and writing those names very often), and when you want
to demonstrate some feature, you *first* look it up by higher-level
object ("let's see the frob_quux function") to get the line number.

Assuming that your functions and methods are not obnoxiously huge, I
think having a good class browser which lets you jump directly to
functions or methods is *far* more useful than line numbers, in this
context.

 

[Chris Angelico]

I call shenanigans

I don't expect that you keep in your head the line numbers (even the line
numbers-ish) of interesting or pertinent features of your code,
*especially* while the code is in active development and the line numbers
are rapidly changing. I think it is far more likely that you keep
function, class or method names in your head (after all, you are
presumably reading and writing those names very often), and when you want
to demonstrate some feature, you *first* look it up by higher-level
object ("let's see the frob_quux function") to get the line number.

Neither. You're correct that I don't memorize line numbers; but the
point of them was not to synchronize a screen with a brain, but to
synchronize two screens. So you're also correct that I look it up to
get the line number. But I'm not locating a function; if I wanted
that, I'd use that. No, I'm pointing to a specific line of code.

Assuming that your functions and methods are not obnoxiously huge, I
think having a good class browser which lets you jump directly to
functions or methods is *far* more useful than line numbers, in this
context.

They're not obnoxiously huge, but even twenty lines is too coarse when
you're trying to explain one line of code. Way too coarse. I want to
pinpoint what I'm talking about.

ChrisA

 

[Cameron Simpson]

| On Sat, 29 Dec 2012 14:00:23 -0500, Mitya Sirenef wrote:
| > [...] 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.
|
| See, by the time I remembered what obscure (to me) command to type, or
| searched the help files and the Internet, I'd have forgotten what the
| hell it was I was trying to do.

Well, the idea is that your fingers become familiar with the core
commands. An issue of practice. The more complex vi commands are usually
composed from smaller pieces, so the learning curve isn't as steep as it
initially appears. Eg "%" jumps to that matching bracket. And
_therefore_, "c%" changes all text from here to the matching bracket.
There's a whole host of these.

| With a GUI app, I can run the mouse over the menus and see a high-level
| overview of everything the app can do in a matter of a second or two.

Well, there is GVim, a GNome X11 interface to vim. I imagine it would
offer that kind of mode.

| (Perhaps three or five seconds if the app over-uses hierarchical menus.)
| But with a text interface, commands are much less discoverable. I can
| also use *spacial* memory to zero in on commands much more easily than
| verbal memory -- I have no idea whether the command I want is called
| "Spam" or "Ham" or "Tinned Bully Beef", but I know it's in the top
| quarter of the "Lunch" menu, and I will recognise it when I see it.

I must admit I find Apple's "help" search box neat this way - you can
type a keyword is it will actually find the menu item for you. Not that
I use this for vi, of course...

| > 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.
|
| Ah yes, the famous "a for indent" mnemonic. *wink*

No, ">" is indent: it means shift-right. For Python you'd set the
shiftwidth to 4 (well, I use 2). But again, that's a grammar. Like the
"change" example above it is ">" followed by a cursor motion. So I'm
quite fond of ">}". "}" means jump to next blank line (or end of
paragraph for a prose paradigm). So ">}" means shift right from here to the
next blank line.

When your fingers know the cursor motion commands, folding any of them
into a compound command like "c" or ">" or "<" (guess what that one is)
requires almost no though. It's almost like speaking - you don't think
about grammar in your native language.

| It seems to me, that by the time I would have searched for the right
| command to use, decided which of the (multiple) matching commands is the
| right one, then used the command, it would have been quicker and less
| distracting to have just done the editing by hand. But now I'm just
| repeating myself.

To repeat yourself in "vi" you just type ".". See? So much faster than
your paragraph above

Cheers,
--
Cameron Simpson <[email protected]>

As your attorney, it is my duty to inform you that it is not important that
you understand what I'm doing or why you're paying me so much money. What's
important is that you continue to do so.
- Hunter S. Thompson's Samoan Attorney

 

[Tim Chase]

I must admit I find Apple's "help" search box neat this way - you
can type a keyword is it will actually find the menu item for
you. Not that I use this for vi, of course...

If you've not used it, Vim's ":helpgrep" command provides full Vim
regexp power for searching Vim's help.

No, ">" is indent: it means shift-right. For Python you'd set
the shiftwidth to 4

For PEP8, you'd also want to set 'expandtab'. Just to bring my
semi-OT reply back around to Python

-tkc

 

[Mitya Sirenef]

See, by the time I remembered what obscure (to me) command to type, or
searched the help files and the Internet, I'd have forgotten what the
hell it was I was trying to do. Well, almost. My memory is not quite that
bad, but it would certainly be a much bigger disruption to my coding than
just doing the edit by hand.

I would agree with you if I had to look up a command every time I use
it. The way it really works for me is that either I use a command often
enough that I remember it from the first time I looked it up, and the
memory is reinforced every time I use it, OR it's such a rare command
that looking it up is not a problem (obviously if it's faster to do it
by hand than to look it up, I can do that, as well, which in Vim means
using lower level commands that still don't require you leaving the home
row.)

I do love the power of command line tools, but I think that for rich
applications like editors, the interface is so clunky that I'd rather use
a less-powerful editor, and do more editing manually, than try to
memorize "hundreds" of commands.

Clunky is the last word I'd use to describe it (ok maybe for Emacs
I probably remember about 200 commands, plus or minus, but a lot of them
fit into a consistent scheme which makes them much easier to remember:
there's (change delete yank vis-select)*(inner outer)*(letter word WORD
paragraph )]} )

(Where word includes 'keyword' characters and WORD is separated by spaces).

So, these correspond to commands (cdyv)(ia)(lwWp)]}).

Therefore, deleting 3 WORDs is 3daW (mnemonic: del a WORD 3 times).

I think I have a pretty bad memory but I remembered all of these
commands a few at a time without too much trouble. And they're extremely
useful even now as I'm editing this email.

With a GUI app, I can run the mouse over the menus and see a high-level
overview of everything the app can do in a matter of a second or two.
(Perhaps three or five seconds if the app over-uses hierarchical menus.)
But with a text interface, commands are much less discoverable. I can
also use *spacial* memory to zero in on commands much more easily than
verbal memory -- I have no idea whether the command I want is called
"Spam" or "Ham" or "Tinned Bully Beef", but I know it's in the top
quarter of the "Lunch" menu, and I will recognise it when I see it.

It's not a binary choice, GVim has a customizable menu system with a
simple text format for adding menus (from Vim manual):

To create a new menu item, use the ":menu" commands. They are
mostly like
the ":map" set of commands but the first argument is a menu item
name, given
as a path of menus and submenus with a '.' between them. eg:

:menu File.Save :w<CR>
:inoremenu File.Save <C-O>:w<CR>

On the other hand, it's a lot harder to use a GUI app over a slow SSH
connection to a remote machine in a foreign country over a flaky link
than it is to use a command line or text-interface app.

With GVim, you can use gui menus just as easily when you open a file
remotely.

Ah yes, the famous "a for indent" mnemonic. *wink*

Well, 'a' is mnemonic for 'a', fittingly ;-). > is for indent, just as <
is for dedent. 'a' is to distinguish from inner paragraph command,
which omits blank lines after the paragraph (which matter for other
commands, but not for indent/dedent.): >ip .


- mitya

 

[Roy Smith]

Clunky is the last word I'd use to describe it (ok maybe for Emacs
I probably remember about 200 commands, plus or minus, but a lot of them
fit into a consistent scheme which makes them much easier to remember

At some point, it becomes muscle memory, which means you don't even
consciously know what you're typing. Your brain just says, "delete the
next three words" and your fingers move in some way which causes that to
happen. This is certainly true with emacs, and I imagine it's just as
true with people who use inferior editors

I used to do a bunch of pair programming with another emacs power user.
Every once in a while, one of us would say something like, "What did you
just do?", when the other performed some emacs technique one of us was
not familiar with. Invariably, the answer would be, "I don't know", and
you would have to back up and recreate the key sequence. Or, just run
C-? l, which tells you the last 100 characters you typed.

Case in point. I use C-? l moderately often, when I make some typo and
I'm not sure what I did wrong. But, despite the fact that my fingers
now how to perform "show me the last stuff I typed", I had to go hunting
to find the actual keystrokes which does that when typing the above
paragraph

 

[Mitya Sirenef]

At some point, it becomes muscle memory, which means you don't even
consciously know what you're typing. Your brain just says, "delete the
next three words" and your fingers move in some way which causes that to
happen. This is certainly true with emacs, and I imagine it's just as
true with people who use inferior editors

I used to do a bunch of pair programming with another emacs power user.
Every once in a while, one of us would say something like, "What did you
just do?", when the other performed some emacs technique one of us was
not familiar with. Invariably, the answer would be, "I don't know", and
you would have to back up and recreate the key sequence. Or, just run
C-? l, which tells you the last 100 characters you typed.

Case in point. I use C-? l moderately often, when I make some typo and
I'm not sure what I did wrong. But, despite the fact that my fingers
now how to perform "show me the last stuff I typed", I had to go hunting
to find the actual keystrokes which does that when typing the above
paragraph

That's true with Vim, as well, especially when I'm making a custom
mapping and I can NEVER remember what some combination does, even though
if I actually needed to use it, it pops right out, so to find out, I
have to try it and then I say, "of course, dammit, I use this command 50
times every single day!"; so it's a curious case of one-directional
memory.


<subliminal 1-nanosecond BLINK TAG comment="hope this works, fingers
crossed" content="let's face it, Vim is BETTER as it has always been!">

 

[jussij]

FWIW on the Windows platform the Zeus IDE has support for Python:

http://www.zeusedit.com/python.html

Zeus does the standard Python syntax highlighting, code completion, smart
indenting, class browsing, code folding etc.

Zeus also has limited Python debugger support and is fully scriptable
in Python.

Jussi Jumppanen
Author: Zeus Editor

 

[Ramchandra Apte]

'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 use Eclipse only because it has PEP 8 and Pylint integration.
Ezio Melotti, core Python developer, said in personal chat, that he uses Kate.
IDEs aren't that useful when coding in Python.

 

[Neil Cerutti]

Stick with what you've been using for the last couple of
decades. These tools have stood the test of time for a good
reason: they're powerful, efficient and made for the task of
programming.

There is a good Python plugin for Vim that will allow simple
reindenting and a bunch of other cool cursor movement powers I
don't even use. ctags will also work, though I've never really
needed it.

 

[Neil Cerutti]

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.

I used that power all the time writing C and C++ code. It felt
indespensable. But even though I can do the same with Python, it
doesn't feel crucial when writing Python. The errors are more
few.

 

[Matty Sarro]

That's really a question for you - do you want the features of an IDE?
Aptana includes pydev, and is built on eclipse which is a great
swiss-army-knife IDE. If you like KISS, vim is an excellent choice. Go with
whichever you are more comfortable using.

 

[Michael Torrie]

Therefore, deleting 3 WORDs is 3daW (mnemonic: del a WORD 3 times).

Interesting. I typically use just d3w. 3daW seems to delete 3 lines
for me, the same result as d3<enter>. Another favorite command is d or
c followed by a number and then the right arrow key, for manipulating
letters instead of words.

In any case, I can be way more productive with just a few commands
(maybe 3 or 4 commands or concepts) in Vim than in almost any GUI
editor. In my experience, Vim users almost always find this to be true
for them as well. Vim really hits the sweet spot for productivity and
usability. The only thing about Vim that I find clunky is how code
folding macros work, and also code completion hacks (which I have never
needed anyway).

 

[Mitya Sirenef]

Interesting. I typically use just d3w. 3daW seems to delete 3 lines
for me, the same result as d3<enter>. Another favorite command is d or
c followed by a number and then the right arrow key, for manipulating
letters instead of words.

d3w is a different command, it means delete 3 words *ahead* from cursor.
e.g.:

func() lst[] lst2[ind] foo bar

Now put the cursor on letter 'c' (4th from beginning) and use the
command 3daW, it should delete the 3 WORDs, leaving just the 'foo bar'.

In any case, I can be way more productive with just a few commands
(maybe 3 or 4 commands or concepts) in Vim than in almost any GUI
editor. In my experience, Vim users almost always find this to be true
for them as well. Vim really hits the sweet spot for productivity and
usability. The only thing about Vim that I find clunky is how code
folding macros work, and also code completion hacks (which I have never
needed anyway).

Vim does have a lot of flaws, alas. The highest ones on my list is that
python integration (as a scripting language) is wonky; python can't be
run alongside Vim process; double-escaping is terrible (stuff like
\<lt>blah); process of development is slowed down too much by
over-emphasis on backwards compatibility; the way arguments and counts
are implemented between mappings, commands and functions is byzantine
and way overcomplicated..

That said, Vim is still 1k% better than emacs and 3k% better than
anything else .

It's really odd that large companies like google, microsoft, ibm,
facebook don't all chip in to give Bram a few million to hire a few
people and knock the Vim out into the stratosphere, given how much these
companies' employees used Vim for many hours, daily, to great benefit
for said companies. Oh well.

-m

 

[Wayne Werner]

Interesting. I typically use just d3w. 3daW seems to delete 3 lines
for me, the same result as d3<enter>. Another favorite command is d or
c followed by a number and then the right arrow key, for manipulating
letters instead of words.

Right arrow and not l? Surely you jest!

In any case, I can be way more productive with just a few commands
(maybe 3 or 4 commands or concepts) in Vim than in almost any GUI
editor. In my experience, Vim users almost always find this to be true
for them as well. Vim really hits the sweet spot for productivity and
usability. The only thing about Vim that I find clunky is how code
folding macros work, and also code completion hacks (which I have never
needed anyway).

Yep. That's how I feel. I had used ViEmu in Visual Studio for coding in .NET at
work - but I found that the buffers & macros were more powerful. So now I do
most of my programming in Vim, and only head to VS if I need autocomplete or
some of it's auto-generation tools.

(I'm even writing this email in Vim as my external editor from alpine
-W

 

[Wayne Werner]

On 01/01/2013 02:02 PM, Roy Smith wrote:
That's true with Vim, as well, especially when I'm making a custom
mapping and I can NEVER remember what some combination does, even though
if I actually needed to use it, it pops right out, so to find out, I
have to try it and then I say, "of course, dammit, I use this command 50
times every single day!"; so it's a curious case of one-directional
memory.

I've found writing macros helps me a lot in this regard. I do qa<stuff>q"aP
fairly frequently.

-W

 

[Wayne Werner]

I use Eclipse only because it has PEP 8 and Pylint integration.
Ezio Melotti, core Python developer, said in personal chat, that he uses Kate.
IDEs aren't that useful when coding in Python.

I concur. I think it's because with a language that has 43(?) keywords and
I believe it's 12 different statement types, you can easily fit it all in
your head. What you can't fit in your head is found in the docstrings of
whatever you're using.

Give me an interactive interpreter, vim, and a web browser, and I'm more
than fine.

-W

 

[Mitya Sirenef]

I've found writing macros helps me a lot in this regard. I do
qa<stuff>q"aP
fairly frequently.

-W

But how does that help remember commands?

(I also use recording, but I use qq because it's easier to type
and I have a Q mapping that plays back q register).

-m