[Q] Perl vs. Python
Christopher Browne
On Wed, 17 Jun 1998 15:20:10 -0400, Faceless <bmco...@cunyvm.cuny.edu> wrote:
>Charlie Stross wrote:
>> Fundamentally, Python and Perl come from different lineages; Perl is
>> UNIX-ish (and feels like a bastard collision between C and every tool in
>> the UNIX environment -- it's not called the UNIX swiss-army chainsaw for
>> nothing),
>
>I'll take that as a good thing since I love C. I've just bought "Learning
>Perl" published
>by O'REILLY.
Had Python been available at the time Perl was, I expect that we'd all
be using Python today, as it just has the feel to me of being a "cleaner
design." (I think the "busmeister" hadn't quite released ABC at the
point of Perl 2...)
The only "bad rap" that Python tends to get is with respect to the
"treating whitespace as significant" issue.
I quite like Python, and those few experiences I've had with it. The
handling of regular expressions is quite nice.
I write a lot more Perl, but that is largely a matter of having had more
familiarity because Perl 3 was available a *LONG* time ago...
--
"There's no longer a boycott of Apple. But MacOS is still a
proprietary OS." -- RMS - June 13, 1998
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Christopher Browne
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.
It would be more accurate to say:
"All compilers for languages that people don't arbitrarily flame for
being old and decrepit (such as FORTRAN or COBOL) do not treat
whitespace as significant."
The fact that FORTRAN, JCL, and assemblers have traditionally *required*
whitespace in order to force fields to particular positions has caused
people to criticize what you have criticized.
This does not establish a general rule that it is indeed "stupid" for
language semantics to have *some* dependencies on whitespace.
Feel free to claim it. That doesn't make it true.
I've not written huge quantities of Python, but have done enough to get
a preliminary feel for it. I didn't find the whitespace handling caused
me any confusion.
It is equally appropriate to criticize Perl for its proliferation of
punctuation into programs, or LISP for the proliferation of parentheses,
or C for the proliferation of braces.
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
schools in Canada, albeit not being particularly notable for its CS
program; you should have learned better than that...)
--
"Windows95, Word97, Office98: With all the criticisms of Microsoft, at
least they include "best-before" dating on many of their products..."
(cbbr...@hex.net)
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
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
> *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
Cordova Gustavo
But that's pre-processor stuff, it doesn't actually get seen by the
compiler.
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
Piet van Oostrum
>>>>> Cordova Gustavo <Cordova...@JDCorp.deere.com> (CG) writes:
CG> But that's pre-processor stuff, it doesn't actually get seen by the
CG> compiler.
And in python it is lexer stuff.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: Piet.van...@gironet.nl
Michael Scharf
Cordova Gustavo wrote:
>
> But that's pre-processor stuff, it doesn't actually get seen by the
True, but from the programmes point of view, the pre-processor
*is* pat of the language! How else, for example, would you avoid
including the same header-file more than once.
> >
> > Even C/C++ *is* whitespace sensitive:
> >
> > #define X \
> > int X;
> >
> > put a blank after the \ and you see the difference....
Michael
Mike Meyer
In <358AA11C...@Rhein-Neckar.de>, Michael Scharf <Michael...@Rhein-Neckar.de> wrote:
> Cordova Gustavo wrote:
> >
> > But that's pre-processor stuff, it doesn't actually get seen by the
> > compiler.
>
> True, but from the programmes point of view, the pre-processor
> *is* pat of the language! How else, for example, would you avoid
> including the same header-file more than once.
Nuts - in some IMPLEMENTATIONS the preprocessor is part of the
compiler.
Do all the languages that do string pasting count as having
significant spaces?
<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.
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
Tim Peters
[Toon Moene]
> Not only that, but a Fortran compiler is the only one that
> can legally *ignore* whitespace.
[Dennis Bieber]
> Which is what makes FORTRAN compilers so complex...
Spent many delightful years writing delightful Fortran compilers. The real
reason they're complex is that they don't expect the user to write optimized
assembly language for them <0.9 *p++ = *q++>.
> Consider where the compiler has to be to determine just
> what type of statement it is processing:
>
> do 10 i = 1. 3
> vs
> do 10 i = 1, 3
The difficulty of getting stuff like that straight is grossly overblown.
It's a snap, just so long as you stay away from new-fangled baby-pacifiers
like parser generators <grin>.
64Hhollerith-is-much-clearer-than-quoted-strings-too-ly y'rs - tim
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
Dave Kirby
>In <358AA11C...@Rhein-Neckar.de>, Michael Scharf <Michael...@Rhein-Neckar.de> wrote:
>> Cordova Gustavo wrote:
>> >
>> > But that's pre-processor stuff, it doesn't actually get seen by the
>> > compiler.
>>
>> True, but from the programmes point of view, the pre-processor
>> *is* pat of the language! How else, for example, would you avoid
>> including the same header-file more than once.
>
>Nuts - in some IMPLEMENTATIONS the preprocessor is part of the
>compiler.
The behaviour of the C (and hence C++) pre-processor is defined by the
language standard, so to me than makes it part of the language.
Whether it is implemented by a seperate program or not is irrelevant.
>
>Do all the languages that do string pasting count as having
>significant spaces?
As an aside, forth is totally dependant on whitespace to delimit its
tokens since you can define a forth word consisting of any sequence of
(non-ws) characters. I do not believe that the language is any the
worse for that.
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.
Tim Peters
[Navindra Umanee]
> [scary quotes about indentation from the python-mode docs]
>
> I think that speaks for itself.
Na, not really. The python-mode docs are extensive, and, unlike the docs in
other language modes at the time I wrote that stuff, strove to tell the
whole truth. As such, it dutifully described all the pathologies that were
*possible*. Since you haven't used it, though, you seem to be reading it as
a description of typical experience. It's not. In actual practice, Python
mode almost always got the intended indentation right all by itself, even
after cutting & pasting and using one of the "reindent according to context"
functions. Barry Warsaw has since made it even better.
I currently use a much dumber editor than Emacs, and given the dumbest form
of auto-ident imaginable, plus manual block indent/dedent, find editing
Python no harder than editing C++ even there.
reading-the-fine-print-on-any-accurately-labeled-pkg-is-scary-ly y'rs - tim
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_
William Clodius
Tim Peters wrote:
> <snip>
> > Consider where the compiler has to be to determine just
> > what type of statement it is processing:
> >
> > do 10 i = 1. 3
> > vs
> > do 10 i = 1, 3
>
> The difficulty of getting stuff like that straight is grossly overblown.
> It's a snap, just so long as you stay away from new-fangled baby-pacifiers
> like parser generators <grin>.
I was under the strong impression that lexical analysis, not parsing,
was the difficulty with Fortran's fixed form, i.e., YACC could be
relatively easilly used to handle Fortran's syntax, but something much
more capable than LEX was needed.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov
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
Guido van Rossum
> "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
> constructs, but I'm perfectly happy that others disagree...
That's not true. Since 'do' *requires* the 'while' part, there's no
ambiguity in the following:
do:
y = y - 1
while x < y:
x = x+1
while x > y
The real reason why I don't like adding this is simply that I'm trying
to keep the syntactic complexity down.
--Guido van Rossum (home page: http://www.python.org/~guido/)
James Logajan
Guido van Rossum (gu...@CNRI.Reston.Va.US) wrote:
: > "do...while" doesn't fit well with the python style of using
You're too late! :-) Anyway, perhaps a do:...until block structure
would avoid all residual questions of ambiguity and still provide
some of us some relief. I can live without such a construct, though.
P.S. As I said earlier, if this has been hashed out before, I beg
forgiveness for bringing it up again.
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.
Paul Jackson
Guido wrote:
|> The real reason why I don't like adding this is simply
|> that I'm trying to keep the syntactic complexity down.
As a Python newbie -- I greatly appreciate this view.
Not that I can't master complexity (though getting fluent in
C++ took an amazingly long time). But rather that I enjoy the
minimalism more often seen in single lead designer works, and
usually destroyed in committee designed works.
Well done, I say. I never thought I'd find a rapid development
scripting language with such keen thought given to programming
in the large. I'm fluent in sh/ksh/awk/grep/sed/... as well
(the thinking man's Perl, as someone's .sig notes). But such
technology is limited roughly to projects solvable in less than a
thousand lines of code. And such scripts (even my clearest gems)
are notoriously unmaintainable by anyone other than the author.
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (p...@sgi.com; p...@usa.net) 3x1373 http://sam.engr.sgi.com/pj
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
Barry A. Warsaw
>>>>> "JL" == James Logajan <jam...@netcom.com> writes:
JL> You're too late! :-)
Ah, but it could be *much* worse!
JL> Anyway, perhaps a do:...until block structure would avoid all
JL> residual questions of ambiguity and still provide some of us
JL> some relief. I can live without such a construct, though.
I personally don't miss do/while or do/until much. while 1: does the
job just fine, and often there is more than one condition that can
break out of the loop, which would make a do/while only more
complicated.
-Barry
Jacques Vidrine
-----BEGIN PGP SIGNED MESSAGE-----
Consider a 4 Gb file ..
Jacques Vidrine <n...@nectar.com>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNY6lCTeRhT8JRySpAQFRLAQApFDtJr2pcXg/dN4X4ZIROlS32c8J3zBF
4BLb3v7SQJtbe8StKloNBKyBCRulwt29AuqiV1Tys4EcJoRoaE0s1gtmnbJlXVnD
LoUhA64X4jjdPLkjpEXwSx1JruleNNCAdVYOqiVBIUjvKQmOsX1Ej1vKCtLDs7xZ
vBKtLSxbv+M=
=GOYX
-----END PGP SIGNATURE-----
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 ]
--
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
noone
In article <1998062218...@ranma.nectar.com>,
--
This is a message from qqqqq.
Flexible - but not spineless !!
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.
Quentin Crain
Oops! Sorry about that!
What I meant to say was:
WOW! A 4Gb Python script! :)
Quentin Crain
nano...@europa.com
Tim Peters
> > > do 10 i = 1. 3
> > > vs
> > > do 10 i = 1, 3
[tim]
> > The difficulty of getting stuff like that straight is grossly
> > overblown. It's a snap, just so long as you stay away from
> > new-fangled baby-pacifiers like parser generators <grin>.
[William B. Clodius]
> I was under the strong impression that lexical analysis, not parsing,
> was the difficulty with Fortran's fixed form, i.e., YACC could be
> relatively easily used to handle Fortran's syntax, but something much
> more capable than LEX was needed.
Ya, but the distinction between lexing and parsing only arises if you're
trying to use one of those baby boosters to begin with <wink>.
Seriously, parser generators are great and anyone would be nuts not to use
one. "Pure lex" can't handle Fortran, but in practice lex can be fudged.
Historical note: Cray's 2nd Fortran compiler (CFT77) actually used a parser
generator from one of "you guys" (i.e., from LANL or LLNL; don't recall
which offhand). The person doing the tokenization to feed into it swore a
lot, but after a couple weeks of that I recall the parsing part went very
smoothly.
One fine idea Fortran had that subsequent language fashion rejected was
*not* reserving its keywords. It gave the language freedom to evolve
without breaking old code (contrast with the hellish syntactic convolutions
in C++ to avoid new keywords). The odd thing is that reserving keywords
makes neither lexing nor parsing easier; it just simplifies token
*classification*. Simplifies it a whole bunch, yes, but at what eventual
cost?
talk-about-the-context-free-tail-wagging-the-dog-ly y'rs - tim
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. ]
Andrew Kuchling
Tim Peters writes:
>One fine idea Fortran had that subsequent language fashion rejected was
>*not* reserving its keywords. It gave the language freedom to evolve
Didn't PL/I also not reserve its keywords? I seem to recall
seeing an example such as IF IF <> THEN THEN THEN = IF in my
programming language course.
--
A.M. Kuchling http://starship.skyport.net/crew/amk/
Principally I played pedants, idiots, old fathers, and drunkards.
As you see, I had a narrow escape from becoming a professor.
-- Robertson Davies, "Shakespeare over the Port"
Anselm Lingnau
In article <000101bd9c28$d4736880$4d9e2299@tim>,
Tim Peters <tim...@email.msn.com> wrote:
> > do 10 i = 1. 3
> > vs
> > do 10 i = 1, 3
>
> The difficulty of getting stuff like that straight is grossly overblown.
Especially since it is perfectly allowable to say
do 10, i = 1, 3
but
do 10, i = 1. 3
is an obvious (to the compiler, anyway) syntax error.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
I have never seen anything fill up a vacuum so fast and still suck.
--- Rob Pike, on X
William Clodius
Tim Peters wrote:
> <snip>
> Historical note: Cray's 2nd Fortran compiler (CFT77) actually used a parser
> generator from one of "you guys" (i.e., from LANL or LLNL; don't recall
> which offhand). The person doing the tokenization to feed into it swore a
> lot, but after a couple weeks of that I recall the parsing part went very
> smoothly.
Strange. I thought Cray's compiler was written in Pascal. I had heard
that LANL had written a parser generator, but one that generated Fortran
code. Maybe we had more than one such code, or you used one form LLNL.
>
> One fine idea Fortran had that subsequent language fashion rejected was
> *not* reserving its keywords. It gave the language freedom to evolve
> without breaking old code (contrast with the hellish syntactic convolutions
> in C++ to avoid new keywords). The odd thing is that reserving keywords
> makes neither lexing nor parsing easier; it just simplifies token
> *classification*. Simplifies it a whole bunch, yes, but at what eventual
> cost? <snip>
Not reserving keywords has another cost in terms of indirect syntactic
complexity. In particular, the syntax for subroutine calls (CALL
procedurename(...)) makes it easier to distinguish language designed
procedures from user defined procedures. The number of reserved words,
and hence their cost, can be reduced through a properly designed
namespace or module
system.
Felix Schroeter
Hello!
In article <6mcc99$l84$2...@blue.hex.net>,
Christopher Browne <cbbr...@hex.net> wrote:
>[...]
>"All compilers for languages that people don't arbitrarily flame for
>being old and decrepit (such as FORTRAN or COBOL) do not treat
>whitespace as significant."
Would you flame Haskell for being old? Yet, there is one
kind of syntactic/lexical sugar in there that depends on
whitespaces, the layout rules.
>[...]
Regards, Felix.
[c.l.python removed from the followup]
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
Tim Peters
> > > do 10 i = 1. 3
> > > vs
> > > do 10 i = 1, 3
> >
> > The difficulty of getting stuff like that straight is grossly
> > overblown.
[Anselm Lingnau]
> Especially since it is perfectly allowable to say
>
> do 10, i = 1, 3
> but
> do 10, i = 1. 3
>
> is an obvious (to the compiler, anyway) syntax error.
Indeed, to the compiler, it is. I'm not defending DO-loop syntax, though --
it sucks. Was responding to a claim that sorting it all out made Fortran
compilers complex. It doesn't. The code required to deal with it is
certainly a nuisance, but no worse than that.
BTW, we really can't tell whether your examples are or aren't syntax errors
unless you show us the lines that follow them too <wink>.
continuation-lines-are-a-source-of-great-joy-ly y'rs - tim
Tim Peters
[tim]
> ...
> Historical note: Cray's 2nd Fortran compiler (CFT77) actually
> used a parser generator from one of "you guys" (i.e., from LANL
[William Clodius]
> Strange. I thought Cray's compiler was written in Pascal.
Right -- although after we got done extending it I'm not sure Professor
Wirth would have agreed <wink>.
> I had heard that LANL had written a parser generator, but one that
> generated Fortran code. Maybe we had more than one such code, or
> you used one form LLNL.
I *thought* there was an odd step in this! You're right, it was the LANL
Fortran generator. We didn't need the "back end" of that, though -- the
real value was in the parse tables it constructed from the grammar. We took
the parse tables and massaged them a bit, then a vectorized Pascal
table-crawler used the result as a canned (precomputed) input. Worked well!
> [about reserving keywords]
> Not reserving keywords has another cost in terms of indirect syntactic
> complexity. In particular, the syntax for subroutine calls (CALL
> procedurename(...)) makes it easier to distinguish language designed
> procedures from user defined procedures.
Not sure that's an advantage, though. What useful information is
communicated to the reader, or in what way does forcing the distinction to
be made aid the author? I wrote compilers long enough that compiler-centric
views lost appeal <wink>.
> The number of reserved words, and hence their cost, can be reduced
> through a properly designed namespace or module system.
The cost is in inhibiting language evolution, which gets paid in the end
whether there are 500 keywords or 15 at the start. Java certainly took
namespaces seriously, yet thanks to their inability to add new keywords,
some of the new initialization and inner class features follow the C++ path
of assigning meaning to syntax that was simply illegal before. It still
*looks* bizarre, but now it "means something" non-obvious. Or, closer to
home, we saw Guido recently suggest that "x = x" would be a reasonable way
to spell "ah, this module-level name's binding may change after
initialization" -- in lieu of not being able to say "const x'" for names not
in that class.
The good news is, after piling up enough obscure syntactic hackery, it
*does* give a fine excuse to throw it all out and start over.
and-without-new-languages-we'd-be-stuck-with-the-old<wink>-ly y'rs - tim
Terry Reedy
am...@Xenon.Stanford.EDU says...
...
>Python. Those languages have made me really appreciate the power of
>loops with this shape:
>
> while 1:
> ... code A ...
> if condition: break
> ... code B ...
[+ comment on much greater usage frequency than simple do-while]
The hackiness of the above is syntactic, not semantic. Linger, Mills, &
Witt, in 'Structured Programming: Theory and Practice', label this
control structure 'dowhiledo'. They examine it as a primitive, and
prove theorems about it, along with its specializations, whiledo and
dowhile (or dountil). As a generalization, it is more powerful than
either (and the theorems more complicated!). They use the syntax 'do A
while cond do B od' (sometimes written on 7+ lines). If we were to add
do-while to Python, I would like it to be a full do-while-(do). IE.
do: suiteA
while cond: suiteB
(I am assuming that a revised parser could handle this just as well as
the simpler no-suiteB form that has already been proposed, and which
Guido said should be possible).
The more general form proposed here would require a 'pass' command for
suiteB when the latter is not needed, but, as Amit suggested, this is
relatively rare. At first, it may look a little awkward or strange,
with two keyword lines, but it is no more so (with practice) than
if cond: suiteA
else: suiteB
If we were to add this, then it could (should?) be presented as a
generic loop construct paralleling if-else as a generic branch
construct. For 'do:suiteA' would be optional in the same sense that
'else: suiteB' currently is, with a useless 'do: pass' usually omitted
just as 'else: pass' usually is now.
Because the general form is needed much more often than the restricted
do-while, there would be much more justification and payoff for the
effort of changing. It would also give Python something that C and many
(most?) other languages currently lack: explicit incorporation in its
syntax, as a 'first-class' control stucture, of the one-switch,
two-block loop that corresponds to the one-switch, two-block
ifC-thenA-elseB branch structure.
Terry J. Reedy
Tim Peters
[Andrew Kuchling]
> Didn't PL/I also not reserve its keywords? I seem to recall
> seeing an example such as IF IF <> THEN THEN THEN = IF in my
> programming language course.
Yes, and Eric Stechmann pointed this out too. Cute, eh? Of course nobody
in practice writes code like that, any more than Fortran programmers name
their DO loop vrbls DO or declare a COMPLEX value with name INTEGER. The
entire value is in what it "doesn't break later". Shadowing of outer vrbls
by same-named vrbls in inner scopes is of much the same flavor in practice:
doing it on purpose is abuse, but it can save your bacon all the same.
BTW, comp.lang.python has really matured! That is, we're all typing in a
thread called "Perl vs. Python" and I can't remember the last time Perl was
even mentioned in this exchange <wink>!
So I'll rectify that here: In effect, Perl got around the "new keyword"
issue by reserving all possible keywords! That's one happy consequence of
forcing all user names to start with $, %, etc. Even read a bit by Larry
Wall that said it was an intentional consequence -- Perl's not as nuts as
Larry looks <wink -- or maybe that's backwards>.
while-python-has-truly-done-incredibly-well-with-its-handful-of-
keywords-so-far-ly y'rs - tim
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
Richard Smol
In a previous article, wclo...@lanl.gov (William Clodius) says:
>> One fine idea Fortran had that subsequent language fashion rejected was
>> *not* reserving its keywords. It gave the language freedom to evolve
>> without breaking old code (contrast with the hellish syntactic convolutions
>> in C++ to avoid new keywords). The odd thing is that reserving keywords
>> makes neither lexing nor parsing easier; it just simplifies token
>> *classification*. Simplifies it a whole bunch, yes, but at what eventual
>> cost? <snip>
>
>Not reserving keywords has another cost in terms of indirect syntactic
>complexity. In particular, the syntax for subroutine calls (CALL
>procedurename(...)) makes it easier to distinguish language designed
>procedures from user defined procedures. The number of reserved words,
>and hence their cost, can be reduced through a properly designed
>namespace or module system.
Hey, tell that to Mike Colinshaw, the maker of Rexx ;) . As far as I know,
Rexx has no real reserved keywords, yet is syntactically childishly simple.
Greetz,
RS
Tor Iver Wilhelmsen
On Fri, 19 Jun 1998 19:34:20 +0200, Michael Scharf
<Michael...@Rhein-Neckar.de> uttered:
>How else, for example, would you avoid
>including the same header-file more than once.
You borrow Objective-C's "import". :-)
--
"I had to upgrade the memory of my 8088 from to 256K to 640K just to play [Demon's Winter]."
- gmad...@usa.net
Tor Iver Wilhelmsen http://www.pvv.org/%7etoriver/
Tor Iver Wilhelmsen
On Tue, 23 Jun 1998 08:28:11 -0600, William Clodius
<wclo...@lanl.gov> uttered:
>Not reserving keywords has another cost in terms of indirect syntactic
>complexity.
Not too much more complex, IMHO: you change "this word is a keyword"
into "this word, occuring in this statement, is a keyword".
Piet van Oostrum
>>>>> tjr...@udel.edu (Terry Reedy) (TR) writes:
TR> am...@Xenon.Stanford.EDU says...
TR> ...
>> Python. Those languages have made me really appreciate the power of
>> loops with this shape:
>>
>> while 1:
>> ... code A ...
>> if condition: break
>> ... code B ...
TR> ...
TR> [+ comment on much greater usage frequency than simple do-while]
TR> The hackiness of the above is syntactic, not semantic. Linger, Mills, &
TR> Witt, in 'Structured Programming: Theory and Practice', label this
TR> control structure 'dowhiledo'. They examine it as a primitive, and
TR> prove theorems about it, along with its specializations, whiledo and
TR> dowhile (or dountil). As a generalization, it is more powerful than
TR> either (and the theorems more complicated!). They use the syntax 'do A
TR> while cond do B od' (sometimes written on 7+ lines). If we were to add
TR> do-while to Python, I would like it to be a full do-while-(do). IE.
TR> do: suiteA
TR> while cond: suiteB
In fact Algol 68 had this kind of construction.
while
suite
condition
do
suite
od
This isn't as general as could be, however. In the general case there can
be more than one exit point:
while 1:
... code A ...
if condition: break
... code B ...
if anothercondition: break
... code C ...
I must admit that I don't like to see "while 1:" and I hate:
while 1:
line = file.readline()
if not line: break
...
where I would prefer something with the semantics of:
while (line = file.readline()):
...
But that is about the only gripe I have against the while 1 construction.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: Piet.van...@gironet.nl
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 |
\-------------------------------------/
William Clodius
Tim Peters wrote:
> <snip>
> [myself]
> > [about reserving keywords]
> > Not reserving keywords has another cost in terms of indirect syntactic
> > procedurename(...)) makes it easier to distinguish language designed
> > procedures from user defined procedures.
>
> communicated to the reader, or in what way does forcing the distinction to
> be made aid the author? I wrote compilers long enough that compiler-centric
> views lost appeal <wink>.
It is certainly less necessary now with useful namespace or module
systems. At the time of Fortran's design this in effect put user defined
subroutines in a different namespace from language defined procedures.
It could have been addressed in other ways though, e.g., by allowing
intrinsic procedures (as well as functions) to have the intrinsic
attribute.
>
> > The number of reserved words, and hence their cost, can be reduced
> > through a properly designed namespace or module system.
>
> The cost is in inhibiting language evolution, which gets paid in the end
> whether there are 500 keywords or 15 at the start. Java certainly took
> namespaces seriously, yet thanks to their inability to add new keywords,
> some of the new initialization and inner class features follow the C++ path
> of assigning meaning to syntax that was simply illegal before. It still
> *looks* bizarre, but now it "means something" non-obvious. Or, closer to
> home, we saw Guido recently suggest that "x = x" would be a reasonable way
> to spell "ah, this module-level name's binding may change after
> initialization" -- in lieu of not being able to say "const x'" for names not
> in that class.<snip>
Keyword issues break up into two major parts, actions and semantic
descriptions.
Extending the languages semantic descriptions is certainly badly
affected by a syntax relying on reserved keywords, e.g., static in the C
related languages. A very well designed grammar, and on this point
Fortran's grammar has been well designed, recognizes that semantic
descriptions belong in a different namespace from actions, and that this
is an aspect of the language that requires modification of the processor
(i.e., that users other than compiler writers will not intervene into
this namespace), and that, as a result, the semantic description
namespace should be clearly syntactically distinguished from the action
namespace.
Actions involve two considerations, the ability to perform the actions,
and a convenient syntax for the actions. In most cases the convenient
syntax is a procedure or function call, and such cases are adequately
addressed by a namespace or module system. Other cases, e.g., special
forms of initialization or new operators, can be extended through
additional syntax that was illegal in the past. However, this new syntax
should rely on punctuation or bracketing and not on the use of keywords,
as the reliance on keywords can intrude on the user's namespace.
Navindra Umanee
Tim Peters <tim...@email.msn.com> wrote:
> entire value is in what it "doesn't break later". Shadowing of outer vrbls
> by same-named vrbls in inner scopes is of much the same flavor in practice:
> doing it on purpose is abuse, but it can save your bacon all the same.
You think? I do it all the time:
public void setValue(Value value)
{
this.value = value;
}
I dunno, it just seems neater to me and I don't usually feel like
making up new, clumsier names.
Navin
PS It's not nice snipping out the newsgroup on which the thread
originated in the first place and without at least some kind of
prior warning.
Gordon McMillan
Piet van Oostrum wrote:
> I must admit that I don't like to see "while 1:" and I hate:
>
> while 1:
> line = file.readline()
> if not line: break
> ...
>
> where I would prefer something with the semantics of:
>
> while (line = file.readline()):
> ...
From my C days, I am rather fond of the latter construction, but I
think our beloved dictator was wise not to give in to those who
would have an assignment return a value. (And despite what various
whiny "human rights" groups would have you believe, there is no
credible evidence that he bears any responsibility for the
disappearance of any "innocent" bystanders, nor indeed, that any of
those termed "innocent" were anything other than provocateurs for
the scum-sucking slime who would perversely mix the semantics of
"statement" and "expression" with the goal of thwarting the ideals
embodied and defended by our heroic brothers in the Peoples
Semantic Liberation Army! Long Live Guido!!).
A for loop is a better construction for this situation anyways:
----------------------------------------------------------
import exceptions
class Rdr:
def __init__(self, f):
self.f = f
self.pos = -1
def __getitem__(self, n):
if n == self.pos + 1:
self.pos = n
val = self.f()
if val:
return val
raise exceptions.IndexError
raise exceptions.IOError, "Sequential access only"
if __name__ == '__main__':
f = open('c:/temp/test.txt','r')
rdr = Rdr(f.readline)
for ln in rdr:
print ln,
------------------------------------------------------
- Gordon
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.
Fredrik Lundh
>So I'll rectify that here: In effect, Perl got around the "new keyword"
>issue by reserving all possible keywords! That's one happy consequence of
>forcing all user names to start with $, %, etc. Even read a bit by Larry
>Wall that said it was an intentional consequence -- Perl's not as nuts as
>Larry looks <wink -- or maybe that's backwards>.
yes, it's backwards:
tokenizer stats (/py15/lib)
134 files
13422 reserved keywords
53659 symbols
but of course, if Python had as many weird %&/$./&#'~ incantations
as Perl, we wouldn't need to refer to things by their real names quite
as often...
Cheers /F
fre...@pythonware.com
http://www.pythonware.com
Dave Kirby
the problem I have with the 'official' method of
while 1:
...do stuff
if condition: break
...more stuff
is that the flow of control is no longer shown by the indentation -
the 'if condition' should (IMHO) be on the same level of indentation
as the 'while'. For this reason the proposal of
do:
suiteA
while cond:
suiteB
is far more appealing. However there is a problem with it as it
stands. To be able to replace the original the exit condition should
be able to appear multiple times. With the syntax given above this
becomes ambiguous:
do:
suiteA
while cond1:
suiteB
while cond2:
suiteC
is the final 'while' part of the do loop, or the start of a new loop?
If the language is going to change in this respect (which I doubt from
reading the posts by GvR) then my preference would be for the 'if
cond: break' statement to be replaced by an 'exit_if cond:' (or
similar) statement at the same level of indentation as the 'while'.
i.e.
while 1:
...do stuff
exit_if condition1:
...more stuff
exit_if condition2:
...stuff outside of loop
this also removes the need for a final 'pass', since 'exit_if' does
not mark the start of a new block.
To my mind this is far more readable than the original, since you can
see immediately at what points the loop is going to be exited. The
only problem I can see with it is that it introduces a new keyword,
which is generally A Bad Thing. Something similar could be done with
the existing keywords, perhaps by turning the 'if cond: break' round -
i.e.
while 1:
...do stuff
break if condition:
...more stuff
this would not break any existing code, since it is currently a syntax
error. The one problem with this is that it may look a bit too perlish
for some peoples taste.
Just my 0.02 Euro's worth.
sure-this-has-all-been-flogged-to-death-before-but-that-was-before-my-time-ly
yours
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
Fredrik Lundh
Gordon wrote:
>A for loop is a better construction for this situation anyways:
>
>----------------------------------------------------------
>------------------------------------------------------
You mean:
import fileinput
for ln in fileinput.input("c:/temp/test.txt"):
print ln,
don't you?
PS. to loop over multiple files, use a sequence of filenames (list,
tuple, etc) instead of just a single file. if you omit the names,
they default to sys.argv[1:], or stdin if no arguments were given.
Chris Wright
Tim Peters wrote in message <000301bd9e45$dbc206e0$3fa22299@tim>...
>One fine idea Fortran had that subsequent language fashion rejected was
>*not* reserving its keywords.
That's one of the most appealing features of Forth
: + 2 / ;
(re-defines "plus" to be "halve")
Some forth implementations warn you and Forth in ROM won't let you (without
being underhand about the dictionary location), but many just let you quite
happily aim at your big toe and pump a whole magazine into it!
cheers
chris
Gordon McMillan
Fredrik Lundh writes:
> Gordon wrote:
> >A for loop is a better construction for this situation anyways:
> You mean:
>
> import fileinput
I don't suppose I could interest you in an extensive collection of
completely original wheels, many of them almost round....
- Gordon
Terry Reedy
In article <35914ff7...@read.news.global.net.uk>,
dki...@see.sig.for.addr says...
>If the language is going to change in this respect (which I doubt from
>reading the posts by GvR) then my preference would be for the 'if
>cond: break' statement to be replaced by an 'exit_if cond:' (or
>similar) statement at the same level of indentation as the 'while'.
>i.e.
>
> while 1:
> ...do stuff
> exit_if condition1:
> ...more stuff
> exit_if condition2:
>
> ...stuff outside of loop
>
>this also removes the need for a final 'pass', since 'exit_if' does
>not mark the start of a new block.
I like this about as much my original proposal (but see revision below).
Although it reverses the sense of the test to a break test rather
continuation test, it puts 'while' at the top to mark the loop
beginning. Since we already condense else_if as elif, exit_if could
condense to exif, tho this is maybe too similar :-).
Hmmm. REVISED PROPOSAL: stick with continuation tests and reuse'elif'
as an optional dependent block marker. Thus, no new keyword!
while condition a:
do stuff A
elif conditon b:
continue with stuff B
elif condition c:
continue with block C
While this is a slight abuse of the normal meaning of what elif
abbreviates, it is no more abusive than the current usage of 'else'
after while or for. It would make 'if' and 'while' compounds
syntactically parallel: both could be followed by any number of 'elif'
blocks and then by possibly one 'else' block'. (And I suspect that the
current parser/compiler machinery for 'if' could be modified and reuse
for an extended 'while' construct.)
Terry J. Reedy
Tim Peters
> ... In effect, Perl got around the "new keyword" issue by reserving
> all possible keywords! That's one happy consequence of forcing all
> user names to start with $, %, etc. Even read a bit by Larry Wall
> that said it was an intentional consequence -- Perl's not as nuts
> as Larry looks <wink -- or maybe that's backwards>.
[Fredrik]
> yes, it's backwards:
>
> tokenizer stats (/py15/lib)
> 134 files
> 13422 reserved keywords
> 53659 symbols
>
> but of course, if Python had as many weird %&/$./&#'~ incantations
> as Perl, we wouldn't need to refer to things by their real names quite
> as often...
I take it as evidence that Python can afford to add 40237 more keywords
before there's a 50/50 chance of colliding with a user's name <wink>.
nothing-like-hard-data-to-settle-an-issue-ly y'rs - tim
Tim Peters
About dowhiledo and so on, see Knuth's classic paper "Structured Programming
with Gotos" for a wealth of other creative ideas (he even mulls over how
nice it would be to use indentation instead of brackets to denote program
structure <wink>).
I'm happy enough with
if condition:
break
most days myself, and definitely prefer that to the hide-the-important-part
if condition: break
on all days.
evenings-until-11pm-too-ly y'rs - tim
Tim Peters
[tim]
> ... Shadowing of outer vrbls by same-named vrbls in inner scopes
> is of much the same flavor in practice: doing it on purpose is abuse,
> but it can save your bacon all the same.
[Navindra Umanee]
> You think?
Hmm. Nope, haven't changed my mind since yesterday!
> I do it all the time:
>
> public void setValue(Value value)
> {
> this.value = value;
> }
>
> I dunno, it just seems neater to me and I don't usually feel like
> making up new, clumsier names.
Sure! No problem here. I really had in mind traditional lexical block
nesting (a la, say, C or Pascal). Since you appear to be writing Java
above, note that Java flatly forbids *that* kind of shadowing (although most
languages do not; see section 14.3.2 of the Java Spec for details).
Shadowing of class fields (which you're doing above) raises different issues
(and, in Java, follows looser rules).
> Navin
>
> PS It's not nice snipping out the newsgroup on which the thread
> originated in the first place and without at least some kind of
> prior warning.
OK, here's your warning: I get at comp.lang.python thru its mailing-list
gateway; what I see is email, and what I post is email. Don't see any
newsgroup lists, or article ids, or anything else of that nature. So, e.g.,
I couldn't tell you which group this thread started in unless you both told
me the answer and paid me to bother <wink>.
all-c.l.p.'ers-are-nice-plus-too-stupid-to-snip-anyway<wink>-ly y'rs - tim
Navindra Umanee
Tim Peters <tim...@email.msn.com> wrote:
> above, note that Java flatly forbids *that* kind of shadowing (although most
> languages do not; see section 14.3.2 of the Java Spec for details).
True.
> OK, here's your warning: I get at comp.lang.python thru its mailing-list
> gateway; what I see is email, and what I post is email. Don't see any
Sorry, I hadn't realised this.
> I couldn't tell you which group this thread started in unless you
> both told me the answer and paid me to bother <wink>.
Thread started in comp.os.linux.advocacy where some poor twink asked
some advice on whether he should use Perl or Python. Someone replied
and mentioned that Python was whitespace-sensitive. I opened my mouth
and said the word "stupid" a couple of times. Was promptly flamed by
Christopher B. Browne who crossposted to comp.lang.misc and
comp.lang.python. So that's the story behind this flamewar, sorry for
unknowingly spamming all those mailboxes.
Navin
Mike Coffin
"Dirk Heise" <dhe...@metronet.de> writes:
> But i think it's not a problem - just use the feature and correct it if
> it's not
> what you intended. You blame Pythons syntax, but the real problem is:
> An "intelligent" editor can never rely on the syntactical correctness of
> the source
> code - when i edit it, it's nearly almost an incorrect program.
>
> So you MUST use heuristics, and they may err. What's the problem?
I have no problems with Python when I'm just typing in brand new text.
The problems happen later, when the program is largely or completely
working, and I'm reorganizing things for one reason or another.
(Personally, I find that the only way I can achieve good code or good
prose is by frequent revision.) So, I find myself moving blocks of
code around quite frequently---moving some statements out of a loop,
moving a block into a subroutine, etc. This is where
indentation-as-syntax causes extra work. E.g. suppose, in Perl, I have
if ($a eq $b) {
foo();
}
If I paste in a block to create
if ($a eq $b) {
foo();
while(xxx()) {
foo();
bar();
}
}
then there is absolutely no ambiguity. The while loop is inside the
if statement, because is comes before the closing brace. My editor
can ident that properly with one keystroke, and no heuristics are
required. On the other hand if I have the Python block
if a = b:
foo()
and paste in a block to create
if a = b:
foo()
while xxx():
foo()
bar()
the editor cannot possibly know that the while loop was intended to go
inside the if statement. The only way to tell the editor (or the
Python parser) what's going on is to indent it manually.
-mike
Dirk Heise
Mike Coffin wrote:
>
> If I paste in a block to create
>
> if ($a eq $b) {
> foo();
>
> while(xxx()) {
> foo();
> bar();
> }
>
> }
>
> then there is absolutely no ambiguity. The while loop is inside the
> if statement, because is comes before the closing brace. My editor
> can ident that properly with one keystroke, and no heuristics are
> required. On the other hand if I have the Python block
>
> if a = b:
> foo()
>
> and paste in a block to create
>
> if a = b:
> foo()
>
> while xxx():
> foo()
> bar()
>
> the editor cannot possibly know that the while loop was intended to go
> inside the if statement. The only way to tell the editor (or the
> Python parser) what's going on is to indent it manually.
>
> -mike
>
Allright, i agree. But in fact, you'll get much more severe problems
in C++:
if(ITS_UNIX_OR_MAYBE_A_YOU_KNOW_WHAT)
{
IFeelLikeAPoetToDay();
cout <<
"Dem Wurme gleich ich"
"der, im Staub sich windend,"
"weicht"
"des Wandrers Schritt [Goethe]"
<< endl;
}
and other of these whitespace-insensitive languages
(serious design flaw).
More seriously, not being a poet, i use to write complex
boolean rules like this in C/C++:
if( (hugry() OR thirsty())
AND
(NoMoney())
AND
(ATMAround() OR SomebodyThereWhoLendsMeMoney())
)
// and unfortunately, that's a little bit difficult in Python
...
So, i think, it would be quite difficult to write a perfect editor
adapted to the indentation "rules" of human programmers
for all possibilities... You constructed an example for Python,
i constructed one for C/C++... And don't tell me that this a
pathological example; programs are pathological in general ;-)
Dirk Heise, Braunschweig, Germany
dhe...@metronet.de
Barry A. Warsaw
>>>>> "MC" == Mike Coffin <m...@Eng.Sun.COM> writes:
MC> the editor cannot possibly know that the while loop was
MC> intended to go inside the if statement. The only way to tell
MC> the editor (or the Python parser) what's going on is to indent
MC> it manually.
While it's true that you have to think about it a little more,
something like python-mode makes it very easy to indent or dedent
blocks of code rigidly. Okay, it's not as convenient as going to the
opening brace and hitting one keystroke to indent the entire
expression, but it's also true that there is *much* less variability
in real Python coding layouts than there are in, say C. And that's a
good thing.
In practice it just doesn't seem to me to be much of a problem.
-Barry
Mike Coffin
bwa...@cnri.reston.va.us (Barry A. Warsaw) writes:
> While it's true that you have to think about it a little more,
> something like python-mode makes it very easy to indent or dedent
> blocks of code rigidly. Okay, it's not as convenient as going to the
> opening brace and hitting one keystroke to indent the entire
> expression, but it's also true that there is *much* less variability
> in real Python coding layouts than there are in, say C. And that's a
> good thing.
>
> In practice it just doesn't seem to me to be much of a problem.
It's not a BIG problem; it's a nagging problem. When I maintain
Python code, I curse under my breath every ten minutes or so when I
have to manually indent a chunk of code instead of hitting "F12". Not
to say I don't curse under my breath occasionally for other reasons
when I'm messing with other languages.
Sorry if I made it sound like a big problem. The conversation started
when someone wrote
"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)."
For me, the cutting/pasting problem I described is a lot more irksome
than tabs vs. spaces.
-mike
Michael Scharf
Dirk Heise wrote:
>
> Allright, i agree. But in fact, you'll get much more severe problems
> in C++:
> if(ITS_UNIX_OR_MAYBE_A_YOU_KNOW_WHAT)
> {
> IFeelLikeAPoetToDay();
> cout <<
> "Dem Wurme gleich ich"
> "der, im Staub sich windend,"
> "weicht"
> "des Wandrers Schritt [Goethe]"
> << endl;
> }
..and I had today a long debug session with a C++ file
that was edited on a Windows mashine. LF were replaced
by CR/LF. g++ compiled it without warning but later
at link time there were some unresolved references...
After I replaces all CR/LF with LF (using a Python script,
what else) everything worked fine.
Finally 'diff --ignore-space-change' did not show any difference
to the between those two 'whitespace-different' files.
I could not figure out what it was, but the only
difference between the working and the not-working
file was "whitespace"...
So much about "whitespace-insensitive languages".
Michael
--
''''\ Michael Scharf
` c-@@ TakeFive Software
` > http://www.TakeFive.com
\_ V mailto:Michael...@TakeFive.co.at
Hannu Koivisto
"Dirk Heise" <dhe...@metronet.de> writes:
| Allright, i agree. But in fact, you'll get much more severe problems
| in C++:
| if(ITS_UNIX_OR_MAYBE_A_YOU_KNOW_WHAT)
| {
| IFeelLikeAPoetToDay();
| cout <<
| "Dem Wurme gleich ich"
| "der, im Staub sich windend,"
| "weicht"
| "des Wandrers Schritt [Goethe]"
| << endl;
| }
What is the problem here? Except that you have written that piece
of code very unclearly, not indenting it in any sane way. For
example, as I'm writing this followup with Emacs, I can copypaste
your code below and let cc-mode reindent it. Here we go:
if(ITS_UNIX_OR_MAYBE_A_YOU_KNOW_WHAT)
{
IFeelLikeAPoetToDay();
cout <<
"Dem Wurme gleich ich"
"der, im Staub sich windend,"
"weicht"
"des Wandrers Schritt [Goethe]"
<< endl;
}
From what I know about German language, your poem doesn't make
any sense to me (well, I don't know much German, I can mainly say
"Ich kann nicht Deutch sprechen" :). Still, "ichder",
"windend,weicht" etc. sound quite strange. Thus I propose you
insert newlines to your poem. If you want the _poem_ indented the
way you indented your _code_, then you might also want to add few
spaces. Like this:
if(ITS_UNIX_OR_MAYBE_A_YOU_KNOW_WHAT)
{
IFeelLikeAPoetToDay();
cout <<
"Dem Wurme gleich ich\n"
" der, im Staub sich windend,\n"
" weicht\n"
"des Wandrers Schritt [Goethe]"
<< endl;
}
Is this what you wanted? If you mean that this produces the
result what you wanted the compiler to generate from your
original piece of code, then I'd like to remind you that we are
talking about programming languages here, not typesetting
languages like LaTeX.
| and other of these whitespace-insensitive languages
| (serious design flaw).
| More seriously, not being a poet, i use to write complex
| boolean rules like this in C/C++:
|
| if( (hugry() OR thirsty())
| AND
| (NoMoney())
| AND
| (ATMAround() OR SomebodyThereWhoLendsMeMoney())
| )
| // and unfortunately, that's a little bit difficult in Python
| ...
What's the difficulty? I write such complicated boolean rules in
Python all the time. Well, I don't format them like you (because
I want that everyone else is able to read them too), but more
like, for example:
if (hungry() or thirsty()) \
and NoMoney() \
and (ATMAround() or SomebodyThereWhoLendsMeMoney()):
...
| for all possibilities... You constructed an example for Python,
| i constructed one for C/C++... And don't tell me that this a
If I failed to see the point in your C/C++ example, please
explain.
--
Hannu Koivisto | What you see is all you get.
NOYB | - Brian Kernighan
-------------------------------------------------------------
Hannu Koivisto
Michael Scharf <Michael...@Rhein-Neckar.de> writes:
| ..and I had today a long debug session with a C++ file
| that was edited on a Windows mashine. LF were replaced
| by CR/LF. g++ compiled it without warning but later
| at link time there were some unresolved references...
|
| After I replaces all CR/LF with LF (using a Python script,
| what else) everything worked fine.
|
| Finally 'diff --ignore-space-change' did not show any difference
| to the between those two 'whitespace-different' files.
|
| I could not figure out what it was, but the only
| difference between the working and the not-working
| file was "whitespace"...
|
| So much about "whitespace-insensitive languages".
I hope you understand that lousy _implementations_ (and their
problems) don't neccessarily have anything to do with the
_language_ (or its possible problems).
It's a well known fact that many Unix applications can't handle
MS-DOS/Windows newlines. If this was news to you, then I can
guarantee you will face many more surprises if you try to write
portable programs.
Either use cvs that _may_ at least partially solve your problem
(it has some client/server features for those newline
differences between platforms), or keep your files with LF
newlines also in Windows (most Windows applications, at least
based on my experience in writing portable programs, can handle
them). For example, Windows version of Emacs doesn't muck with
them if you tell it so.
Navindra Umanee
Michael Scharf <Michael...@Rhein-Neckar.de> wrote:
> ..and I had today a long debug session with a C++ file
> that was edited on a Windows mashine. LF were replaced
> by CR/LF. g++ compiled it without warning but later
> at link time there were some unresolved references...
Irrelevant. Must be a compiler/linker bug. Besides, what is the
point of comparing Python to C++? We all know C++ isn't exactly a
model language.
The real discussion is whether Python would have been a better
language if it had "hard" delimiters. So far, it would seem that
Python, as it is now, makes for easier, more natural reading by humans
but it makes the job of automated tools a little harder and sometimes
impossible.
Either way, I'm sure it would be relatively easy to add these hard
delimiters to Python if you really wanted them and write a
preprocessor to strip them out and replace them with whitespace. The
preprocessor would even be written in Python.
> After I replaces all CR/LF with LF (using a Python script,
> what else) everything worked fine.
This is a simple search/replace editor operation.
> I could not figure out what it was, but the only
> difference between the working and the not-working
> file was "whitespace"...
Bugs do happen, although maybe not in the Python part of the
universe. :)
more-and-more-interested-in-python'ly yrs,
Navin
Tor Iver Wilhelmsen
On 26 Jun 1998 06:53:27 GMT, Navindra Umanee <navi...@cs.mcgill.ca>
uttered:
>This is a simple search/replace editor operation.
Or using ASCII mode when transferring with FTP.
--
"I had to upgrade the memory of my 8088 from to 256K to 640K just to play [Demon's Winter]."
- gmad...@usa.net
Tor Iver Wilhelmsen http://www.pvv.org/%7etoriver/
Fredrik Lundh
(posted and mailed)
>The real discussion is whether Python would have been a better
>language if it had "hard" delimiters. So far, it would seem that
>Python, as it is now, makes for easier, more natural reading by humans
>but it makes the job of automated tools a little harder and sometimes
>impossible.
footnotes:
-- to generate code, tools can use something like the CodeGenerator
backend (see an earlier post). to parse code, we use a proprietary
tokenizer which generates the necessary INDENT and DEDENT tokens
(tweaking the tokenizer.py standard module to do the same isn't that
hard).
-- also see the parser module:
ast2tuple: Creates a tuple-tree representation of an AST.
compileast: Compiles an AST object into a code object.
expr: Creates an AST object from an expression.
suite: Creates an AST object from a suite.
tuple2ast: Creates an AST object from a tree representation.
(that is, you can use to both to analyze and generate Python
code -- the tuple representation is a bit unwieldy, though...).
>Either way, I'm sure it would be relatively easy to add these hard
>delimiters to Python if you really wanted them and write a
>preprocessor to strip them out and replace them with whitespace. The
>preprocessor would even be written in Python.
$ more Tools/scripts/pindent.py
#! /usr/local/bin/python
# This file contains a class and a main program that perform two
# related (though complimentary) formatting operations on Python
# programs. When called as "pindend -c", it takes a valid Python
# program as input and outputs a version augmented with block-closing
# comments. When called as "pindent -r" it assumes its input is a
# Python program with block-closing comments but with its indentation
# messed up, and outputs a properly indented version.
# A "block-closing comment" is a comment of the form '# end <keyword>'
# where <keyword> is the keyword that opened the block. If the
# opening keyword is 'def' or 'class', the function or class name may
# be repeated in the block-closing comment as well. Here is an
# example of a program fully augmented with block-closing comments:
# def foobar(a, b):
# if a == b:
# a = a+1
# elif a < b:
# b = b-1
# if b > a: a = a-1
# # end if
# else:
# print 'oops!'
# # end if
# # end def foobar
# Note that only the last part of an if...elif...else... block needs a
# block-closing comment; the same is true for other compound
# statements (e.g. try...except). Also note that "short-form" blocks
# like the second 'if' in the example must be closed as well;
# otherwise the 'else' in the example would be ambiguous (remember
# that indentation is not significant when interpreting block-closing
# comments).
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>
Dirk Heise
Hannu Koivisto wrote:
> if (hungry() or thirsty()) \
> and NoMoney() \
> and (ATMAround() or SomebodyThereWhoLendsMeMoney()):
I didn't know that the backslash trick works in Python. Shame on me,
and thank you.
You mention a re-indenter, but i have a problem with that:
It'll work fine on syntactically correct programs, but during editing,
THIS ISN'T THE CASE! I mean, this is not a real battle, i just
wanted to show that an "intelligent editor" always has a hard time to
do EVERYTHING right. (albeit being useful even though it might err)
And i forgot the newlines, you're right again -
didn't really test the poem-like program.
Here's my lousy translation for the english-speakers, sorry, Goethe:
"I'm like a worm, winding in the dust, escaping from the wanderers steps"
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...)"
Hannu Koivisto
"Dirk Heise" <dhe...@metronet.de> writes:
| You mention a re-indenter, but i have a problem with that:
| It'll work fine on syntactically correct programs, but during editing,
| THIS ISN'T THE CASE! I mean, this is not a real battle, i just
All the relevant information _to the point_ you are editing in,
is known for on-the-fly indentation to be possible (at least for
most common languages). As a matter of fact, during editing
automatically indenting editor can help you to spot syntactic
problems! I have a feeling that you haven't used Emacs utilizing
its those features especially targeted for writing programs, so
I'll try to construct a simple example:
Let's say I'm writing a multiline if statement in Python and I
don't remember that the mentioned 'backslash trick' works in
Python. The intention is to get something like this:
if (cond() and cond2()) \
or (cond3() and cond4()):
...
but as I don't remember the use of backslash, I write
if (cond() and cond2())<return>
X
where, after pressing return, cursor moves to the location of
"X", that is, to next line and to the same horizontal position
with "if". I immediately know that (because in my python-mode
configuration <return> is bound to newline-and-indent (which
inserts newline and indents according to current major mode))
something is wrong in what I just wrote, because the indentation
is not what it should be. Now I remember that some languages use
backslash as the line continuation indicator, so I decide to try
if it worked in Python too:
if (cond() and cond2()) \<return>
X
voi'la, it indents the new line correctly so the syntax is at
least more likely to be correct than in the previous case.
The same applies in, for example, C/C++. If I forget ";" from
the end of the line or something similar, the wrong indentation
immediately tells me that I just made a mistake.
The power is out there :) Just go and download Emacs, make
yourself familiar with its features, and then we can continue
this discussion.
Dirk Heise
Hannu Koivisto wrote:
> "Dirk Heise" <dhe...@metronet.de> writes:
>
> | You mention a re-indenter, but i have a problem with that:
> | It'll work fine on syntactically correct programs, but during editing,
> | THIS ISN'T THE CASE! I mean, this is not a real battle, i just
>
> All the relevant information _to the point_ you are editing in,
> is known for on-the-fly indentation to be possible (at least for
> most common languages).
You suppose that the program is syntactically correct to
the point i'm editing. That's something i didn't assume.
As long as it's the case, EMACS will reindent correctly,
i conclude from your explanations. Okay. Understood.
Is there a version of EMACS with a built-in Python ?
This would at least be of enough interest to me to give it
a try.
Dirk
M.A.Miller
>>>>> "Dirk" == Dirk Heise <dhe...@metronet.de> writes:
> Is there a version of EMACS with a built-in Python ?
It is not necessary to have an interpreter built-in. You can use
your own Python to execute a buffer or region (either via menu or
typed commands).
Mike
P.S. If your emacs and/or python set-up does not already include
python-mode (the Debian python packages include it, not sure
about others), you can find it and installation info at
<http://www.python.org/emacs/python-mode/>.
Tim Peters
[tim]
> I couldn't tell you which group this thread started in unless you
> both told me the answer and paid me to bother <wink>.
[Navindra Umanee]
> Thread started in comp.os.linux.advocacy where some poor twink
> asked some advice on whether he should use Perl or Python.
Such an easy question, eh?
> Someone replied and mentioned that Python was whitespace-sensitive.
> I opened my mouth and said the word "stupid" a couple of times.
I like "braindead" better, but "stupid" is fine too -- it expresses many
(although, I think, not most) initial reactions.
> Was promptly flamed by Christopher B. Browne who crossposted to
> comp.lang.misc and comp.lang.python. So that's the story behind
> this flamewar, sorry for unknowingly spamming all those mailboxes.
No apology needed, Navindra! The Python list is the *natural* place to
knock Python's syntax. I hope you stick around long enough to give Python a
try (http://www.python.org). There are a bunch of other braindead things in
Python too -- and most experienced Python users will defend every one of
them to the death <wink>.
curly-braces-are-their-own-reward-ly y'rs - tim
Hannu Koivisto
"Dirk Heise" <dhe...@metronet.de> writes:
| You suppose that the program is syntactically correct to
| the point i'm editing. That's something i didn't assume.
Yes, sorry for not mentioning this assumption -- I never leave
any broken if sentences or similar behind me in the code because
I would probably forget them :)
| Is there a version of EMACS with a built-in Python ?
| This would at least be of enough interest to me to give it
| a try.
M.A.Miller already gave a good answer to this question. I'd also
like to add that you can run python interpreter in an emacs
buffer in a separate window (which can be in the same window
manager window with another source code buffer/window or in a
separate window manager window (these are called frames in emacs
terminology)).
Gary Capell
Mike Coffin <m...@Eng.Sun.COM> writes:
>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. :-)
I disagree.
>[example of dropping some code either inside or after a loop]
>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.
This isn't a language problem, but an editor problem.
For _both_ indentation-based and brace-based syntax, you have
to tell the editor whether the pasted code is inside or
after the loop. For most existing editors this is
easier to do for brace-based style (by placing the code
before or after the closing brace). To do this easily
for indentation-based syntax, you need an outline editor.
Plus, you don't have to also hit the "reindent" button :-)
Unfortunately, I don't know of any really good outline editor
for Unix/X.
--
http://www.cs.usyd.edu.au/~gary/
Python: executable pseudo-code; Perl: executable line noise
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.)
Egbert Hess
Mike Coffin wrote:
Well, here is a starting point to save your mind from too much stress.
Extend the reformatter (if that is possible, which it is for Emacs, at least)
in such a way that it can cope with block start&end symbols inside of
comments.
E.g. a line like
# { ... some comment on the block's purpose ...
would be added at the start of each code block while a line like
# }
would follow each code block.
Now your editor/reformatter can view each code block as in any other "explicit
block oriented" programming language.
Do not forget the Python purists and define a "stripper" which removes the
structuring { } in the comments and any empty-after-{}-stripping comment
lines.
Hope that serves your needs.
PS: As soon as you have extended any reformatter please share your gained
knowledge.
Mike Coffin
Egbert Hess <egb...@bluewin.ch> writes:
> Extend the reformatter (if that is possible, which it is for Emacs, at least)
> in such a way that it can cope with block start&end symbols inside of
> comments.
> E.g. a line like
> # { ... some comment on the block's purpose ...
> would be added at the start of each code block while a line like
> # }
> would follow each code block.
> Now your editor/reformatter can view each code block as in any other "explicit
> block oriented" programming language.
> Do not forget the Python purists and define a "stripper" which removes the
> structuring { } in the comments and any empty-after-{}-stripping comment
> lines.
>
> Hope that serves your needs.
Not really. Most of the code I deal with I didn't write, so it
doesn't contain such comments. Also, there would be niggling
difficulties with braces inside legitimate comments.
I've toyed with the idea of writing a Python mode that automatically
adds in braces to match existing indentation when a file is read in,
uses the braces to indent things while I'm editing, and then deletes
them when the file is written out. So far I've resisted the
temptation :-)
-mike
Dirk Heise
>
> your own Python to execute a buffer or region (either via menu or
> typed commands).
Well, okay. But i don't want to necessarily write Python code
with EMACS, i'd rather like to program EMACS in Python -
that means, instead of using a LISP to program it, use Python.
Is this possible, too? (By calling some DLL functions via an
extended Python, e.g.) Sorry, my question was imprecise.
[Reading the lengthy subject line of this thread, i remember my 4 year
old son playing with my CD collection yesterday.
Before he ruined "Licensed to ill" by
the Beastie Boys, i gave him a 2 year old Perl CD ROM i never
used he can play with. He was very glad to own a shining CD ROM.
So, i thought, this CD finally was good for something. This
doesn't prove any superiority of Python. It just says: Yes, Perl
is useful in some way, at least when pressed on CD. I only gotta
take care he doesn't find a computer where he can install it and start
using it. I'm responsible for his education. Hope it's not as easy to
install as PythonWin.]
Dirk
Barry A. Warsaw
>>>>> "EH" == Egbert Hess <egb...@bluewin.ch> writes:
EH> Extend the reformatter (if that is possible, which it is for
EH> Emacs, at least) in such a way that it can cope with block
EH> start&end symbols inside of comments.
Probably won't work well in practice. At its C core, Emacs major
modes are partially syntax table driven, which is why things like
skipping over comments, strings, and balanced brace expressions can
happen so fast. The latter is great for C and Lisp, not as useful for
Python. The point is that unbalanced braces inside comments will be
ignored, and you can't teach Emacs' syntax tables to treat even #{ and
#} as balanced brace expressions (hmm, but you might be able to teach
it that # is a comment starter iff followed by a space).
Another weird Emacs thing, while I'm here. Ever notice that if you
put a paren or brace in column zero inside a triple quoted string,
things like font-lock get badly messed up? Thank the Emacs C layer
which hard-codes this C/Lispism in its parsing routines.
-Barry