[Q] Perl vs. Python
Navindra Umanee
At one point in cyberspacetime
(actually 19 Jun 1998 00:44:25 GMT in comp.os.linux.advocacy),
Christopher Browne <cbbr...@news.hex.net> wrote:
> If the best criticism that you can come up with is that "semantic
> meaning of the language alledgedly *depends* on whitespace," then I
> would suggest you look for more substantial reasons, and don't just
> "allege" such accusations. (McGill is supposed to be one of the better
No, I don't know anything about python. I was referring to the
comments in a previous post, hence the "alledgedly". I don't know
anything about perl either for that matter.
Navin
--
"Evolution is not only about survival, it's about domination." --Prey
Michael Scharf
On 18 Jun 1998 05:01:20 GMT, Navindra Umanee <navi...@cs.mcgill.ca
> wrote:
> Practically all decent compilers ignore whitespace these days (in that
> it doesn't matter how much or how little whitespace you have, as long
> as the compiler can make out the tokens). What I'm saying is stupid
> about Python is that the semantic meaning of the language alledgedly
> *depends* on whitespace.
Even C/C++ *is* whitespace sensitive:
#define X \
int X;
put a blank after the \ and you see the difference....
Michael
--
''''\ Michael Scharf
` c-@@ TakeFive Software
` > http://www.TakeFive.com
\_ V mailto:Michael...@TakeFive.co.at
Toon Moene
Michael Scharf <Michael...@Rhein-Neckar.de> wrote:
> On 18 Jun 1998 05:01:20 GMT, Navindra Umanee <navi...@cs.mcgill.ca
> > wrote:
> > Practically all decent compilers ignore whitespace these days
> Even C/C++ *is* whitespace sensitive:
>
> #define X \
> int X;
>
> put a blank after the \ and you see the difference....
Not only that, but a Fortran compiler is the only one that can legally
*ignore* whitespace.
Try the following with g77:
WRITE(*,*) 3 000 000
END
--
Toon Moene (mailto:to...@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:for...@gnu.org; NWP: http://www.knmi.nl/hirlam
Navindra Umanee
At one point in cyberspacetime
Michael Scharf <Michael...@Rhein-Neckar.de> wrote:
> On 18 Jun 1998 05:01:20 GMT, Navindra Umanee <navi...@cs.mcgill.ca
>> wrote:
>> Practically all decent compilers ignore whitespace these days (in that
>> it doesn't matter how much or how little whitespace you have, as long
>> as the compiler can make out the tokens). What I'm saying is stupid
>> about Python is that the semantic meaning of the language alledgedly
>> *depends* on whitespace.
>
> Even C/C++ *is* whitespace sensitive:
>
> #define X \
> int X;
>
> put a blank after the \ and you see the difference....
Well, C/C++ have worse deficiencies then this making the point rather
moot. :)
I simply question the wisdom of using whitespace with all the
accompanying headaches simply to avoid the typical block delimiters.
I obviously overstated the case judging by the amount of email this
has generated (not only flames, some were rather useful).
Navin
brian hiles
Michael Scharf (Michael...@Rhein-Neckar.de) wrote:
: On 18 Jun 1998 05:01:20 GMT, Navindra Umanee <navi...@cs.mcgill.ca
: Even C/C++ *is* whitespace sensitive:
: #define X \
: int X;
: put a blank after the \ and you see the difference....
This is a goof; yours, not C++ nor any other language. The above
escaped newline is parsed out by acpp(1) and is _not_ a function
of the language. Indeed, an escaped newline anywhere in any language
(including C++) is the common syntactic feature to fold the current
line without logically terminating it. Any whitespace after the
backslash would of course be escaping the lexical meaning of the
whitespace, not the newline.
-Brian
Dave Kirby
On 20 Jun 1998 07:31:17 GMT, Navindra Umanee <navi...@cs.mcgill.ca>
wrote:
>
>I simply question the wisdom of using whitespace with all the
>accompanying headaches simply to avoid the typical block delimiters.
>I obviously overstated the case judging by the amount of email this
>has generated (not only flames, some were rather useful).
>
I missed the start of this thread, so I am curious as to what you
consider "all the accompanying headaches" of using whitespace to be.
The only problem in practice comes from inconsistent mixing of tabs
and spaces, which the latest version of Python will warn you about (if
you tell it to).
I had been using C, C++ and perl for years before using python, and
was originally sceptical about its use of indentation to delimit
blocks. However after using it for a few hours I found it that it
works - the resulting code is far clearer and less cluttered than the
C, perl or similar equivalent. I now find when going back to the other
languages that they feel unnatural.
Dave K
---------------------------------------------------------------
Everything Is Deeply Intertwingled. (Ted Nelson, Computer Lib)
dkirby@ <-figure this out, spambots!-> Dave.Kirby@
bigfoot. My opinions are my own, psygnosis.
com but I'm willing to share. co.uk
Mike Coffin
dki...@see.sig.for.addr (Dave Kirby) writes:
> I missed the start of this thread, so I am curious as to what you
> consider "all the accompanying headaches" of using whitespace to be.
> The only problem in practice comes from inconsistent mixing of tabs
> and spaces, which the latest version of Python will warn you about (if
> you tell it to).
That's not the only problem in practice. A far more serious problem
for me is that there isn't enough information for an editor to indent
the code for me. With C, Java, Perl, etc., I type and the editor
indents. When I cut and paste a chunk of code, one keystroke
re-indents it to fit it into the surrounding code. If it doesn't
re-indent the way I expect, I immediately know I've screwed up. With
Python, this doesn't work. There isn't enough information around for
an editor to know how the code should be indented to begin with.
-mike
Navindra Umanee
Dave Kirby <dki...@see.sig.for.addr> wrote:
> I missed the start of this thread, so I am curious as to what you
> consider "all the accompanying headaches" of using whitespace to be.
> The only problem in practice comes from inconsistent mixing of tabs
> and spaces, which the latest version of Python will warn you about (if
> you tell it to).
Exactly that. We do all kinds of funky things with \t. Now suddenly
\t has to be treated specially and with care.
Also, now you can't break up long statements without some kind
continuation indication (for example: [backslash][newline], I don't
know what python actually uses.) In a non-whitespace sensitive
language, it is always clear where a statement begins and ends but in
python if you want to break up a statement you now have to give the
compiler special indications. You might say that typing ';' to end a
statement is an extra effort anyway but this is not true since Emacs
will automatically insert a newline and indent.
Plus, how can Emacs figure out how to do auto-indentation if there are
no block delimiters? For example, in cc-mode if I type a '}' the } is
automatically placed on a newline and my cursor is placed
appropriately at the start of the next statement. To do this in
python, you'd have to press some keybinding that indicates you're
closing or opening the block. I was curious to see how python-mode
actually does this and came upon this comment:
----------------------------
Unlike most programming languages, Python uses indentation, and only
indentation, to specify block structure. Hence the indentation
supplied automatically by Python-mode is just an educated guess: only
you know the block structure you intend, so only you can supply
correct indentation.
The [indent-for-tab-command] and [py-newline-and-indent] keys try
to suggest plausible indentation, based on
the indentation of preceding statements. E.g., assuming
[...]
Python-mode cannot know whether that's what you intended, or whether
[...]
was your intent. In general, Python-mode either reproduces the
indentation of the (closest code or indenting-comment) preceding
statement, or adds an extra py-indent-offset blanks if the preceding
statement has `:' as its last significant (non-whitespace and non-
comment) character. If the suggested indentation is too much, use
\\[py-electric-backspace] to reduce it.
----------------------------
I think that speaks for itself.
> I had been using C, C++ and perl for years before using python, and
> was originally sceptical about its use of indentation to delimit
> blocks. However after using it for a few hours I found it that it
> works - the resulting code is far clearer and less cluttered than the
> C, perl or similar equivalent. I now find when going back to the other
> languages that they feel unnatural.
I don't know about that but I'm sure Python's other advantages would
outweigh the whitespace-means-something "problem" anyway.
Navin
--
bus error
(core not dumped)
David M. Cook
On 22 Jun 1998 02:36:35 GMT, Navindra Umanee <navi...@cs.mcgill.ca> wrote:
>Also, now you can't break up long statements without some kind
>continuation indication (for example: [backslash][newline], I don't
>know what python actually uses.)
This is wrong. Why don't you actually investigate Python instead of
reaching for specious reasons to dismiss it.
Dave Cook
Navindra Umanee
One point wrong, but how about the rest? I'm not even sure it's
wrong, so would you care to be more specific instead of snipping the
most my text and taking a potshot?
[autofill turned off so that I don't accidentally change semantic
meaning. notice the backslash after 'filename + ']
http://www.unixworld.com/archives/95/tutorial/005.html:
# mailer module mailer.py
import posix # make posix system calls available
def mailit(filename, subject, list):
# mail the file to each victim
for victim in list:
# make a shell mail command for this victim
string = 'cat ' + filename + \
' | mail -n -s ' + `subject` + ' ' + victim
print string # echo the command
posix.system(string) # execute the command
usage = 'function: mailit(filename, subjectstring, list)'
----------
python-mode.el:
If a line is a continuation line because the line preceding it ends with
a backslash, the third and following lines of the statement inherit their
indentation from the line preceding them.
----------
So maybe I am wrong, but it wouldn't hurt if you'd care to be more
specific. I'm not reaching for specious reasons to dismiss Python
like you seem to think. I'm simply listing what I perceive to be the
disadvantages of relying on whitespace. I'm sure the advantages of
Python outweigh this perceived flaw.
Do also note that I don't speak for cs.mcgill.ca and that you cannot
make any conclusions or inferences about cs.mcgill.ca from my posts.
They have kickass shell accounts and a cool newsserver which I don't
mind using. So please, try to take the thread off of a personal
level.
Navin
Kevin Huber
"Navindra" == Navindra Umanee <navi...@cs.mcgill.ca> writes:
Navindra> So maybe I am wrong, but it wouldn't hurt if you'd care to
Navindra> be more specific. I'm not reaching for specious reasons to
Navindra> dismiss Python like you seem to think. I'm simply listing
Navindra> what I perceive to be the disadvantages of relying on
Navindra> whitespace. I'm sure the advantages of Python outweigh this
Navindra> perceived flaw.
In practice, few lines must be wrapped with \. Python lines tend to
be short. Function calls and expressions in parentheses can be split
among multiple lines without \. The example you cited would have fit
into 80 columns without wrapping.
example:
dragon:~/News# python
Python 1.5.1 (#1, May 5 1998, 20:30:43) [GCC 2.7.2.3.f.1] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> print (1 + 2 +
... 3 + 4)
10
-Kevin
Navindra Umanee
Kevin Huber <khu...@yuck.net> wrote:
> In practice, few lines must be wrapped with \. Python lines tend to
> be short. Function calls and expressions in parentheses can be split
> among multiple lines without \. The example you cited would have fit
> into 80 columns without wrapping.
Fair enough. Obviously the practice factor is lacking on my side. :)
I'll be sure to take a look-see at python now. (jpython seems
interesting too)
Navin
James Logajan
Navindra Umanee (navi...@cs.mcgill.ca) wrote:
: Kevin Huber <khu...@yuck.net> wrote:
Just out of curiosity, I decided to write a short Python script (ck.py) to
count how often I used the newline escape continuation in a bunch of code
I've written. The script and results follow.
---------------------begin script-----------------
#!/usr/bin/env python
import sys
s = "."
numLines = contLines = 0
while s:
s = sys.stdin.readline()
if s:
numLines = numLines + 1
if len(s) > 1 and s[-2] == "\\":
contLines = contLines + 1
def PrintEval(s):
print s + " = " + str(eval(s))
PrintEval("numLines")
PrintEval("contLines")
PrintEval("contLines/float(numLines)")
---------------------end script-----------------
Doing:
cat *.py | ck.py
Yields:
numLines = 5718
contLines = 43
contLines/float(numLines) = 0.00752011192725
So it occurs less than 1 in 100 lines in my code. This doesn't
include parenthesis wrapping. I don't consider it an issue at all. If you
want an issue to bitch about, try the lack of a do...while construct. I don't
like the trick I played in the code above, but am no fan of extraneous
flags either or doing "while 1:". Not sure why there is no do...while
construct; must have been hashed over in a thread here before my time.
Donal K. Fellows
In article <jameslEu...@netcom.com>,
James Logajan <jam...@netcom.com> wrote:
[...]
> Not sure why there is no do...while construct; must have been hashed
> over in a thread here before my time.
"do...while" doesn't fit well with the python style of using
indentation for blocks. The parser would tend to get mixed up between
the "do" construct and the ordinary "while" construct due to keyword
clash. I personally don't like using pure indentation for block
constructs, but I'm perfectly happy that others disagree...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
Department of Computer Science, University of Manchester, U.K. +44-161-275-6137
--
Never underestimate the power of the penguin...
Andrew Kuchling
Donal K. Fellows writes:
>"do...while" doesn't fit well with the python style of using
>indentation for blocks. The parser would tend to get mixed up between
>the "do" construct and the ordinary "while" construct due to keyword
>clash.
Oh, the absence of do...while is another Python annoyance of
mine. Guido seems to think that this is clean and obvious:
while (1):
... code ...
if (condition):
break
While the idiom becomes quickly recognizable, I still dislike it.
Unfortunately, my one attempt to add do...while to the interpreter
broke the parser completely, and I never bothered to track down the
problem.
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
I know flattery when I hear it; but I do not often hear it.
-- Robertson Davies, _Fifth Business_
Andrew Kuchling
Navindra Umanee writes:
>[autofill turned off so that I don't accidentally change semantic
> meaning. notice the backslash after 'filename + ']
Supporting parenthesized expressions across lines was a later
addition to Python -- well, if you consider "later" to be version
0.9.9, dated 29 Jul 1993 (from Misc/HISTORY). The Unixworld article
is from 1995, so the feature was certainly present at the time, but
Aaron may have not wanted to write the following code for some
pedagogical reason (or perhaps he forgot about that feature):
string = ( 'cat ' + filename +
' | mail -n -s ' + `subject` + ' ' + victim )
Nany of the objections to the whitespace delimiting seem to be
on theoretical grounds, from people who look at it and wonder how it could
possibly work, but haven't actually spent much time editing and
developing Python code. One could similarly wonder how C programmers
survive having 15 (or whatever the number is) different precendence
levels, or how Perl programmers possibly remember all the $[^a-z]
variables, yet apparently they do.
>Do also note that I don't speak for cs.mcgill.ca and that you cannot
>make any conclusions or inferences about cs.mcgill.ca from my posts.
Hey, I'm a product of cs.mcgill.ca, too. Blame Panangaden for
that...
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
"Why is *The McGill Daily?*" / Asked the pessimist sourly. / "Thank God," said
the optimist gaily, / "That it isn't hourly!"
-- A.J.M. Smith
D'Arcy J.M. Cain
>import sys
>s = "."
>numLines = contLines = 0
>
>while s:
> s = sys.stdin.readline()
> if s:
> numLines = numLines + 1
> if len(s) > 1 and s[-2] == "\\":
> contLines = contLines + 1
>want an issue to bitch about, try the lack of a do...while construct. I don't
>like the trick I played in the code above, but am no fan of extraneous
>construct; must have been hashed over in a thread here before my time.
What's wrong with this?
#!/usr/bin/env python
import sys
numLines = contLines = 0
for s in sys.stdin.readlines():
numLines = numLines + 1
if len(s) > 1 and s[-2] == "\\":
contLines = contLines + 1
...etc.
--
D'Arcy J.M. Cain <da...@vex.net> | Democracy is three wolves
http://www.vex.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Barry A. Warsaw
>>>>> "NU" == Navindra Umanee <navi...@cs.mcgill.ca> writes:
NU> Plus, how can Emacs figure out how to do auto-indentation if
NU> there are no block delimiters? For example, in cc-mode if I
NU> type a '}' the } is automatically placed on a newline and my
NU> cursor is placed appropriately at the start of the next
NU> statement.
Specifics of block delimiting aside, I can tell you it is *much*
easier to get python-mode to do the right thing than CC Mode. From an
Emacs major-mode point of view, Python syntax is way way more simple.
But of course, you really don't care about all that. Why don't you
try it and see how well it works in practice?
-Barry
Toon Moene
bwa...@cnri.reston.va.us (Barry A. Warsaw) wrote:
> Specifics of block delimiting aside, I can tell you it is *much*
> easier to get python-mode to do the right thing than CC Mode. From an
> Emacs major-mode point of view, Python syntax is way way more simple.
But the simplest is Fortran mode:
Indent six spaces and chop off anything from column 73 onwards.
[ Sorry, couldn't resist ]
Mike Meyer
In <6mkfvj$j...@sifon.cc.mcgill.ca>, Navindra Umanee <navi...@cs.mcgill.ca> wrote:
> Exactly that. We do all kinds of funky things with \t. Now suddenly
> \t has to be treated specially and with care.
Not really. The funky things used to break for the *human* reading the
program when you did them. Now the break for the compiler as well.
I've never really had a problem, but I'm of the same faith as the
library authors in this case.
> Also, now you can't break up long statements without some kind
> continuation indication (for example: [backslash][newline],
This is only true if you consider "newline as statement terminator" to
be "whitespace is significant". Since that particular thing seems to
be about as common as not (at least if you look past C and things
designed to be easy for C programmers to learn), I wouldn't call that
a particular problem withPython.
> I don't
> know what python actually uses.) In a non-whitespace sensitive
> language, it is always clear where a statement begins and ends but in
> python if you want to break up a statement you now have to give the
> compiler special indications. You might say that typing ';' to end a
> statement is an extra effort anyway but this is not true since Emacs
> will automatically insert a newline and indent.
This is pretty much just like Python. A special character - either
newline or ; - terminates a statement. If, for whatever reason, you
need one of those in the middle of a statement, you have to quote it
somehow.
In practice, Python is pretty good at figuring out that a statement
couldn't *possibly* end there, so you don't need to quote it. About the only obvious one that it misses is:
a = 3 +
5
Which CLU would pick up for you.
> Plus, how can Emacs figure out how to do auto-indentation if there are
> no block delimiters?
Well, when you're entering text, it does as well as it does for C. If
you look carefully, you'll notice that all lines that preceed an
indent start with ":". So it indents the next line if the last
non-white character is a ":". When you get to the end of a block, you
type a character to indicate that it's done - for C, "}"; for Python,
"DEL". It even tells you what block you've closed in Python (haven't
written C recently in Emacs).
For moving blocks, you have to be be carefull and indent the region
after the move, but it's not to bad.
What it really boils down to is that this is just a syntactic thing.
It's not for everybody - some people (me, for instance) really like
it, others hate it. Just like using dollar-splat-frob-varname, or
lots of parens. Try it, and see if you like it. If you do, cool. If
not, move on to the next thing.
<mike
--
Do NOT reply to the address in the From: header. Reply to mwm instead of
bouncenews at the same machine. Mail to bouncenews will be returned with
instructions on reaching me. Sending unsoliticed email I consider commercial
gives me permission to subscribe you to a mail list of my choice.
--
Do NOT reply to the address in the From: header. Reply to mwm instead of
bouncenews at the same machine. Mail to bouncenews will be returned with
instructions on reaching me. Sending unsoliticed email I consider commercial
gives me permission to subscribe you to a mail list of my choice.
Chris Wright
This thread, which has the potential to be YAIW (YA indentation war) could
also become an editor war (YAEW).
Mike Coffin wrote in message <8p6btrm...@eng.sun.com>...
[snip]
>
>That's not the only problem in practice. A far more serious problem
>for me is that there isn't enough information for an editor to indent
>the code for me. ...
>There isn't enough information around for
>an editor to know how the code should be indented to begin with.
>
>-mike
The python-mode for emacs does a fine job. I think it might be quite <hard>
to do, but it's pretty much do-able.
cheers
chris
Donal K. Fellows
In article <6mm091$4ud$1...@news.trends.ca>,[...]
> for s in sys.stdin.readlines():
> numLines = numLines + 1
> if len(s) > 1 and s[-2] == "\\":
> contLines = contLines + 1
Nothing, provided you know that you are only dealing with small
files[*][**] but if were to take this and then try to handle a gig of
data, you'd know the reason why swallowing the lot first is a bad
idea. You also wouldn't want to do this with a general pipeline
transformation as it would effectively place infinite buffering at
this stage, a bad thing in more ways than one.
Donal.
[* Or if Python is lazy, but I doubt that. For some reason, Real
Programmers Don't Use Lazy Languages. Don't know why this is the
case though. ]
[** That is, for the specific case that the original code was used
for. Using your code *generally* is more problematic. ]
Terry Reedy
navi...@cs.mcgill.ca says...
>Plus, how can Emacs figure out how to do auto-indentation if there are
>no block delimiters? For example, in cc-mode if I type a '}' the } is
>automatically placed on a newline and my cursor is placed
>appropriately at the start of the next statement.
If you are used to {} as block delimiters, could you program EMACS to
recognized them as such for Python also (but just not print them)?
IE, { = \n + indend, } = \n + dedent
IE, personalize python-mode.el?
> To do this in python, you'd have to press some keybinding that
indicates you're closing or opening the block.
Is this what I just said above? (I'm not sure)
Terry
Navindra Umanee
Terry Reedy <tjr...@udel.edu> wrote:
> If you are used to {} as block delimiters, could you program EMACS to
> recognized them as such for Python also (but just not print them)?
> IE, { = \n + indend, } = \n + dedent
> IE, personalize python-mode.el?
Yes. The difference is that Emacs only sees the {} as you type them
so for all other situations which involve processing written code,
Emacs will have to rely [on whatever it relies on now].
>> To do this in python, you'd have to press some keybinding that
> indicates you're closing or opening the block.
>
> Is this what I just said above? (I'm not sure)
Yes, that's what I meant.
(A preprocessor for python that is non-whitespace dependent would
probably be trivial, eh. python --no-whitespace)
Navin
James Logajan
Chris Wright (c...@belloc.med.monash.edu.au) wrote:
: This thread, which has the potential to be YAIW (YA indentation war) could
Not sure I understand what Mike Coffin is getting at. My problem with curly-
bracket delimited blocks is that if I indent to show block structure, none
of the editors I use know how to add curly brackets after the fact....
Barry A. Warsaw
>>>>> "TM" == Toon Moene <to...@moene.indiv.nluug.nl> writes:
TM> But the simplest is Fortran mode:
TM> Indent six spaces and chop off anything from column 73
TM> onwards.
TM> [ Sorry, couldn't resist ]
No, I will *not* succumb to your subliminal suggestion that I take
over fortran-mode.el.
-Barry
Amit Patel
[comp.*.linux removed]
Andrew Kuchling <akuc...@cnri.reston.va.us> wrote:
| Donal K. Fellows writes:
| >"do...while" doesn't fit well with the python style of using
| >indentation for blocks. The parser would tend to get mixed up between
| >the "do" construct and the ordinary "while" construct due to keyword
| >clash.
|
| Oh, the absence of do...while is another Python annoyance of
| mine. Guido seems to think that this is clean and obvious:
|
| while (1):
| ... code ...
| if (condition):
| break
|
| While the idiom becomes quickly recognizable, I still dislike it.
| Unfortunately, my one attempt to add do...while to the interpreter
| broke the parser completely, and I never bothered to track down the
| problem.
Loops in Scheme and ML often end up looking like 'while 1' loops in
Python. Those languages have made me really appreciate the power of
loops with this shape:
while 1:
... code A ...
if condition: break
... code B ...
Note that this doesn't fit into the 'while/do' loop (where 'code A'
must be empty) or the 'do/while' loop (where 'code B' must be empty).
When using C++ I often find people cram all of 'code A' into the while
condition, which I find somewhat uglier than the 'while 1' approach:
while(cin >> x && x != "end" && !prime(count))
... code B ...
I think this is much easier to understand:
while (1) {
cin >> x; // code A
if (x == "end") break; // condition
if (prime(count)) break; // condition
... code B ...
}
Anyway, most of the times that I can't use a normal while/do, it turns
out that there's both a 'code A' and 'code B' section, so I couldn't
use do/while either! :P
- Amit
Mike Coffin
"Chris Wright" <c...@belloc.med.monash.edu.au> writes:
> This thread, which has the potential to be YAIW (YA indentation war) could
> also become an editor war (YAEW).
>
> Mike Coffin wrote in message <8p6btrm...@eng.sun.com>...
> [snip]
> >
> >That's not the only problem in practice. A far more serious problem
> >for me is that there isn't enough information for an editor to indent
> >the code for me. ...
> >There isn't enough information around for
> >an editor to know how the code should be indented to begin with.
> >
> >-mike
>
>
> The python-mode for emacs does a fine job. I think it might be quite <hard>
> to do, but it's pretty much do-able.
It's not just hard, it's impossible. And it doesn't have anything to
do with what editor you use, so lets not get into that. :-)
Suppose I have this code:
while a < 7:
b := b * 5
c := c / 2
Now I grab a block of code from somewhere else and insert it after the
while loop. For sake of simplicity, suppose it's just one line,
unindented. (Yes, I know it's silly to cut an paste one line. The
same thing happens if it's a dozen lines.)
d := 9 * d
The editor cannot possibly know whether I want
while a < 7:
b := b * 5
c := c / 2
d := 9 * d
or
while a < 7:
b := b * 5
c := c / 2
d := 9 * d
In fact, there might well be half a dozen valid ways to indent in more
complicated code, depending on what is meant.
In other languages, I insert the line (either before or after the
closing brace) and hit "reindent"---presto, everthing is nicely lined
up. In Python, I have to reindent the pasted code manually.
-mike
Clemens Hintze
>>>>> "D'Arcy" == D'Arcy J M Cain <da...@vex.net> writes:
[...]
D'Arcy> What's wrong with this?
[...]
This program will work for what it was designed. But in principle if you use
the readlines() functions, you have to take sorrow, that the file to be read
in is not too large.
With Python 1.5 Guido has include a very nice and very useful module called
inputfile.py. It takes the arguments of the script as files and open them one
after the other during delivering of lines of these files. If no arguments was
given the input is read from stdin. Using that module, your script would
become:
#!/bin/env python
import fileinput
contLines = 0
for line in fileinput.input():
if len(s) > 1 and s[-2] == "\\":
contLines = contLines + 1
# The module fileinput counts the "number of lines read until yet" in the
# variable fileinput.lineno
Bye,
Cle.
--
| Clemens Hintze * ACB/EO ____ OMC-R Software Developement
| Phone: +49 30 7002-3241 \ / ALCATEL Mobile Communication Division ITD
| Fax : +49 30 7002-3851 \/ Colditzstr. 34-36, D-12099 Berlin, Germany
| mailto:Clemens...@bln.sel.alcatel.de
Kevin Dahlhausen
Two guys are sitting in a bar, and get talking.
"What's you IQ?" one asks.
"169" is the reply.
"Wow, amazing --- my IQ's 172. What're your ideas on Hawkings latest
work on
superstring theory?"
And the two get chatting and become lifelong friends.
Further down the bar, two other guys are comparing IQs.
"Mine's 104"
"Gosh, mine's 102. What do you think about the latest Cub's game?"
And the two become lifelong friends.
Even further down the bar, two other guys are also comparing IQs.
"Mine's 53."
"Wow! Mine's 54. Do you use emacs or vi?"
Jerry McBride
In article <3590fcfa...@bad-news.harborcom.net>,
I was drinking a cup of coffee when I came across this. Needless to say, I
had to wipe of my monitor rather quickly... <VBG>
Most Excellent!
--
/-------------------------------------\
| Jerry McBride |
| |
| (mcbr...@erols.com |
\-------------------------------------/
James Logajan
Kevin Dahlhausen (mo...@harborcom.net) wrote:
: Two guys are sitting in a bar, and get talking.
: "What's you IQ?" one asks.
: "169" is the reply.
: "Wow, amazing --- my IQ's 172. What're your ideas on Hawkings latest
: work on
: superstring theory?"
: And the two get chatting and become lifelong friends.
: Further down the bar, two other guys are comparing IQs.
: "Mine's 104"
: "Gosh, mine's 102. What do you think about the latest Cub's game?"
: And the two become lifelong friends.
: Even further down the bar, two other guys are also comparing IQs.
: "Mine's 53."
: "Wow! Mine's 54. Do you use emacs or vi?"
Thanks, that was a lot quicker way of figuriin out my IQ than taking
some dumb test! I assume the emacs guy has the 54 IQ. I can live with 53.
P.S. I pulled a real Charly Gordon this morning and used the c-shell.
P.P.S. And put flowers on Algernon's grave for me.
David O'Bedlam
Kevin Dahlhausen <mo...@harborcom.net> wrote:
[...]
> Even further down the bar, two other guys are also comparing IQs.
> "Mine's 53."
> "Wow! Mine's 54. Do you use emacs or vi?"
Neither. I use PICO.
TheDavid
--
"Universal ethical laws come from offers to fellate TheDavid."
-- Oli <sam...@w3ath3r.demon.co.uk>
Carey Evans
Andrew Kuchling <akuc...@cnri.reston.va.us> writes:
> while (1):
> ... code ...
> if (condition):
> break
>
> While the idiom becomes quickly recognizable, I still dislike it.
> Unfortunately, my one attempt to add do...while to the interpreter
> broke the parser completely, and I never bothered to track down the
> problem.
I hesitate at recommending *anything* from ILE RPG, but it has
something like this:
* Doesn't get executed if foo starts as 0.
C FOO DOWNE 0
C ...
C ENDDO
* Always executes at least once.
C FOO DOUEQ 0
C ...
C ENDDO
So a future version of Python _could_ do something like:
until foo = 0:
... code ...
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"[UNIX] appears to have the inside track on being the replacement for
CP/M on the largest microcomputers (e.g. those based on 68000...)"
Bloody Viking
Mike Coffin (m...@Eng.Sun.COM) wrote:
: In other languages, I insert the line (either before or after the
: closing brace) and hit "reindent"---presto, everthing is nicely lined
: up. In Python, I have to reindent the pasted code manually.
My pet solution for indenting is to not indent in the first place! This
makes for some ugly code, of course. Since my code is always for my
personal use, it doesn't matter. :) I just use the pico text editor for
hacking up the code and compile away. One of the funniest things I found
with Linux is a QBASIC to C converter. You code in BASIC, use the
converter to spit out C, and edit the C code for that extra touch up work.
I wouldn't be surprised if I could reinvent anon.penet.fi software with
that QBASIC to C converter. Anyone know about setting up Linux for a SMTP
dialup connection? I could use the fame of being another Julf with my own
anon.penet.com!
--
CAUTION: Email Spam Killer in use. Leave this line in your reply! 152680
A cult founder's rustbucket freighter is his battleship.
2727652 bytes of spam mail deleted. http://www.wwa.com/~nospam/
Bloody Viking
'David O'Bedlam' (thed...@frottage.org) wrote:
: Kevin Dahlhausen <mo...@harborcom.net> wrote:
: [...]
: > Even further down the bar, two other guys are also comparing IQs.
: > "Mine's 53."
: > "Wow! Mine's 54. Do you use emacs or vi?"
: Neither. I use PICO.
Same here! On my Linux box, I have it as the default, but HOW I set it up
as the default is wierd. I merely renamed elvis to something else, and
renamed pico to elvis! Eh, it's my box! :) This from the bloke who names
Linux executables that are automatically run (Like my mail bot) as
whatever.exe. (And automatically run shell scripts whatever.bat.)
Confusion
sorry for the crosspost, but im not sure from where you are posting
from.
Just a simple question about PICO. How do you turn off line wrapping in
pico? I use it it to read a wide datafile but PICO wrapped and mangled
the long lines. (I've already RTFM and RTFFaq)
Thanks
Bloody Viking wrote:
>
> Mike Coffin (m...@Eng.Sun.COM) wrote:
>
<chomp>
>
> My pet solution for indenting is to not indent in the first place! This
> makes for some ugly code, of course. Since my code is always for my
> personal use, it doesn't matter. :) I just use the pico text editor for
> hacking up the code and compile away. One of the funniest things I found
> with Linux is a QBASIC to C converter. You code in BASIC, use the
> converter to spit out C, and edit the C code for that extra touch up work.
>
<chomp>
Confusion
Thank you. jpico works nicely :)
juuust a little comment, cant navigate the directories from inside joe
a'la ^T in pico
:)
Mark Nottingham wrote:
>
> pico -w will get you support for longer lines, but will still chomp very
> long ones. Muuch better is jpico, joe's pico emulation mode, which lets
> you fine-tune these things, and offers a LOT more functionality.
>
> Joe should be in most linux distributions, or do an altavista for +joe
> +editor.
>
> --
> Mark Nottingham
> Web Architecture, Design, Programming and Consulting
> mn...@pobox.com http://www.pobox.com/~mnot/
> Melbourne "Redneck Wonderland" Australia
Mark Nottingham
Confusion (conf...@confusion.edu) wrote:
: Just a simple question about PICO. How do you turn off line wrapping in
: pico? I use it it to read a wide datafile but PICO wrapped and mangled
: the long lines. (I've already RTFM and RTFFaq)
pico -w will get you support for longer lines, but will still chomp very