Python indentation

[Mark 'Kamikaze' Hughes]

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.

 

[Antoon Pardon]

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.

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.

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.

 

[David Fraser]

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]

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.

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.

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.

 

[Mark 'Kamikaze' Hughes]

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

Nyet.

if A:
B
elif C:
D
else:
E

This structure looks very similar to the "and while" proposal, but is
totally different, since B, D, and E are in separate flows of execution.

What I don't care about uglyness.

We can stop right there, then. One of Python's major attractions to
me, at least, is that the most readable, pleasant code is almost always
the most correct. This means that in 6 months or 6 years when I come
back to my code, I can pick it up immediately. I care very much about
ugliness. Programming in Python means never feeling ashamed of your
code.

At least a few other people share this principle:
python -c "import this"

No there is not.

I'm sorry, your time is up. If you wish to continue the argument,
please pay the receptionist 5 pounds.

 

[Jacek Generowicz]

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]

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.

 

[Jacek Generowicz]

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.

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]

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.

 

[Mark 'Kamikaze' Hughes]

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

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?

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

You know, I might say that...

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.

 

[Steve Lamb]

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.

 

[Christopher T King]

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

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

 

[Martin Christensen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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+EACgkQYu1fMmOQldUQGwCdFhwfQOPJKB7hg/ZgdvQjO34A
j5cAn2ICfAgyzzQ1r0v/fFb1x0StaJTp
=ESjc
-----END PGP SIGNATURE-----

 

[Mark 'Kamikaze' Hughes]

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.

 

[Mark 'Kamikaze' Hughes]

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

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

 

[Mark 'Kamikaze' Hughes]

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.

 

[Michele Simionato]

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]

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.

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.

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.