Python indentation

[Sateesh]

Hi,
I am a beginner in Python, and am wondering what is it about the indentation
in Python, without which python scripts do not work properly.
Why can't the indentation not so strict so as to give better freedom to the
user?
Is there any plausible reason behind this?

Cheers!
Sateesh

[Mark 'Kamikaze' Hughes]

Antoon Pardon <ap*****@forel.vub.ac.be>
wrote on 12 Jul 2004 11:19:50 GMT:

Op 2004-07-09, Mark 'Kamikaze' Hughes schreef <ka******@kuoi.asui.uidaho.edu>:

This confuses me as to where the loop starts and ends: This confusion may be nothing more than your unfamiliary which
such a construct.

linenum=1
while True:
line = raw_input()
and while line:
print "%05d:%s" % (linenum, line,)
linenum += 1
No, I am quite certain that my confusion is due to the block
indentation aimlessly wandering out, then in, then out again, then in at
the end. And I'm supposed to visually identify that as a single flow of
execution? Bugger that.

I've programmed in dozens of languages. None but BASIC and various
assembly languages have a loop structure quite so ugly as that.
I rarely use post-loop condition testing even in Java where it exists
and you can use assignment as an expression, let alone in Python. When
I do, an explicit if...break at the end works fine.

That is not an argument.

Actually, it is. You just didn't follow it. Python does not have
assignment as expressions, which is a feature that makes post-loop
testing more convenient. Python does have a practical solution to that
kind of loop already.

Python wins now because it is simple, and clear, and there's one
explicitly correct way to solve most tasks.
Before instructions like while, repeat etc
existed, we could use the equivallent of an if combined with a goto
and that worked fine too.

Ah, so your plan is to return to those golden times with equally
incoherent block structures. Excellent plan. Here was me thinking you
had no plan, but you did, and it's a *fine* plan. You go on ahead, I'll
be sure to follow your cutting-edge lead any day now.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

[Mark 'Kamikaze' Hughes]

Jacek Generowicz <ja**************@cern.ch>
wrote on 12 Jul 2004 16:57:40 +0200:

Chris Share <us****@caesium.me.uk> writes:

On Wed, 07 Jul 2004 18:36:05 -0400, Peter Hansen <pe***@engcorp.com> wrote:

> I'm actually pretty inept with vi (or vim), to the point that I don't
> actually know how to configure it for use with Python.

FYI, it's pretty simple...
I use vim for writing python in, with the following options:
:set et
:set tabstop=4

And how do I get it to send the function definition surrounding the
cursor to the Python interpreter with which it is currently
interacting ?
(Only half joking ... if there is a way to make vi(m) provide the same
interactive capabilities that Emacs does, then I would be able to
recommend it to those who insist on using vi in my courses and end up
trailing the rest of the class and slowing us all down.)

Simple way: Select the block of code you want to execute with V and
motion keys, then !python^M

Complex way: :help python, and read.

Vim's considerably faster to work with than emacs (and easier on the
carpal tunnel than escape-meta-alt-control-shift), and Python's
completely hooked in, at least if Vim was compiled that way. You're
just not familiar with it yet.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

[Antoon Pardon]

Op 2004-07-12, Mark 'Kamikaze' Hughes schreef <ka******@kuoi.asui.uidaho.edu>:

Antoon Pardon <ap*****@forel.vub.ac.be>
wrote on 12 Jul 2004 11:19:50 GMT:

Op 2004-07-09, Mark 'Kamikaze' Hughes schreef <ka******@kuoi.asui.uidaho.edu>:

This confuses me as to where the loop starts and ends: This confusion may be nothing more than your unfamiliary which
such a construct.

linenum=1
while True:
line = raw_input()
and while line:
print "%05d:%s" % (linenum, line,)
linenum += 1
No, I am quite certain that my confusion is due to the block
indentation aimlessly wandering out, then in, then out again, then in at
the end. And I'm supposed to visually identify that as a single flow of
execution? Bugger that.

It is as much a single flow of execution as an if elif else.
I've programmed in dozens of languages. None but BASIC and various
assembly languages have a loop structure quite so ugly as that.
What I don't care about uglyness. I care about implementing algorithms.
If an algorithm is best expressed in such a kind of loop I prefer to
implement in such a kind of loop. I rarely use post-loop condition testing even in Java where it exists
and you can use assignment as an expression, let alone in Python. When
I do, an explicit if...break at the end works fine. That is not an argument.

Actually, it is. You just didn't follow it. Python does not have
assignment as expressions, which is a feature that makes post-loop
testing more convenient. Python does have a practical solution to that
kind of loop already.

IMO it is as practical as combining an if with a goto.
Python wins now because it is simple, and clear, and there's one
explicitly correct way to solve most tasks.

No there is not.

Before instructions like while, repeat etc
existed, we could use the equivallent of an if combined with a goto
and that worked fine too.

Ah, so your plan is to return to those golden times with equally
incoherent block structures.

There is nothing incoherent about the proposed structure. A break
or continue in the middle of a loop is more like a goto and less
structured than a loop with multiple exit conditions.

The specific proposed syntax may be ugly, but that doesn't
make the structure incoherent.

--
Antoon Pardon

[David Fraser]

Antoon Pardon wrote:

Op 2004-07-12, Mark 'Kamikaze' Hughes schreef <ka******@kuoi.asui.uidaho.edu>:

Antoon Pardon <ap*****@forel.vub.ac.be>

Before instructions like while, repeat etc
existed, we could use the equivallent of an if combined with a goto
and that worked fine too.

Ah, so your plan is to return to those golden times with equally
incoherent block structures.

There is nothing incoherent about the proposed structure. A break
or continue in the middle of a loop is more like a goto and less
structured than a loop with multiple exit conditions.

The specific proposed syntax may be ugly, but that doesn't
make the structure incoherent.

Not to you perhaps, just to those of us who replied to you in the thread.
Anyway I remain unconvinced, but feel free to produce a language like
this if you want to.

David

[Tuure Laurinolli]

Antoon Pardon wrote:

Op 2004-07-12, Mark 'Kamikaze' Hughes schreef <ka******@kuoi.asui.uidaho.edu>:

Antoon Pardon <ap*****@forel.vub.ac.be>
wrote on 12 Jul 2004 11:19:50 GMT:

Op 2004-07-09, Mark 'Kamikaze' Hughes schreef <ka******@kuoi.asui.uidaho.edu>:

This confuses me as to where the loop starts and ends:

This confusion may be nothing more than your unfamiliary which
such a construct.

linenum=1
while True:
line = raw_input()
and while line:
print "%05d:%s" % (linenum, line,)
linenum += 1
No, I am quite certain that my confusion is due to the block
indentation aimlessly wandering out, then in, then out again, then in at
the end. And I'm supposed to visually identify that as a single flow of
execution? Bugger that.

It is as much a single flow of execution as an if elif else.

Not true.

B1: while True:
B1: line = raw_input()
B2: and while line:
B2: print "%05d:%s" % (linenum, line)
B2: linenum += 1

In this example the B1 part is always executed, and B2 is conditionally
executed dependin on a variable in B1 part.

B1: if v1 == 1:
B1: line = raw_input()
B2: elif v1 == 1:
B2: print "%05d:%s" % (linenum, line)
B2: linenum += 1

In this example the B1 part is always executed, and B2 is never
executed, even though the test of B2 would be true. The indentation
denotes the exclusivity of the blocks.

Block structure like that would be extremely confusing.

I've programmed in dozens of languages. None but BASIC and various
assembly languages have a loop structure quite so ugly as that.

What I don't care about uglyness. I care about implementing algorithms.
If an algorithm is best expressed in such a kind of loop I prefer to
implement in such a kind of loop.

The loop used as example above should use an iterator anyway.

Python wins now because it is simple, and clear, and there's one
explicitly correct way to solve most tasks.

No there is not.

Is not simple and clear or doesn't have one explicitly correct way to
solve most tasks?
There is nothing incoherent about the proposed structure. A break
or continue in the middle of a loop is more like a goto and less
structured than a loop with multiple exit conditions.

The specific proposed syntax may be ugly, but that doesn't
make the structure incoherent.

The syntax isn't just ugly, it's confusing and misleading too.

[Jacek Generowicz]

Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> writes:

Simple way: Select the block of code you want to execute with V and
motion keys, then !python^M
This looks like it sends each code snippet to a new interpreter
.... which is pretty useless for interactive incremental development.
Complex way: :help python, and read.
Sorry, too complex for me. I'll try to find a vim user and try to work
out with him, whether this is of any use.
Vim's considerably faster to work with than emacs
Well that rather depends on which you are more familiar with, wouldn't
you say ?
You're just not familiar with it yet.

And probably never will be. My operating system (Emacs) comes with an
excellent, fully integrated editor. I have no need for vi.

[Steve Lamb]

On 2004-07-15, Jacek Generowicz <ja**************@cern.ch> wrote:

Complex way: :help python, and read.

Sorry, too complex for me. I'll try to find a vim user and try to work
out with him, whether this is of any use.
Nice way to lose credibility. Heaven forbid you'd actually have to *READ*
something. Lemme ask you this, what're you doing here, reading this
newsgroup.
And probably never will be. My operating system (Emacs) comes with an
excellent, fully integrated editor. I have no need for vi.

Uh-huh. So, what're the instructions to boot to Emacs. Don't worry,
unlike you I'm perfectly willing to accept a pointer to something I'd have to
read. Of course knowing full well ya can't boot a computer to Emacs since it
isn't an OS might have something to do with that. I'd say your credibility's
pretty much shot. But then that's par for course coming from am Emacs zealot.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Jacek Generowicz]

Steve Lamb <gr**@despair.dmiyu.org> writes:

On 2004-07-15, Jacek Generowicz <ja**************@cern.ch> wrote:

Complex way: :help python, and read.

Sorry, too complex for me. I'll try to find a vim user and try to work
out with him, whether this is of any use.
Nice way to lose credibility. Heaven forbid you'd actually have to *READ*
something.

Reading is not my problem; navigating through it in vim is.
And probably never will be. My operating system (Emacs) comes with an
excellent, fully integrated editor. I have no need for vi.

Sorry, forgot, this is usenet. I should have added ":-)".
Uh-huh. So, what're the instructions to boot to Emacs. Don't worry,
unlike you I'm perfectly willing to accept a pointer to something I'd have to
read. Of course knowing full well ya can't boot a computer to Emacs since it
isn't an OS might have something to do with that. I'd say your credibility's
pretty much shot. But then that's par for course coming from am Emacs zealot.

Nice try.

Please follow up to alt.religion.editors, if you want to continue in
this vein. If you have something constructive to say, please follow up
here.

But given that you're taking pot-shots at me (and the editor I use),
let me fire one back: Tell me are you deliberately failing to notice
the humour of my statement, or has using vi damaged your brain so much
that you genuinely are too stupid to see it as such. I would normally
think it's because vi users are too stupid in general, were it not for
the fact that it is vi users who invented the "I want an editor, not
an operating system" argument to level against Emacs. Your credibility
as a vi bigot has been pulverized. You really use ed, don't you ? :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) (enough smileys
for you? got the message?)

Now that we've got that bit of fun out of the way, could we, please,
return to the scheduled programme ?

[Steve Lamb]

On 2004-07-15, Jacek Generowicz <ja**************@cern.ch> wrote:

Reading is not my problem; navigating through it in vim is.
Huh. vim was actually exceptionally easy for me to pick up on. Maybe the
problem lay with you?
Please follow up to alt.religion.editors, if you want to continue in
this vein. If you have something constructive to say, please follow up
here.
Ah. I see. You get to be a zealot here but someone takes you to task and
they have to go elsewhere. Howsabout *you* be constructive first?
Tell me are you deliberately failing to notice the humour of my statement,
Might've been funny about 10 years ago when it was coined. Not it is just
trite. Sad part is many emacs zealots really do say that and mean it.
I would normally think it's because vi users are too stupid in general, were
it not for the fact that it is vi users who invented the "I want an editor,
not an operating system" argument to level against Emacs. Your credibility
as a vi bigot has been pulverized.

Too bad I'm not a vi bigot, huh? Let's see I've recently mentioned
kdevelop3 and boa-constructor to someone, use boa-constructor myself, have
used dozens of editors in the past.

An no, wasn't enough smileys because every single was was disingenuous.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Mark 'Kamikaze' Hughes]

Jacek Generowicz <ja**************@cern.ch>
wrote on 15 Jul 2004 09:18:09 +0200:

Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> writes:

Simple way: Select the block of code you want to execute with V and
motion keys, then !python^M This looks like it sends each code snippet to a new interpreter

It sends the entire selected block to a new interpreter, yes. Not
each line to a different interpreter, if that's what you're trying to
say.
... which is pretty useless for interactive incremental development.
Not so. I do that all the time, and it's extremely useful for quickly
getting a value or for complex text manipulation. I often do things
like:

foo="""
sometext
"""
results = dostuff(foo)
print results

Complex way: :help python, and read.

Sorry, too complex for me. I'll try to find a vim user and try to work
out with him, whether this is of any use.

So rather than read a brief, carefully-written article which is
included in Vim itself, you'd rather waste the time of someone else and
make them recite the same information from memory? Inconsiderate much?

Vim's considerably faster to work with than emacs

Well that rather depends on which you are more familiar with, wouldn't
you say ?

You know, I might say that...

You're just not familiar with it yet.

OH, LOOK, I DID! HOW DID YOU KNOW? Don't be a twat.
And probably never will be. My operating system (Emacs) comes with an
excellent, fully integrated editor. I have no need for vi.

Huh. I always thought it was an incredibly slow and awkward Lisp
interpreter, with a fairly weak shell (it is not an OS), and a really
lousy editor with too many modifier keys on top. Since I've got Python,
Linux and FreeBSD, and Vim with Python scripting compiled in, it has
nothing to offer me.

But you asked how Vim does that, and in a snarky way implying that it
couldn't. You were wrong, and now you're upset at being corrected. If
you had the slightest trace of manners you'd say "Thanks for the
information, I'll read that". Alas.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

[Steve Lamb]

On 2004-07-15, Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> wrote:

Huh. I always thought it was an incredibly slow and awkward Lisp
interpreter, with a fairly weak shell (it is not an OS), and a really
lousy editor with too many modifier keys on top. Since I've got Python,
Linux and FreeBSD, and Vim with Python scripting compiled in, it has
nothing to offer me.

That's the part that always gets me. This is the Python newsgroup. Many
of us are here because we program in Python. Quite a few of those actually
like and prefer Python to other languages. So why, then, do Emacs people put
forth an editor that, to customize, one must learn Lisp. I don't know Lisp.
However from the many Lisp/Python discussions here (charitable description, I
know) I do know I don't want to learn Lisp in general and certainly not just
to tweak my editor around.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Christopher T King]

On 15 Jul 2004, Mark 'Kamikaze' Hughes wrote:

Jacek Generowicz <ja**************@cern.ch>
wrote on 15 Jul 2004 09:18:09 +0200:

vim sux0rz!!1

EMACS sux0rz!!1

<singing> Why can't we be friends? Why can't we be friends? </singing>

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> "Steve" == Steve Lamb <gr**@despair.dmiyu.org> writes:

Steve> So why, then, do Emacs people put forth an editor that, to
Steve> customize, one must learn Lisp. I don't know Lisp. However
Steve> from the many Lisp/Python discussions here (charitable
Steve> description, I know) I do know I don't want to learn Lisp in
Steve> general and certainly not just to tweak my editor around.

I don't have a problem with Lispdom as a whole (though I dislike the
fragmentation of the community and many dialects both, as well as the
write-your-own-ad-hoc-language principle), but ELisp - Emacs Lisp - is
just a horrible abomination of a language if you ask me. So why do I
bother with it? Well, because it makes programming my editor very easy
indeed once the initial hurdle has been overcome. I've never seen a
language with more warts, but it gets the job done. That, and it's
documented quite well... which is more than can be said of most of the
code that's actually _written_ in the language, unfortunately.

There are (usually) hooks for everything one can imagine, making it
pretty simple to tweak the editor and the applications written for/in
it in any number of ways. For instance, I use Emacs, more specifically
Gnus, for mail and news, and in less than 10 lines of code, I got it
to prompt me whether to encrypt or digitally sign all outgoing
messages. Moreover, I didn't have to change any existing code, just
add a bit of my own. And just about everything can be changed if one
should want. Perhaps the best example of this is Viper mode, which
basically gives you a vi implementation in Emacs. Apparently there are
vi people who want the power of Emacs (in the programmability sense)
enough that they're willing to put up with the beast. :-)

I caution you that I am not all that intimate with the different vi
implementations, and even less their programmability. I can get by
well enough with vi, but have never attempted to program any of the
different flavours, so I cannot make any comparisons. I only hope to
answer your question without further fanning the flames.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD26wAACgkQYu1fMmOQldXs3wCgnmTv6Qa4fb JESne+H1Qwo713
51kAn0QORY3hu8m2EDXxRj3Hq9+1isRq
=QsIf
-----END PGP SIGNATURE-----

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> "Mark" == Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> writes:

Mark> Jacek Generowicz <ja**************@cern.ch> wrote on 15 Jul 2004
Mark> 09:18:09 +0200: Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> writes:

Simple way: Select the block of code you want to execute with V
and motion keys, then !python^M

This looks like it sends each code snippet to a new interpreter

Mark> It sends the entire selected block to a new interpreter, yes.
Mark> Not each line to a different interpreter, if that's what you're
Mark> trying to say.

I think what he was trying to say is this: for each time you send a
code snippet to the interpreter, a new interpreter is started, and
afterwards you won't have the same interpreter and its state to play
with.

With Emacs' Python mode, you can run a so-called inferior Python
process, which is just to say that you have an interpreter running in
Emacs. You can then keep sending code to this same interpreter. In my
experience, this is immensely practical. When writing a class, for
instance, you can create an instance and do all the necessary set-up,
and without needing to give thought to repeating said set-up, you can
alter method definitions etc. on-the-fly. I get the impression that
with the mentioned approach in vi, you're still stuck with the full
write-run-debug cycle, whereas the 'inferior Python process' approach
takes a lot of the tediousness out of the run part of the cycle. The
same is true for all the other languages with an interactive
interpreter that I've tried. When I've not had Emacs at hand for
hacking Python, this is what I've missed most of all.

I should be greatly surprised if it weren't possible to do something
similar in at least Vim.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD27+EACgkQYu1fMmOQldUQGwCdFhwfQOPJKB 7hg/ZgdvQjO34A
j5cAn2ICfAgyzzQ1r0v/fFb1x0StaJTp
=ESjc
-----END PGP SIGNATURE-----

[Mark 'Kamikaze' Hughes]

Steve Lamb <gr**@despair.dmiyu.org>
wrote on Thu, 15 Jul 2004 18:31:57 GMT:

On 2004-07-15, Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> wrote:

Huh. I always thought it was an incredibly slow and awkward Lisp
interpreter, with a fairly weak shell (it is not an OS), and a really
lousy editor with too many modifier keys on top. Since I've got Python,
Linux and FreeBSD, and Vim with Python scripting compiled in, it has
nothing to offer me. That's the part that always gets me. This is the Python newsgroup. Many
of us are here because we program in Python. Quite a few of those actually
like and prefer Python to other languages. So why, then, do Emacs people put
forth an editor that, to customize, one must learn Lisp. I don't know Lisp.

Well, there are other non-Pythonic editors that can work with Python.
JEdit's very nice, and it's Java, with Beanshell scripting. Kate's
reasonable, and it's a C++ app with no scripting that I know of. There
are even Eclipse (Java IDE) plug-ins for Python (see also
<http://www.jtauber.com/blog/2004/04/05/eclipse_is_next_emacs>).

Emacs fans like it because if you're willing to use Lisp, it's
programmable, and it did that back in the day when that was very rare.
Now scripting is not unusual, and you can choose a better editor with a
scripting language you like more.
However from the many Lisp/Python discussions here (charitable description, I
know) I do know I don't want to learn Lisp in general and certainly not just
to tweak my editor around.

I don't understand why, but many Lispers zealously over-evangelize
their language to non-Lispers and yet don't seem to write that much real
software in it.

This isn't just a random opinion, it's backed by rigorous scientific
research (i.e., a few minutes fooling around with freshmeat.net):
<http://kuoi.asui.uidaho.edu/~kamikaze/read.php?topic=News&id=11>

I put my code where my mouth is. I write a ton of Java code, but
Python's a close second--mostly for smaller tools and one-off scripts,
but also for large apps like my Umbra CRPG.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

[Mark 'Kamikaze' Hughes]

Christopher T King <sq******@WPI.EDU>
wrote on Thu, 15 Jul 2004 14:37:15 -0400:

On 15 Jul 2004, Mark 'Kamikaze' Hughes wrote:

Jacek Generowicz <ja**************@cern.ch>
wrote on 15 Jul 2004 09:18:09 +0200:

> vim sux0rz!!1

EMACS sux0rz!!1

<singing> Why can't we be friends? Why can't we be friends? </singing>

<http://hackingthemainframe.com/coppermine/wm.php?pid=9891&mode=normal>

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

[Mark 'Kamikaze' Hughes]

Martin Christensen <kn************************@gvdnet.dk>
wrote on Thu, 15 Jul 2004 22:58:10 +0200:

I should be greatly surprised if it weren't possible to do something
similar in at least Vim.

Thus `:help python`, which tells how to use the built-in interactive
interpreter. Jacek took poorly to my suggestion to use Vim's help
system to learn how Vim works, but there's no point in repeating
information so easily available.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

[Michele Simionato]

Jacek Generowicz <ja**************@cern.ch> wrote in message news:<ty*************@pcepsft001.cern.ch>...

This looks like it sends each code snippet to a new interpreter
... which is pretty useless for interactive incremental development.

Using emacs with Lisp or Scheme you can send a block of code to the
interpreter and do interactive incremental developement with a few
keystrokes. I have no idea of how to do the same in Python, so I just
open a lower buffer and I cut and paste by hand the function I am testing.
Is there a better way? You seem to imply there is ...
Michele Simionato (a rather poor emacs user ;)

[Michele Simionato]

Following up my previous message ...

My Python-mode has a "run inferior Python" menu (C-c!) but for some reason it
does not work ("Process Python exited abnormally with code 1"). If it worked,
I suppose I could highlight a snippet of code and send it to the interpreter.

I guess I tried C-c! when I first discovered Python, it didn't worked, and I
forgot completely about this feature. It is something I didn't need really
(just had small scripts). However, if you have large programs and large
initialization times the interactive incremental development strategy is a
big win, since you do not reinitialize everything each time you add a new line
of code.

Is there a way to get any info about why the Python process failed? (did I mention
I am a rather poor emacs user? ;)

Michele Simionato

[Jacek Generowicz]

Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> writes:

Jacek Generowicz <ja**************@cern.ch>
wrote on 15 Jul 2004 09:18:09 +0200:

Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> writes:

Simple way: Select the block of code you want to execute with V and
motion keys, then !python^M

This looks like it sends each code snippet to a new interpreter

It sends the entire selected block to a new interpreter, yes. Not
each line to a different interpreter, if that's what you're trying to
say.

Don't be a moron.

... which is pretty useless for interactive incremental development.

Not so. I do that all the time, and it's extremely useful for quickly
getting a value or for complex text manipulation.

Emacs allows me to interact with a continuously live instance of the
Python interpreter. This enables me to type code directly in the
interactive Python REPL (thereby updating its state), it allows me to
send the contents of whole Emacs buffers to the very same instance of
the intepreter (thereby updating its state), and it allows me to send
selections of Emacs buffers to the very same instance of the
interpreter (thereby updating its state). This offeres a very powerful
_incremental_ development environment.

By comparison, sending a whole block to a _new_ interpreter _is_
pretty useless.

Sorry, too complex for me. I'll try to find a vim user and try to work
out with him, whether this is of any use.

So rather than read a brief, carefully-written article which is
included in Vim itself, you'd rather waste the time of someone else and
make them recite the same information from memory?

As you observe, it is included in vim itself. When I try to read it,
it beeps at me; I am not a vi user. Therefore I propose to go to
someone who

a) _is_ a vi user (so the damn thing won't beep at him)

b) cares about incremental programming in Python with vi

c) is more likely to understand what it means.

If, together, we can work something out, it would be _useful_ to said
person (and many others).

So quit pratting around with the editor war crap, and the ad-hominem
bullshit. I am trying to find out how to make life easier for people
who attend my Python course and who prefer using vi to Emacs
.... because I have no desire to convent happy vi users to Emacs. There
is no point in trying to persuade me to use vi, because I am
extatically happy with the editor I use.

If you want to help me help vi users, and have the knowledge, then
please contribute it ... otherwise sod the $%^& off. Incremental
Python development in vi is of no personal interest to me, and if I
have to put up with your moronic insults to get at it, it becomes less
likely that I will bother ... so a few more vi users will continue to
be less productive that they might be.

[Jacek Generowicz]

mi***************@gmail.com (Michele Simionato) writes:

"Process Python exited abnormally with code 1" Is there a way to get any info about why the Python process failed?

You could start by looking at the python interpreter Emacs is trying
to run:

C-h v py-python-command RET

or

M-x describe-variable RET py-python-command RET
If that looks dodgy, try changing it to something sensible. One way to
do that is

M-x customize-group RET python RET

.... and then do the mousey-clickety thing that seems relevant.

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> "Michele" == Michele Simionato <mi***************@gmail.com> writes:

Michele> Is there a way to get any info about why the Python process
Michele> failed? (did I mention I am a rather poor emacs user? ;)

In addition to Jacek's tips, you can also check the *Messages* buffer
for clues. That's always a good place to start. Oh, and make sure that
the Python executable is in your path. That bit is not entirely
unimportant. :-)

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD3rTQACgkQYu1fMmOQldU+sQCeJET5eKVWzm o+N9KefyfxlOLv
LYEAnjDQe+IEto5jYhy/5YqxvD/5bbAS
=KgLH
-----END PGP SIGNATURE-----

[Steve Lamb]

On 2004-07-16, Jacek Generowicz <ja**************@cern.ch> wrote:

Don't be a moron.
First step, read the help. .... Oh sorry, forgot.
Emacs allows me to interact with a continuously live instance of the
Python interpreter.

You know, oddly enough this isn't something I demand of my editors. With
things like screen, konsole, multiple rxvts or even plain old ALT-F1, ALT-F2 I
get the exact same functionality. It's called learning how to use the tools
given instead of insisting on having everything bolted onto one large
bloatware application.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Mark 'Kamikaze' Hughes]

Jacek Generowicz <ja**************@cern.ch>
wrote on 16 Jul 2004 10:58:59 +0200:

Don't be a moron.
If you want to help me help vi users, and have the knowledge, then
I already did. You're just too stupid to actually use that help.
please contribute it ... otherwise sod the $%^& off. Incremental
Python development in vi is of no personal interest to me, and if I
have to put up with your moronic insults to get at it, it becomes less

I gave you useful information, and you spat in my face. Go screw
yourself, cretin.

<http://kuoi.asui.uidaho.edu/~kamikaze/doc/plonk.html>

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

[Jacek Generowicz]

Steve Lamb <gr**@despair.dmiyu.org> writes:

Emacs allows me to interact with a continuously live instance of the
Python interpreter.
You know, oddly enough this isn't something I demand of my editors.
With things like screen, konsole, multiple rxvts or even plain old
ALT-F1, ALT-F2 I get the exact same functionality.

Of course, and with a Turing machine I get exactly the same
functionality as I do in Python.
It's called learning how to use the tools given instead of insisting
on having everything bolted onto one large bloatware application.

You know, I always believed that vim was an excellent tool, the tool
of choice of many intelligent power-users.

The contributions of you and your Kamikaze chum are the first instance
of something managing to make me start questioning that belief.

Good riddance.

[Michele Simionato]

Jacek Generowicz <ja**************@cern.ch> wrote in message news:<ty*************@pcepsft001.cern.ch>...

mi***************@gmail.com (Michele Simionato) writes:

"Process Python exited abnormally with code 1"

Is there a way to get any info about why the Python process failed?

You could start by looking at the python interpreter Emacs is trying
to run:

C-h v py-python-command RET

Thanks Jacek, this did the job. py-python-command was set to
"/usr/bin/env python"
and Mandrake was not happy about that, for some reason.
I solved setting py-python-command to "/usr/bin/python". Now it works.
Still, it is not as handy as in Scheme/Lisp where I can execute the block
by just giving C-x C-e after the last parens (ah, how bad Python lack of
parens ;)

BTW, if someone needs tips for programming Scheme with emacs my suggestion
is to try quack.el by Neil van Dyke (google is your friend).
Michele Simionato

[Jacek Generowicz]

mi***************@gmail.com (Michele Simionato) writes:

Thanks Jacek, this did the job. py-python-command was set to
"/usr/bin/env python"
and Mandrake was not happy about that, for some reason.
I solved setting py-python-command to "/usr/bin/python". Now it works.
Cool.
Still, it is not as handy as in Scheme/Lisp where I can execute the block
by just giving C-x C-e after the last parens (ah, how bad Python lack of
parens ;)

Indeed ;-)

C-M-x is a poor-man's alternative which does the job in a limited set
of cases, in Python ... limited, but still useful.

[Jacek Generowicz]

I'd like to apologize for posting previous message to the group at
large. I should have refrained from posting to this thread a while
ago, when it became clear that nothing constructive would come of it.

[Steve Lamb]

On 2004-07-16, Jacek Generowicz <ja**************@cern.ch> wrote:

I'd like to apologize for posting previous message to the group at
large. I should have refrained from posting to this thread a while
ago, when it became clear that nothing constructive would come of it.

IE, from your very first post since you're the one being completely
unconstructive? :P

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Lonnie Princehouse]

> I think what he was trying to say is this: for each time you send a

code snippet to the interpreter, a new interpreter is started, and
afterwards you won't have the same interpreter and its state to play
with.

If you use :!python, then of course you're starting a new python
session each time, because it's just running the interpreter via
system()...

BUT if you use :python, it will keep a persistent embedded interpreter
sitting around. Try it:

:python foo=5
:python print foo

Reading the help file on :python is highly recommended! The vim
module* is really spiffy.

*only works from inside the embedded interpreter, e.g. :python import
vim
Also-- I don't know of any code that does it, but it would be pretty
straight forward to (1) grab the vim cursor location (2) parse the
buffer into an AST (3) figure out where the cursor is inside the AST
and (4) do clever things like name completion, show function
arguments, and even interact with the debugger.

[Ville Vainio]

>>>>> "Jacek" == Jacek Generowicz <ja**************@cern.ch> writes:

Jacek> large. I should have refrained from posting to this thread
Jacek> a while ago, when it became clear that nothing constructive
Jacek> would come of it.

From vi vs. emacs discussion? Surely, you must jest ;-).
--
Ville Vainio http://tinyurl.com/2prnb

[G. S. Hayes]

Martin Christensen <kn************************@gvdnet.dk> wrote in message news:<87************@gvdnet.dk>...

Mark> It sends the entire selected block to a new interpreter, yes.
Mark> Not each line to a different interpreter, if that's what you're
Mark> trying to say.

I think what he was trying to say is this: for each time you send a
code snippet to the interpreter, a new interpreter is started, and
afterwards you won't have the same interpreter and its state to play
with.

With Emacs' Python mode, you can run a so-called inferior Python
process, which is just to say that you have an interpreter running in
Emacs. You can then keep sending code to this same interpreter. [SNIP] I should be greatly surprised if it weren't possible to do something
similar in at least Vim.

http://www.vim.org/scripts/script.php?script_id=165

The vimsh package allows you to run a shell under Vim; among other
things, you can run python under this shell. I do this all the time,
with macros to run selected line(s) from my python code in the Python
window, maintaining state in between sending lines through Python--so
running "i=100", then going back to editing and later running "i=i+1",
"print i" will print 101.

This runs seperately from Vim's built-in Python interpreter, so you
don't have to worry about namespace collisions, etc (in fact, you can
easily have several vimsh python windows each running their own
interpreters, just like in emacs).

vimsh doesn't have smart terminal emulation (just dumb ptys), though,
so you can run line-oriented programs fine this way, but you can't run
e.g. curses or advanced termcap programs in any useful way. Not a big
deal for me.

Sumner

[Eli Stevens (WG.c)]

Jacek Generowicz wrote:

You really use ed, don't you ? :-)

Real Men(tm) don't use ed, they use cat.

# cat > hello.py
prn^D

# cat > hello.py
print "Hello, Wolr^D

# cat > hello.py
print "Hello, World!"
^D

I've actually done this, but not for files that long. ;)

Eli

--
Give a man some mud, and he plays for a day.
Teach a man to mud, and he plays for a lifetime.
WickedGrey.com uses SpamBayes on incoming email:
http://spambayes.sourceforge.net/
--

[Roy Smith]

In article <ma*************************************@python.or g>,
"Eli Stevens (WG.c)" <li*****@wickedgrey.com> wrote:

Jacek Generowicz wrote:

You really use ed, don't you ? :-)

Real Men(tm) don't use ed, they use cat.

# cat > hello.py
prn^D

# cat > hello.py
print "Hello, Wolr^D

# cat > hello.py
print "Hello, World!"
^D

I've actually done this, but not for files that long. ;)

I once knew a guy who linked /dev/tty to /dev/tty.c, then he could do
"cc /dev/tty.c" and type in a C program to compile.

[Steve Lamb]

On 2004-07-17, Roy Smith <ro*@panix.com> wrote:

I once knew a guy who linked /dev/tty to /dev/tty.c, then he could do
"cc /dev/tty.c" and type in a C program to compile.

Of course now there's tcc. :)

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Dan Sommers]

On Fri, 16 Jul 2004 22:26:13 -0400,
Roy Smith <ro*@panix.com> wrote:

In article <ma*************************************@python.or g>,
"Eli Stevens (WG.c)" <li*****@wickedgrey.com> wrote:

Jacek Generowicz wrote:

> You really use ed, don't you ? :-)

Real Men(tm) don't use ed, they use cat.

# cat > hello.py
prn^D

# cat > hello.py
print "Hello, Wolr^D

# cat > hello.py
print "Hello, World!"
^D

I've actually done this, but not for files that long. ;)

I once knew a guy who linked /dev/tty to /dev/tty.c, then he could do
"cc /dev/tty.c" and type in a C program to compile.

For short programs on many common architectures, use this:

gzip -d >a.out

For longer programs, revert back to this (because the string tables are
too big to commit to wetware):

cat >a.out

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>
Never play leapfrog with a unicorn.

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> "Steve" == Steve Lamb <gr**@despair.dmiyu.org> writes:

Emacs allows me to interact with a continuously live instance of
the Python interpreter.

Steve> You know, oddly enough this isn't something I demand of my
Steve> editors. With things like screen, konsole, multiple rxvts or
Steve> even plain old ALT-F1, ALT-F2 I get the exact same
Steve> functionality. It's called learning how to use the tools given
Steve> instead of insisting on having everything bolted onto one large
Steve> bloatware application.

You know, it strikes me as odd that you are so quick to dismiss the
usefulness of something you have not tried in practice. I have tried
it, and I very much miss it when it's not there.

As for the whole 'bolted on' thing... being able to interact with
another process is useful for a wide range of things, as I'm sure any
purist vi user will agree. Also vi can run such processes, sending
input to them and doing something with the output. This particular
feature of Emacs' is simply having input to and output from the
process in the same buffer, and it's reused widely. I've already sung
the praise of its usefulness for interactive programming in Python and
similar languages, but I've also found it invaluable e.g. for
interacting with SQL databases (anyone who've used Oracle's sqlplus
can surely quickly be persuaded of this), where the output is
something that you'll often want to fiddle around with in your editor
anyway. Well, at least I do.

Now, if it's possible to run a Python process separately from vi which
you can send code snippets to anytime, then you can conveniently have
your small, separated tools and the functionality that Jacek and I are
so fond of at the same time.

As for the whole bloatware argument, I think it's getting a bit
ridiculous. Fine, I build Python into Vim, and I'm all for that. I'm
sure that means that I can hook into a _lot_ of Python code that way,
thus making Vim every bit as much bloatware as Emacs is. Seriously, if
you want a slim Emacs, don't load all the things you won't need. Sure,
you'll never cut Emacs down to the minimum size of any vi
implementation, I'm sure, but it was never designed for extreme
compactness. At the computer science department I very recently
graduated from (yay me!), Emacs was used significantly more than vi on
our application servers, and none of our application servers have ever
had scarceness of resources because of it. Sure, on a mobile phone or
PDA with very limited resources, I might start to worry about size,
but with even relatively low-end machines having at least 256 MB main
memory these days, fussing over a couple of megs for something as
important as the text editor one uses, which is probably in the top
three of the most important programs people like us use, is nothing
but pedantry. If that's what's going to tip over your box, it's time
to put the old 386 out of its misery. Hell gVim compiled with Python
support alone takes up 7.5 MB at startup on my box compared to Emacs'
8.2 MB with my own 'basic' stuff loaded (which is quite a lot for
some). Is it really a big deal? It certainly isn't to me.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD4R+AACgkQYu1fMmOQldWB8ACg5GMNmMhC2I ALb62dhMlu8dRh
hJwAnjengArZINHPWOIYcXRuIqcFT+pu
=32eg
-----END PGP SIGNATURE-----

[Steve Lamb]

On 2004-07-16, Martin Christensen <kn************************@gvdnet.dk> wrote:

You know, it strikes me as odd that you are so quick to dismiss the
usefulness of something you have not tried in practice. I have tried
it, and I very much miss it when it's not there.

Who said I've never tried it?

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Jacek Generowicz]

fi**************@gmail.com (Lonnie Princehouse) writes:

I think what he was trying to say is this: for each time you send a
code snippet to the interpreter, a new interpreter is started, and
afterwards you won't have the same interpreter and its state to play
with.

If you use :!python, then of course you're starting a new python
session each time, because it's just running the interpreter via
system()...

BUT if you use :python, it will keep a persistent embedded interpreter
sitting around. Try it:

:python foo=5
:python print foo

OK, so this could be one way of emulating the REPL (but I hope that
there might be a more convenient way).
Reading the help file on :python is highly recommended!
I don't doubt that for one second ... but how do you do it?

[ ... time passes ... ]

OK, I've tried it again, and discovered that you can scroll beyond the
bottom of the screen ... and then some actual information
appears. Phew, what a relief! (On my previous attempt, I thought that
that the |python-commands| &co next to the 5 numbered titles were
links of some sort, and everything I tried resulted in frustration.)

So, am I right in thinking that it's just a single chunk of text, with
some colouring ... which one is supposed to read by scrolling up and
down, or is there more to it (it _looks_ as if there is ...) ?

I guess I really should find the time to go through this with an
interested vim user.
*only works from inside the embedded interpreter

Hmm, that makes me slightly nervous ... do you get to see some
vi-specefic inerpreter state ... with which you might clash ?

[Jacek Generowicz]

sj*******@yahoo.com (G. S. Hayes) writes:

http://www.vim.org/scripts/script.php?script_id=165

The vimsh package allows you to run a shell under Vim; among other
things, you can run python under this shell. I do this all the time,
with macros to run selected line(s) from my python code in the Python
window, maintaining state in between sending lines through Python--so
running "i=100", then going back to editing and later running "i=i+1",
"print i" will print 101.

This runs seperately from Vim's built-in Python interpreter, so you
don't have to worry about namespace collisions, etc (in fact, you can
easily have several vimsh python windows each running their own
interpreters, just like in emacs).

vimsh doesn't have smart terminal emulation (just dumb ptys), though,
so you can run line-oriented programs fine this way, but you can't run
e.g. curses or advanced termcap programs in any useful way. Not a big
deal for me.

Sounds promising. Thanks for the pointer.

Just one thing (and please remember that I do not use vim, so much of
this is alien to me) ... I heard it mentioned a number of times that
Python must be compiled into vim, and in the link you posted the words
"for python enabled [g]vim" appear. Is vim typically Python-enabled
out of the box, or does the user have to compile it in? The problem is
that we have a lot of centrally managed software here, and if users
will need to replace the standard vim with their own version, then
that is likely to lose a lot of potential users.

[G. S. Hayes]

Jacek Generowicz <ja**************@cern.ch> wrote in message news:<ty*************@pcepsft001.cern.ch>...

Just one thing (and please remember that I do not use vim, so much of
this is alien to me) ... I heard it mentioned a number of times that
Python must be compiled into vim, and in the link you posted the words
"for python enabled [g]vim" appear. Is vim typically Python-enabled
out of the box, or does the user have to compile it in?

Typically? I don't know. Red Hat Linux (including Fedora and
Enterprise Server) includes Python support in Vim by default in the
regular vim package which installs as /usr/bin/vim (but not in the
vim-minimal package which installs as /bin/vi).

To check on your machines, fire up vim and try:

:python print "test"

and see if you see the word "test" or an error message. Or do
:version and look for either +python or -python (you want +python).

Sumner

[paolo veronelli]

On 19 Jul 2004 09:03:42 +0200, Jacek Generowicz <ja**************@cern.ch>
wrote:

Just one thing (and please remember that I do not use vim, so much of
this is alien to me) ... I heard it mentioned a number of times that
Python must be compiled into vim, and in the link you posted the words
"for python enabled [g]vim" appear. Is vim typically Python-enabled
out of the box, or does the user have to compile it in? The problem is
that we have a lot of centrally managed software here, and if users
will need to replace the standard vim with their own version, then
that is likely to lose a lot of potential users.

freebsd 5.2.1 doesn't......
--
.....lotta dura per la verdura

[G. S. Hayes]

Jacek Generowicz <ja**************@cern.ch> wrote in message news:<ty*************@pcepsft001.cern.ch>...

OK, I've tried it again, and discovered that you can scroll beyond the
bottom of the screen ... and then some actual information
appears. Phew, what a relief! (On my previous attempt, I thought that
that the |python-commands| &co next to the 5 numbered titles were
links of some sort, and everything I tried resulted in frustration.)

The bits between bars are links to tags. Use Ctrl-] to follow them
and Ctrl-t to pop back to where you followed from.

For more info, ":help tags"

*only works from inside the embedded interpreter

Hmm, that makes me slightly nervous ... do you get to see some
vi-specefic inerpreter state ... with which you might clash ?

If you use the embedded interpreter you can certainly clash with the
vim internals, that's why I use the vimsh approach (also, using vimsh
allows you to restart the interpreter without restarting the editor).

[François Pinard]

[G. S. Hayes]

[Jacek Generowicz]

Is vim typically Python-enabled out of the box, or does the user
have to compile it in?

Typically? I don't know.

If I remember well for SuSE, /bin/vi does not have Python enable, but
/usr/bin/gvim does.

--
François Pinard http://www.iro.umontreal.ca/~pinard

[Steve Lamb]

On 2004-07-19, G. S. Hayes <sj*******@yahoo.com> wrote:

Typically? I don't know. Red Hat Linux (including Fedora and
Enterprise Server) includes Python support in Vim by default in the
regular vim package which installs as /usr/bin/vim (but not in the
vim-minimal package which installs as /bin/vi).

On Debian it is compiled in the vim-python package but not in the vim
package. I don't believe either is installed by default so it is up to the
end user to choose which one he wishes installed.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Lonnie Princehouse]

> OK, so this could be one way of emulating the REPL (but I hope that

there might be a more convenient way).
Yeah, a complete interpreter is lurking in the background, but it _is_
difficult to interact with. I use it mostly as a way to script VIM,
but not on the fly; I just keep a bunch of handy functions in a module
(called "vimfu") which gets imported by .vimrc. The vim module
provides a nice pythonic way to manipulate buffers, selected regions,
etc.

You can do all of this stuff with LISP in Emacs, but Python works
pretty well for scripting VIM.

Reading the help file on :python is highly recommended!

So, am I right in thinking that it's just a single chunk of text, with
some colouring ... which one is supposed to read by scrolling up and
down, or is there more to it (it _looks_ as if there is ...) ?

It is indeed arcane. Ctrl-] will follow the colored links.

I guess I really should find the time to go through this with an
interested vim user.

*only works from inside the embedded interpreter

Hmm, that makes me slightly nervous ... do you get to see some
vi-specefic inerpreter state ... with which you might clash ?

I doubt that is an issue. The vim module interacts directly with a
VIM session, which is why I don't think it can be run outside of VIM.
You could put it in your PYTHONPATH and give it a shot, though-- I
haven't actually tried =)

[Jacek Generowicz]

sj*******@yahoo.com (G. S. Hayes) writes:

To check on your machines, fire up vim and try:

:python print "test"

and see if you see the word "test" or an error message. Or do
:version and look for either +python or -python (you want +python).

Looks like our standard version has it enabled.

Thanks.

[Jacek Generowicz]

sj*******@yahoo.com (G. S. Hayes) writes:

The bits between bars are links to tags. Use Ctrl-] to follow them
and Ctrl-t to pop back to where you followed from.

For more info, ":help tags"

Aaaah, great. Thanks. (Lonnie too.)