Larry Wall's comment on python...
Rod Stephenson
asked his thoughts on other scripting languages, he makes the
following observation about python
"Python is cool to look at small bits of, but I think the "outline"
syntax breaks down with larger chunks of code. I'm with Aristotle on
the structure of discourse--a story should have a beginning, and
middle, and an end. So should blocks"
I'm not quite sure what he's trying to get at here - I guess that for
a long heavily indented chunk of code, you could lose track of the
overall structure, but I don't write code this way.
Any comments?
laotseu
def fun(args):
#BEGIN
if ceci or cela:
#BEGIN
do_this(with_that)
[snip a lot of code]
#END
#END
So what the problem with blocks ?
laotseu
bru...@tbye.com
> "Python is cool to look at small bits of, but I think the "outline"
> syntax breaks down with larger chunks of code. I'm with Aristotle on
> the structure of discourse--a story should have a beginning, and
> middle, and an end. So should blocks"
>
> I'm not quite sure what he's trying to get at here - I guess that for
> a long heavily indented chunk of code, you could lose track of the
> overall structure, but I don't write code this way.
>
> Any comments?
The very idea of Larry Wall lecturing on code readability is hilarious.
-Dave
David LeBlanc
David LeBlanc
Seattle, WA USA
Erik Max Francis
> "Python is cool to look at small bits of, but I think the "outline"
> syntax breaks down with larger chunks of code. I'm with Aristotle on
> the structure of discourse--a story should have a beginning, and
> middle, and an end. So should blocks"
>
> I'm not quite sure what he's trying to get at here - I guess that for
> a long heavily indented chunk of code, you could lose track of the
> overall structure, but I don't write code this way.
>
> Any comments?
I'm not really sure what he's getting at, either. It sounds like he's
suggesting that using indentation for setting off blocks is confusing,
but this is a standard objection to Python that most people have
(especially those with experience in other languages), and my experience
is most people immediately drop this objection after using it for a
little while.
But at some level, what would you expect him to say?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ There is nothing so subject to the inconstancy of fortune as war.
\__/ Miguel de Cervantes
Church / http://www.alcyone.com/pyos/church/
A lambda calculus explorer in Python.
Robert Oschler
"laotseu" <bde...@nospam.free.fr> wrote in message
news:3D7958D...@nospam.free.fr...
> > Any comments?
>
> def fun(args):
> #BEGIN
> if ceci or cela:
> #BEGIN
> do_this(with_that)
> [snip a lot of code]
> #END
> #END
>
>
Although new to Python, I've read many posts complaining about the indenting
issue, usually from "other language" proponents. But for the longest time
I wondered why not do exactly what you have done with comment lines? In
essence I'm saying, I'm glad you made this point. :)
In Pascal, C/C++ and VB (no rock-throwing please, it was a paycheck) I
frequently did things like the following, to use a C example:
if (something == something_else)
{
} // if (something == something_else)
As you can see, using comments to label my end blocks explicitly. For me
this issue was never an issue.
thx
François Pinard
> The very idea of Larry Wall lecturing on code readability is hilarious.
While I understand the sentiment, history adds some perspective.
I've been following Perl since version 1, and in the beginnings, despite the
syntax was admittedly eclectic, Perl was much easier to read then, than now.
Perl grew many $X variables where X was a special character, but in the state
of the things at the time, it was still bearable.
The legibility problem developed progressively when adding things to Perl,
while trying to stay compatible to what it was. Running out of special
characters, $X started to use control characters. The very notion of
announcing the type of something to a prefix character ($%@&) did not mix well
when references and more complex structures were added. Larry made an effort
to clean out the syntax a bit when going from Perl 4 to Perl 5, but the damage
was already too intense for the cleanup to be effective, also considered that
the cleanup just could not be too drastic, to protect the existing code base.
I take Larry Wall as a nice and clever guy. Perl does not marry so well with
evolution, and this is probably the doom of all languages which do not enough
foresee evolution, and overly praise backward compatibility. On the other
hand, too much rapid or drastic changes might erode the user base or make it
less solid. Equilibrium is a very difficult art.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Tim Daneliuk
>
> -Dave
>
>
Well, that's true, but for all of its similarity to line noise, perl has
been an enormous contribution to our profession/community. I would never want
to diminish Wall's stature, therefore.
As someone deeply steeped in Algol-derived languages (C, PL/M, PL/I, Java ...),
I find Python's indentation approach refreshing on two (pardon the expression), levels:
- It makes the compiler/interpreter do the work instead of me - Why should I have
type {} and ; when the language can figure it out for itself.
- It causes me to factor code better. Python encourages a style that
obviates (some of) the need for the kind of syntactic structures found in older
block-structured languages.
Wall's comment is correct if you insist on Algol-style block
structuring. But Python encourages you to factor in a way that makes
such block structure different and perhaps less necessary. In
particular, the ability to combine functional, procedural, and object
constructs in a seamless way gives you the ability to do a lot of
structuring and scoping *implicitly* w/o the need for explicit
indentation or block delimiting. Python not only "Fits Your Brain", it
changes how your brain processes and reduces problems. *This*,
in my view is why the absence of block delimiters is not a big deal.
On a personal note, I've had an interesting year - I've been coding in nothing
but Python (Unix & Win32) and *assembler* (embedded PIC processors). Talk about
a contrast! Yet in both cases, the languages "Fit My Brain" for the tasks at
hand. For instance, I find almost all compiled languages (even C) intrusive
when writing code for embedded systems. Assembler is so much more expressive
there because *it directly reflects the state of the hardware being controlled.*
Similarly, I love Python for most other (higher level) tasks because *it painlessly
reflects the state of the computational problem being solved.* Now, I only wish
for an excellent Python optimizing compiler with a retargetable code generator ...
*that* would be Bliss (and I don't mean the language ;)
--
------------------------------------------------------------------------------
Tim Daneliuk
tun...@tundraware.com
Joseph A. Knapka
...whereas with Perl, you can lose track of the overall structure
in a single line, brackets or no.
-- Joe
"I'd rather chew my leg off than maintain Java code, which
sucks, 'cause I have a lot of Java code to maintain and
the leg surgery is starting to get expensive." - Me
Sean 'Shaleh' Perry
>
> Having read Wall's comments on Slashdot, I think he is really just mildly
> complaining about ridiculously long page-widths in his editor, not really
> slashing Python seriously. He's just giving some props to his own baby at
> the expense of another. (He had to say something, right?) You must agree
> that Python can lead you to horizontal scrolling in your editor - the bane
> of user interface design.
>
that was the original poster's point. When you start side scrolling it is
time to refactor. I find that I write python in much the same physical style
as I wrote in C so this has always been how I approached coding. However not
everyone has.
bru...@tbye.com
> > The very idea of Larry Wall lecturing on code readability is hilarious.
> >
> > -Dave
> Well, that's true, but for all of its similarity to line noise, perl has
> been an enormous contribution to our profession/community. I would never want
> to diminish Wall's stature, therefore.
Me neither, and I didn't intend it that way. There's just something very
pot-calling-the-kettle-black about it, that's all.
-Dave
mma...@hcsmail.com
that
> obviates (some of) the need for the kind of syntactic structures
found in older
> block-structured languages.
I would argue that the "older" block-structured languages were considered
a breakaway from the column-based languages - RPG2 and Fortran, for
instance. Although I grant the Python structure and the column-based
structures are not completely analogous, they BOTH burden the programmer
with arbitrary rules to govern the physical layout of the code. Although
this layout may be considered more elegant from a readability standpoint,
it's the enforcement of the layout that is irritating to the more
Libertarian of us. It's a mindset difference similar to that between
Pascal and C++.
Having read Wall's comments on Slashdot, I think he is really just mildly
complaining about ridiculously long page-widths in his editor, not really
slashing Python seriously. He's just giving some props to his own baby at
the expense of another. (He had to say something, right?) You must agree
that Python can lead you to horizontal scrolling in your editor - the bane
of user interface design.
Yes, I am new here. Hi, everyone.
--
Michael F. Maddox
Senior Software Engineer
Hayes
Tallahassee, FL, USA
Mark McEahern
> Although this layout may be considered more elegant from a
> readability standpoint, it's the enforcement of the layout that is
> irritating to the more Libertarian of us. It's a mindset difference
> similar to that between Pascal and C++.
So does the fact that C++ forces you to use { } as block delimiters irritate
the Libertarian in you?
// m
-
djw
[snip]
> structures are not completely analogous, they BOTH burden the programmer
> with arbitrary rules to govern the physical layout of the code. Although
I completely disagree that Python's rules for code layout are arbitrary.
D
mma...@hcsmail.com
irritate
> the Libertarian in you?
Of course it does. I need a parser that can decipher the pure randomness
of my own code. Basically, I'd like to run an SHA-512 algorithm against a
poorly-typed text file describing my program. Then, I'd just compile the
message digest.
Of course, most of my current code has one big block, main(), and I just
cut-and-paste the rest.
sism...@hebmex.com
> > main(), and I just cut-and-paste the rest.
This just makes me shudder...
sheer horror....
:-D
-gus
--
Advertencia:
La informacion contenida en este mensaje es confidencial y restringida y
esta destinada unicamente para el uso de la persona arriba indicada, Esta
comunicacion representa la opinion personal del remitente y no refleja
necesariamente la opinion de la Compañia. Se le notifica que esta
estrictamente prohibida cualquier difusion, distribucion o copia de este
mensaje. Si ha recibido esta comunicacion o copia de este mensaje por error,
o si hay problemas en la transmision, favor de comunicarse con el remitente.
Todo el correo electrónico enviado para o desde esta dirección será
procesado por el sistema de correo corporativo de HEB. Tal correo
electrónico esta sujeto a ser almacenado y puede ser revisado por alguien
ajeno al recipiente autorizado con el propósito de monitorear que se cumplan
las normas de seguridad de la empresa.
Mark McEahern
> Of course it does. I need a parser that can decipher the pure randomness
> of my own code. Basically, I'd like to run an SHA-512 algorithm against a
> poorly-typed text file describing my program. Then, I'd just compile the
> message digest.
>
> cut-and-paste the rest.
Your message brought me smiles, tears, and laughter--I haven't had that much
fun since watching Heehaw.
Cheers,
// m
-
Gillou
wkr8g7r...@yahoo.com...
Long heavily indented chunks of code is a really bad programming style
(whatever's the language).
Modern python editors can find blocks, hide/show blocks, auto indent/dedent
blocks, and find start/end of blocks.
Tabnanny does a fine job on ugly indenting.
def longfunction():
# 300 lines of code below
...
return
# end longFunction()
dsavitsk
"Gillou" <nos...@bigfoot.com> wrote in message
news:albdk2$2iro$1...@norfair.nerim.net...
> "Rod Stephenson" <vikin...@yahoo.com> a écrit dans le message de news:
> wkr8g7r...@yahoo.com...
> > Slashdot has a list of questions posed to Larry Wall (perl). When
> > asked his thoughts on other scripting languages, he makes the
> > following observation about python
> >
> > "Python is cool to look at small bits of, but I think the "outline"
> > syntax breaks down with larger chunks of code. I'm with Aristotle on
> > the structure of discourse--a story should have a beginning, and
> > middle, and an end. So should blocks"
> >
> > I'm not quite sure what he's trying to get at here - I guess that for
> > a long heavily indented chunk of code, you could lose track of the
> > overall structure, but I don't write code this way.
> >
> > Any comments?
>
> Long heavily indented chunks of code is a really bad programming style
> (whatever's the language).
> Modern python editors can find blocks, hide/show blocks, auto
indent/dedent
> blocks, and find start/end of blocks.
Further, those of us used to using, say, the treeview in Outlook [Express]
to read newsgroups, or other similarly structured interfaces, find the
hierarchy of Python indenting quite natural.
-d
Roy Smith
> Well, that's true, but for all of its similarity to line noise, perl has
> been an enormous contribution to our profession/community. I would never want
> to diminish Wall's stature, therefore.
There is no doubt that Perl was a major breakthrough. It sure beats the
horrible sed/awk/grep/shell disasters we used to write. The fact that
it's showing its age and better things have come along (building on
Perl's success and learning from its mistakes) does not in any way
diminish the magnitude of Larry's contribution. Not to mention rn and
patch (and probably some other stuff I'm forgetting at the moment).
> I find almost all compiled languages (even C) intrusive
> when writing code for embedded systems.
Back in the days when a pdp-11/45 was the hot platform to run Unix on, I
used to do a certain amount of M-6800 programming (note: two zeros, not
three). I found the best way to write code was to write it in a
(self-imposed) simplistic subset of C, and then hand-compile it into
assembler. This let me write the basic control logic in a reasonably
expressive language, but kept me close to the bare machine. It was
almost like flowcharting in pseudocode.
Writing for a machine which only has 256 bytes of RAM gives you a
somewhat different outlook on programming :-)
James J. Besemer
Rod Stephenson wrote:
>Larry Wall Wrote:
>
>"Python is cool to look at small bits of, but I think the "outline"
>syntax breaks down with larger chunks of code. I'm with Aristotle on
>the structure of discourse--a story should have a beginning, and
>middle, and an end. So should blocks"
>
>Any comments?
>
Typically, he substitutes a cute particle of rhetoric for a meaningful
response.
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
http://cascade-sys.com
Peter Hansen
> [about Larry Wall on Python]
>
> "Python is cool to look at small bits of, but I think the "outline"
> syntax breaks down with larger chunks of code. I'm with Aristotle on
> the structure of discourse--a story should have a beginning, and
> middle, and an end. So should blocks"
>
Anyone know how long is the largest chunk of code Larry Wall has
actually written in Python?
The fact he has to say "I think" about this issue implies he is
guessing. Maybe if he actually tried it he'd conclude differently.
-Peter
Peter Hansen
> Although I grant the Python structure and the column-based
> structures are not completely analogous, they BOTH burden the programmer
> with arbitrary rules to govern the physical layout of the code. Although
> this layout may be considered more elegant from a readability standpoint,
> it's the enforcement of the layout that is irritating to the more
> Libertarian of us.
I think you have the wrong meaning for "arbitrary". From the
sounds of it, you have exactly reversed which is arbitrary (your
own "libertarian" coding style) and which is "governed by fixed
rules" (Python layout).
> Having read Wall's comments on Slashdot, I think he is really just mildly
> complaining about ridiculously long page-widths in his editor, not really
> slashing Python seriously. He's just giving some props to his own baby at
> the expense of another. (He had to say something, right?) You must agree
> that Python can lead you to horizontal scrolling in your editor - the bane
> of user interface design.
I agree with the comments about Larry "having" to say something like this.
I definitely don't understand how Python, more or less than any other
language, leads to more horizontal scrolling. Pretty much all
Python code I've ever seen (though I haven't seen yours yet :-) is
roughly 80 characters max, and mine own has been about that since I
started writing C code 16 years ago.
Do you mean there is something special about Python not delimiting
blocks in the traditional ways which somehow leads you to write
much wider lines of code?
-Peter
Jay O'Connor
<bla...@crary.com> wrote:
>That is what is nice about Vi paren,bracket matching!
Vi, Emacs, half a hundred other code editors
Jay O'Connor
joco...@cybermesa.com
http://www.cybermesa.com/~joconnor
"God himself plays on the bass strings first, when he tunes the soul"
mma...@hcsmail.com
intention was to indicate the STYLE of block delimiting was arbitrary
(Nehemiah Jordan: when a task is not seen in meaningful context it is
experienced as being arbitrary). This is not totally in line with my
intentions either, as all programming language rules could be deemed
arbitrary by someone unwilling to accept the context in which they exist.
Now, I LOVE Python. I also love C++. Smalltalk and Lisp are interesting.
Perl is useful to someone somewhere. I said some things that are not as
precise as I would have liked, and I don't want to explore the semantics
of this mailing list and each individual post. Python is cool. Let's talk
about Python.
-Michael
> --
> http://mail.python.org/mailman/listinfo/python-list
Peter Hansen
> You're right. The PLACEMENT of blocks in my style is arbitrary. My
> intention was to indicate the STYLE of block delimiting was arbitrary
Probably also not true. I believe many of the choices made for Python
in its early stages were made after both experience *and*
experimentation with alternatives. Not sure about the block delimiters
(or invisibility thereof) themselves, but certainly things like the
use of the colon before a block were made because of studies suggesting
they were a Good Thing.
> Now, I LOVE Python. I also love C++. Smalltalk and Lisp are interesting.
> Perl is useful to someone somewhere. I said some things that are not as
> precise as I would have liked, and I don't want to explore the semantics
> of this mailing list and each individual post. Python is cool. Let's talk
> about Python.
My post talked exclusively about Python, so I agree with that idea. :)
Maybe you would still respond to the other Python-related question
I asked:
David LeBlanc
Python!" :)
David LeBlanc
Seattle, WA USA
> -----Original Message-----
> From: python-l...@python.org
> [mailto:python-l...@python.org]On Behalf Of Tim Peters
> Sent: Friday, September 06, 2002 20:30
> To: pytho...@python.org
> Subject: RE: Larry Wall's comment on python...
>
>
> [Peter Hansen]
> > Anyone know how long is the largest chunk of code Larry Wall has
> > actually written in Python?
>
> It was 23 lines longer than the largest chunk of code Guido has actually
> written in Perl. The difference is that Larry's code worked, and Guido's
> still doesn't. I suspect Larry may have taken a wrong lesson from that
> <wink>.
>
> > The fact he has to say "I think" about this issue implies he is
> > guessing. Maybe if he actually tried it he'd conclude differently.
>
> It was just a sound bite from an interview, and blocks aren't
> quite the same
> thing in Perl (for example, a Perl block can have its own variables, but a
> Python block can't). I bet that if Guido had designed Perl, it
> would still
> have curlies, and I defy anyone to prove that wrong. Heh.
>
> leave-rationality-to-the-rationals-this-is-language-design-ly y'rs - tim
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
Tim Peters
> Anyone know how long is the largest chunk of code Larry Wall has
> actually written in Python?
It was 23 lines longer than the largest chunk of code Guido has actually
written in Perl. The difference is that Larry's code worked, and Guido's
still doesn't. I suspect Larry may have taken a wrong lesson from that
<wink>.
> The fact he has to say "I think" about this issue implies he is
> guessing. Maybe if he actually tried it he'd conclude differently.
It was just a sound bite from an interview, and blocks aren't quite the same
Tim Daneliuk
<SNIP>
Writing for a machine which only has 256 bytes of RAM gives you a
> somewhat different outlook on programming :-)
The Microchip PIC 16F84A chip I have been using as *68* bytes of RAM -
well RISC register file, really, but its the same thing - 32 bytes of
EEPROM, and a whopping 1K of flash memory for storing the program itself.
And yes, it does give you a whole different perpective on programming...
Kow Kuroda
On Friday, September 6, 2002, at 11:25 AM, Rod Stephenson wrote:
snipped
> "Python is cool to look at small bits of, but I think the "outline"
> syntax breaks down with larger chunks of code. I'm with Aristotle on
> the structure of discourse--a story should have a beginning, and
> middle, and an end. So should blocks"
snipped
> Any comments?
Well, Python code may look awkward --- if not awk-like ---
if you don't know how to customize the tab width in your
editor of choice. For example, vi and emacs indent by 8
characters by default, which I suspect is too wide for Python.
Some code with deep nesting wouldn't look very nice with
this default.
Kow
Thorsten Kampe
>Rod Stephenson wrote:
>> Slashdot has a list of questions posed to Larry Wall (perl). When
>> asked his thoughts on other scripting languages, he makes the
>> following observation about python
>>
>> syntax breaks down with larger chunks of code. I'm with Aristotle on
>> the structure of discourse--a story should have a beginning, and
>> middle, and an end. So should blocks"
>
> def fun(args):
> #BEGIN
> if ceci or cela:
> #BEGIN
> do_this(with_that)
> [snip a lot of code]
> #END
> #END
>
> So what the problem with blocks ?
Nope. Bad, bad readability, sorry.
#||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*BEGINS*_!
def fun(args):
#||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*BEGINS*_!
if ceci or cela:
do_this(with_that)
[snip a lot of code]
#||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*ENDS*_!
#||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*ENDS*_!
Thorsten
jep...@unpythonic.net
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*BEGINS*_!
> def fun(args):
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*BEGINS*_!
> if ceci or cela:
> do_this(with_that)
> [snip a lot of code]
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*ENDS*_!
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*ENDS*_!
But my name's not Larry....! Why don't you write code that's readable by
*me*?
Jeff
Dennis Lee Bieber
08:56 pm:
> One could hardly expect Larry to say "I have seen Pearl 6 - and it is
> Python!" :)
>
"The serpent has tempted me"
--
> ============================================================== <
> wlf...@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulf...@dm.net | Bestiaria Support Staff <
> ============================================================== <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <
yka
>
> Well, Python code may look awkward --- if not awk-like ---
> if you don't know how to customize the tab width in your
> editor of choice. For example, vi and emacs indent by 8
> characters by default, which I suspect is too wide for Python.
> Some code with deep nesting wouldn't look very nice with
> this default.
>
> Kow
Well at vim :set ts=4 makes more fitting
--
Haloo?
yka
>> Of course, most of my current code has one big block, main(), and I just
>> cut-and-paste the rest.
>
> Your message brought me smiles, tears, and laughter--I haven't had that
> much fun since watching Heehaw.
>
yes I'm astonished by this revelation too
--
Haloo?
Sean 'Shaleh' Perry
actually emacs defaults to 4 space indenting and does not bother with tabs. I
find that code which plays games with how large a tab is always looks ugly
unless viewed in the same editor it was written in.
François Pinard
> [yka]
>> [Kow Kuroda]
>> > [...] For example, vi and emacs indent by 8 characters by default
>> [...] Well at vim :set ts=4 makes more fitting
> actually emacs defaults to 4 space indenting [...]
The Python mode writers for Emacs managed to automatically recognise the
indentation in use in a file, and continue editing that file with the same.
For new files, I get four spaces per level.
However, for Python files indented with TABs only, Emacs cannot successfully
guess if the author's intent was to expand those TAB with four or eight
spaces. By default, I vaguely remember it picks eight.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Gib Bogle
Maybe he is referring to an effect of default editor tab size.
Sean 'Shaleh' Perry
correct emacs says a tab is a tab and a tab means 8.
Peter Hansen
> Peter Hansen wrote:
>
>>mma...@hcsmail.com wrote:
>>>You must agree
>>>that Python can lead you to horizontal scrolling in your editor - the bane
>>>of user interface design.
>>
>>language, leads to more horizontal scrolling.
>
Apparently not, according to an email, which just said that
Python leads one to do this more than with other languages.
My point is that indentation (the way I've done it anyway) looks
*exactly* the same in C, Pascal, Python, or any other block-structured
language, so I still have no idea why Python would feel any different
in this respect for someone.
Clearly I'm missing some point, but I still don't know what it is.
C:
if (expression)
{
statements;
}
Python:
if expression:
statements
Pascal:
if (expression)
begin
statements;
end
(or whatever... haven't written any for three years).
The only thing that would make me exceed 80 columns with a language
like this is if I couldn't define subroutines and call them, to
keep the nesting from growing too large. Since all these languages
allow that, I have no idea what is special about Python that leads
to excessive indentation.
Oh well, whatever.
-Peter
Michael Schneider
Komoda from Activestate, They place a highlight around the
blocks.
Congrats to Activestate on such a great tool!!!!!!!!!!
Mike
PS. I am not affiliated with Active state, just a happy customer
Kow Kuroda
On Saturday, September 7, 2002, at 07:51 PM, Peter Hansen wrote:
> Gib Bogle wrote:
>> Peter Hansen wrote:
>>> mma...@hcsmail.com wrote:
>>>> You must agree
>>>> that Python can lead you to horizontal scrolling in your editor - the
>>>> bane
>>>> of user interface design.
>>>
>>> I definitely don't understand how Python, more or less than any other
>>> language, leads to more horizontal scrolling.
>> Maybe he is referring to an effect of default editor tab size.
>
> Apparently not, according to an email, which just said that
> Python leads one to do this more than with other languages.
>
> My point is that indentation (the way I've done it anyway) looks
> *exactly* the same in C, Pascal, Python, or any other block-structured
> language, so I still have no idea why Python would feel any different
> in this respect for someone.
Abstractly, you're completely right, but I guess people like Larry Wall, if
he really meant what his words meant anyway, are expecting certain *tokens*
, or rather *markers*, that make and/or help them *see* the abstract
structures called "blocks" in this case.
More interestingly, Python's lack of block-marking device (or Guido's
refusal to make use of it in Python) is another piece of evidence that
Python is more *abstract* than languages like C.
My best guess is that people like Larry are kind of detail-fetishists who
don't really like this kind of abstractness.
Kow
Steve Holden
[ ... ]
> Having read Wall's comments on Slashdot, I think he is really just mildly
> complaining about ridiculously long page-widths in his editor, not really
> slashing Python seriously. He's just giving some props to his own baby at
> that Python can lead you to horizontal scrolling in your editor - the bane
> of user interface design.
>
Further, lines can easily be broken and continued, which helps to make long
lines more manageable. lastly, of course, if your code has nine levels of
indentation it might well be time to refactor it for improved readbility.
> Yes, I am new here. Hi, everyone.
Hi, and welcome!
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming pydish.holdenweb.com/pwp/
Previous .sig file retired to www.homeforoldsigs.com
-----------------------------------------------------------------------
Robert Hanlin
> "Python is cool to look at small bits of, but I think the "outline"
> syntax breaks down with larger chunks of code.
Looks like Larry is simplifying or making a novice mistake. Knuth
wrote that whitespace indentation is good when languages can let you
write small blocks of code. Python does this for you. In fact,
Python is set up to gently prod you to write clear chunks of code.
Perl is not. It's a different philosophy. If he believes there's
more than one way to do things, he should realize that Python has its
own way.
Rob
laotseu
Ho my !
Isn't it a little bit too much ?-)
laotseu
laotseu
> On 6 Sep 2002, Rod Stephenson wrote:
>
>
>>"Python is cool to look at small bits of, but I think the "outline"
>>syntax breaks down with larger chunks of code. I'm with Aristotle on
>>the structure of discourse--a story should have a beginning, and
>>middle, and an end. So should blocks"
>>
>>a long heavily indented chunk of code, you could lose track of the
>>overall structure, but I don't write code this way.
>>
>>Any comments?
>
>
> The very idea of Larry Wall lecturing on code readability is hilarious.
>
> -Dave
>
>
C'mon, if he is able to read Perl code, he surely can say something
about readability !-)
laotseu
Brian Slesinsky
> Slashdot has a list of questions posed to Larry Wall (perl). When
> asked his thoughts on other scripting languages, he makes the
> following observation about python
>
> syntax breaks down with larger chunks of code. I'm with Aristotle on
> the structure of discourse--a story should have a beginning, and
> middle, and an end. So should blocks"
>
> I'm not quite sure what he's trying to get at here - I guess that for
> a long heavily indented chunk of code, you could lose track of the
> overall structure, but I don't write code this way.
>
> Any comments?
He's repeating the standard newbie complaint. However, I think the
fact that so many people have repeated this for so long is
significant. Long-term Python programmers tend to forget how weird it
is to some newcomers to end a function or class just by *stopping*.
It feels abrupt and rather fragile, particularly when you don't have a
firm grasp of the language. If newbies have complained for this long,
the complaint's not going away, and if we're serious about making
Python easy to pick up it might be good to listen.
I've long thought that Python would be improved by an optional "end"
statement. Example:
class Foo:
def bar(self, x):
# ...
# (imagine 20 more short methods definitions here)
end Foo
# or "end class Foo", or "end class", or, just "end"
Of course it's unnecessary and should be entirely optional. Putting
an "end" after every block would certainly be overly verbose and bad
style. But ending major blocks in a way that's syntax-checkable might
catch the occasional indentation error and/or make error messages
clearer. The main drawback is another reserved word, but it's one
that's reserved in several other programming languages.
I also think there would be a certain satisfaction in having a proper
ending, even for folks who are entirely comfortable with Python's
indentation. It's like "Q.E.D." at the end of a proof, or "The End"
at the end of children's book, or signing a message even though the
"From" header line makes it entirely redundant.
- Brian Slesinsky
Roy Smith
> Of course it's unnecessary and should be entirely optional.
One of the biggest impediments to learning Perl is that so much stuff is
optional. You learn a concept and think you've got it. Then, you look
at a different example of code that purports to do the same thing and it
looks entirely different.
Peter Hansen
> significant. Long-term Python programmers tend to forget how weird it
> is to some newcomers to end a function or class just by *stopping*.
I don't forget how weird it was to me as a newcomer. I also remember,
however, that about fifteen minutes after writing *real* code with it,
I realized it was not weird at all, but very sensible and readable.
> I also think there would be a certain satisfaction in having a proper
> ending, even for folks who are entirely comfortable with Python's
> indentation. It's like "Q.E.D." at the end of a proof, or "The End"
> at the end of children's book, or signing a message even though the
> "From" header line makes it entirely redundant.
There's some truth in that. I often end my files with a line that
reads "# EOF", which helps me not try to scroll down to find more
code, and when I print the file (rare) I can be sure I've found the
last page of code.
On the other hand, I always put "// EOF" in my C++ and Java code,
and /* EOF */ in my C code, so this bit has nothing to do with
block structures.
And I'd regard a strong desire to do something similar after
every single block as an unnatural compulsion. Therapy would be
a good next step for people with this problem. <0.87 wink>
-Peter
Roy Smith
> There's some truth in that. I often end my files with a line that
> reads "# EOF", which helps me not try to scroll down to find more
> code
I would think your editor beeping (or whatever your particular editor
does when you try to scroll past the end of file) would do the trick.
But, it could be worse. We had a guy here who insisted on putting stuff
like this at the ends of his files:
#####################################
# #
# ############################### #
# # End of <filename> # #
# ############################### #
# #
#####################################
bru...@tbye.com
> He's repeating the standard newbie complaint. However, I think the
> fact that so many people have repeated this for so long is
> significant. Long-term Python programmers tend to forget how weird it
> is to some newcomers to end a function or class just by *stopping*.
> It feels abrupt and rather fragile, particularly when you don't have a
> firm grasp of the language. If newbies have complained for this long,
> the complaint's not going away, and if we're serious about making
> Python easy to pick up it might be good to listen.
Yes, the fact that so many newbies complain about it is very significant.
Perhaps we need to do a better job of presenting the concept. For example,
instead of tossing it out there and then defending against complaints
perhaps it would be better to take the offensive: first make a case for
why the "normal" way to delimit blocks has its drawbacks, and then present
the Python way as a solution to a problem.
But just because people consistently complain about something does not
mean the answer is to bow to their wishes. From an arrogant point of view,
they're newbies, so what do they know? ;-) Seriously though, I enjoy
Python because it _is_ different - and I usually derive benefit from the
ways in which it is different (i.e. - it's not different for arbitrary or
random reasons). It's significant that lots of newbies complain about "no
curly braces", but it's as least as significant that once people use it
for awhile they tend to end up liking it.
> Of course it's unnecessary and should be entirely optional. Putting
> an "end" after every block would certainly be overly verbose and bad
> style. But ending major blocks in a way that's syntax-checkable might
> catch the occasional indentation error and/or make error messages
Well, as you know you can always do an "# end" comment which really gives
much of the same benefit. At the bottom of my Emacs window it tells me
which block I'm closing (e.g. "Closes block: ...try:"), other editors
probably do the same. Also, it seems like whenever it's not readily
apparent which block I'm in, then the _real_ problem is sloppy code on my
part.
-Dave
sism...@hebmex.com
I've found that block-delimiting-chars become like a
drug to the brain; you don't really think about them
until they're not available anymore, then the pain
(well, kinda) starts, and there's whines ("whyyyy
can't I use such-and-such delimiters for my python
programs pleeze???"), and all that.
Once you wean your brain off block-delimiter-chars,
you begin to code more freely, much happier. Really!
Another drug which is taken in great amounts by
C++ and Java programmers are "private:" and
"protected:" and "friends:" stuff, really hideous
and much more sneaky, because they first convince
you that you *need* them in order to make good
programs, and it takes a bit more effort to wean
young minds off them.
;-)
-gus
--
Advertencia:
La informacion contenida en este mensaje es confidencial y restringida y
esta destinada unicamente para el uso de la persona arriba indicada, Esta
comunicacion representa la opinion personal del remitente y no refleja
necesariamente la opinion de la Compañia. Se le notifica que esta
estrictamente prohibida cualquier difusion, distribucion o copia de este
mensaje. Si ha recibido esta comunicacion o copia de este mensaje por error,
o si hay problemas en la transmision, favor de comunicarse con el remitente.
Todo el correo electrónico enviado para o desde esta dirección será
procesado por el sistema de correo corporativo de HEB. Tal correo
electrónico esta sujeto a ser almacenado y puede ser revisado por alguien
ajeno al recipiente autorizado con el propósito de monitorear que se cumplan
las normas de seguridad de la empresa.
Tim Lesher
> I take Larry Wall as a nice and clever guy. Perl does not marry so well with
> evolution, and this is probably the doom of all languages which do not enough
> foresee evolution, and overly praise backward compatibility.
Because the language has grown by accretion, many Perl advocates tend
to draw parallels between the evolution of a language over its
lifetime and the evolution of species. I think that this leads to
some invalid assumptions.
Evolution of species works because of natural selection. Many random
mutations are "tried", similar to the individual displacements in
Brownian motion. Those that prove advantageous for a given set of
circumstances persist. That's all there is to it--no worry about
whether this mutation is a good idea overall, or whether it makes the
organism compatible with previous generations, or whether this
mutation makes the DNA sequence easier to read or harder to fit on an
80-column screen. :-)
The moment you talk about designing for language evolution, or
maintaining backwards compatibility, or pretty much any kind of
intelligent process governing the change over time, you have to drop
the comparison with natural evolution, as enticing as the comparison
might be.
Keeping a bad analogy just muddles conversation.
--
Tim Lesher
t...@lesher.ws
Brad Clements
I declare, Larry is some kind of anti-Guido!
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Fazal Majid
>> Larry Wall Wrote:
>>
>> "Python is cool to look at small bits of, but I think the "outline"
>> syntax breaks down with larger chunks of code. I'm with Aristotle on
>> the structure of discourse--a story should have a beginning, and
>> middle, and an end. So should blocks"
> response.
That's funny, I hadn't read Larry's article as I am not all that
interested in Perl (dropped it for Python in 94, haven't looked back
since), but I set out an Aristotle comparison at about the same time.
One of the good things about Python is that it is non-aristotelian:
http://www.majid.info/radio/2002/09/07.html#a30
-- Fazal Majid
Paul Boddie
>
["I need braces" complainants]
> But just because people consistently complain about something does not
> mean the answer is to bow to their wishes.
Especially if the adamant complainants in question are the usual
screaming 14 year old Slashdot "contributors" who think they know it
all after "hanging out" on IRC for a bit.
Paul
Jack D. Hammer
One good argument for having block delimiters is for embedded situations like
ASP. One can conditionally put code into a block as such (ASP is rusty):
<%
if (some_condition) {
%>
<tr>
<td>some data</td>
<td>some more data</td>
</tr>
<%
} // closing curly
%>
I would think that for embedding python, having block delimiters would be
beneficial.
Carl Banks
>
> I would argue that the "older" block-structured languages were considered
> a breakaway from the column-based languages - RPG2 and Fortran, for
> instance. Although I grant the Python structure and the column-based
> structures are not completely analogous, they BOTH burden the programmer
> with arbitrary rules to govern the physical layout of the code.
Python's forced indentation certainly doesn't burden me at all. I
don't know about you, but I indent whether I have a block delimiters
or not. Python doesn't force me to do anything I wouldn't do anyways.
What *is* burdensome is having to use block delimiters, AND to make
sure they are properly sychronized to the indentation.
> Although
> this layout may be considered more elegant from a readability standpoint,
> it's the enforcement of the layout that is irritating to the more
> Libertarian of us. It's a mindset difference similar to that between
> Pascal and C++.
Well, if you're complaining about your lack of freedom, then you're
complaining about your freedom to write unreadable and misleading
code. It's a freedom I don't care for (usually).
> Having read Wall's comments on Slashdot, I think he is really just mildly
> complaining about ridiculously long page-widths in his editor, not really
> slashing Python seriously. He's just giving some props to his own baby at
> the expense of another. (He had to say something, right?) You must agree
> that Python can lead you to horizontal scrolling in your editor - the bane
> of user interface design.
No, not any more than C would. Do you not indent in C? If your C
code runs against the margin, is your solution to simply stop
indenting, and run all the blocks together? (If it is, then you have
worse problems than being forced to indent.)
And, as a matter of fact, I never exceed 79 columns in any of my
Python code. And I use eight-space tab stops. And my editor doesn't
have horizontal scrolling; it wraps.
--
CARL BANKS
http://www.aerojockey.com
Carl Banks
> I've long thought that Python would be improved by an optional "end"
> statement.
Python already has that. It's called a comment.
Steve Holden
>
> One good argument for having block delimiters is for embedded situations
like
> ASP. One can conditionally put code into a block as such (ASP is rusty):
>
:-)
> <%
> if (some_condition) {
> %>
> <tr>
> <td>some data</td>
> <td>some more data</td>
> </tr>
> <%
> } // closing curly
I want to thank you for adding this valuable comment to your code. Without
it, I might have thought you were trying to close the parenthesis you
unopened above...
> %>
>
> I would think that for embedding python, having block delimiters would be
> beneficial.
>
Beneficial in the same way as giving $_ and $< and similar constructs
"meaning"? I use the inverted commas deliberately. They no longer have much
meaning for me. However, I do not deny the pragmatic value of the language,
not the value of the many pieces of software written in it.
If something works for us, we are entitled to use it. I just lost contact
with Perl when I looked at its object-oriented features. Of course, that may
not be Perl's fault. None of us is getting any younger.
[...]
I can't see "{%>" and "<%}" making it into the "Top 20 Delimiters" list,
perhaps I underestimate the pervasiveness of keyboard skills, of which I
have relatively few.
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Roy Marteen
Tim Daneliuk <tun...@tundraware.com> wrote:
> Roy Smith wrote:
> <SNIP>
>
> Writing for a machine which only has 256 bytes of RAM gives you a
> > somewhat different outlook on programming :-)
>
> The Microchip PIC 16F84A chip I have been using as *68* bytes of RAM -
> well RISC register file, really, but its the same thing - 32 bytes of
> EEPROM, and a whopping 1K of flash memory for storing the program
> itself. And yes, it does give you a whole different perpective on
> programming...
Well... it reminds me when I was young, and we had to program using
ABACUS. It was really somewhat different outlook on programming.
Ken Seehof
>* laotseu
> >Rod Stephenson wrote:
> >> asked his thoughts on other scripting languages, he makes the
> >> following observation about python
> >>
> >> syntax breaks down with larger chunks of code. I'm with Aristotle on
> >> the structure of discourse--a story should have a beginning, and
> >> middle, and an end. So should blocks"
> >
> > def fun(args):
> > #BEGIN
> > if ceci or cela:
> > #BEGIN
> > do_this(with_that)
> > [snip a lot of code]
> > #END
> > #END
> >
> > So what the problem with blocks ?
>
>Nope. Bad, bad readability, sorry.
>
>#||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*BEGINS*_!
>def fun(args):
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*BEGINS*_!
> if ceci or cela:
> do_this(with_that)
> [snip a lot of code]
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*ENDS*_!
>#||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*ENDS*_!
>
>
>Thorsten
Definitely not. Too wide by far. You need to reduce the indent to one space.
#||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*BEGINS*_!
def fun(args):
#||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*BEGINS*_!
if ceci or cela:
do_this(with_that)
[snip a lot of code]
#||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*ENDS*_!
#||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*ENDS*_!
- Ken
Peter Hansen
> Definitely not. Too wide by far. You need to reduce the indent to one
> space.
>
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*BEGINS*_!
> def fun(args):
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*BEGINS*_!
> if ceci or cela:
> do_this(with_that)
> [snip a lot of code]
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE IF-CLAUSE _*ENDS*_!
> #||<--- LOOK HERE, LARRY, THIS IS WHERE THE FUNCTION _*ENDS*_!
Oh, I didn't recognize this until now. It's COBOL! Everything
with a leading # is executable code, right? ;-)
-Peter
Magnus Lyckå
> ABACUS. It was really somewhat different outlook on programming.
That's nothing. We had to program in a cardboard box
in the middle of the motorway, our manager sliced us
to pieces every morning, and we had to eat rocks!
Phew, these kids these day... When you tell them how
we had it, they hardly believe us...
Magnus Lyckå
> Rod Stephenson wrote:
>
>> Slashdot has a list of questions posed to Larry Wall (perl). When
>> asked his thoughts on other scripting languages, he makes the
>> following observation about python
>>
>> "Python is cool to look at small bits of, but I think the "outline"
>> syntax breaks down with larger chunks of code. I'm with Aristotle on
>> the structure of discourse--a story should have a beginning, and
>> middle, and an end. So should blocks"
Don Knuth said:
"We will perhaps eventually be writing only small modules
which are identified by name as they are used to build
larger ones, so that devices like indentation, rather than
delimiters, might become feasible for expressing local
structure in the source language."
See http://www.thinkware.se/cgi-bin/thinki.cgi/PythonQuotes
Stephen Edwards said:
Python: Perl designed by a sane man.
http://www.cs.columbia.edu/~sedwards/classes/2002/w4115/scripting.pdf
Of course there is an end for every Python block. The
Zen thing to consider is the old: "What is the sound of
one hand clapping?" Consider that, and return when you
are enlightened. ;)
My personal experience from many years of coding C++ etc
with curlies and Python without, is that I tend to get
lost a lot more in my C++ code than in my Python code.
Not to mention the code of others... I've certainly had
a number of debugging sessions where I had to help some
mediocre C++ coder who couldn't match his own braces...
The problem is usually that the blocks get to big... The
fact that you can get away with incorrect indentation in
the brace-languages makes it worse.
Most modern editors have tools like indentation guides and
folding that can make it easier to see block structures.
Was it one of Beethoven's symphonies that ended so abruptly
that the audience didn't understand when to applaud? It was
considered a big failure at it's time, and it's considered
one of the best works of a genious today...
>> I'm not quite sure what he's trying to get at here - I guess that for
>> a long heavily indented chunk of code, you could lose track of the
>> overall structure, but I don't write code this way.
>>
>> Any comments?
>
>
> def fun(args):
> #BEGIN
> if ceci or cela:
> #BEGIN
> do_this(with_that)
> [snip a lot of code]
> #END
> #END
I would recommend against such a coding style.
First of all, if it's difficult to understand the code
(even after the first 10 minutes of Python exposure)
you probably have a bad structure in your code. Too
big blocks, or too much nesting in the structure. The
solution there is refactoring, not comments.
Secondly, you are adding something redundant and foreign
to your code. Getting used to how Python actaully looks
is a better idea than trying to make it look like Pascal.
Thirdly you are creating a maintenace problaem. The main
problem with all comments (except that they often don't
get written) is that they tend to get out of sync with
the code. No syntax checks or test script will detect if
your #END markers are incorrect. If the code is bad enough
to warrant #END markers, it will be easy to write them
incorrectly, and even easier to make mistakes when you
change your code, adding or removing a loop or an if-
statement in the middle of the structure.
If you still feel that you want an explicit end marker to
your blocks, do it like this.
* Forget about #BEGIN, if you are unable to see where the
Python blocks begin, you might as well give up.
* Please forget about the ugly capitals.
* Add some meaningful information to the end marker so that
you see which block you are ending.
* Make sure that you have a program that will check / generate
the end markers.
It could look like this:
def fun(args):
if ceci or cela:
do_this(with_that)
[snip a lot of code]
#end: if ceci or cela
#end: fun(args)
It shouldn't be so difficult to write a python script that
will remove all lines beginning with #end: and then regenerate
them correctly for all blocks. (Not that I find it worth
while...)
These kinds of scripts are good to run as pre-checkin triggers
if your develpment environment supports that kind of routines.
Matt Gerrans
to Guido on that).
One of the niftiest things about Python is you never have to argue about
whether you should put your curlies in the wrong place, like this:
void foo() {
//...
}
...or whether you should place them correctly, like this:
void foo()
{
//...
}
It saves the world from a lot of unnecessary creation and release of hot air
(so Python has probably done more to help reduce the greenhouse effect than
any other software technology!).
;-)
Chris Gonnerman
From: "Matt Gerrans" <mger...@mindspring.com>
> One of the niftiest things about Python is you never have to
> argue about whether you should put your curlies in the wrong
> place, like this:
>
> void foo() {
> //...
> }
>
> ...or whether you should place them correctly, like this:
>
> void foo()
> {
> //...
> }
Them's fightin' words, son... :-)
> It saves the world from a lot of unnecessary creation and
> release of hot air (so Python has probably done more to help
> reduce the greenhouse effect than any other software
> technology!).
I just like that I don't have to type the #!$&@!! things
anymore.
No smiley this time... I really hate typing curly after curly.
It makes me wonder that anyone *likes* the freakin' things so
much that they named a LANGUAGE after them.
Chris Gonnerman -- chris.g...@newcenturycomputers.net
http://newcenturycomputers.net
Christopher Barber
> No smiley this time... I really hate typing curly after curly.
> It makes me wonder that anyone *likes* the freakin' things so
> much that they named a LANGUAGE after them.
The Curl language was indeed named after curly braces, but not because we like
them so much but because the nature of the language required some sort of
bracketing delimiter punctation and the curly brace seemed a good choice for
this. One of the points of the language is to make it easy to do powerful
text markup and otherwise mix code and text. To support this, you really need
some way to distinguish code from text. For instance:
{paragraph Hello {bold Bold} World!}
Although it might be annoying to have to type the curly braces, I really don't
know what the alternative would be. Parens and square brackets are used much
more frequently in text than curly braces and would have to be escaped more
frequently, and SGML syntax is much worse. I don't think there is a way to do
this kind of thing using Pythonic syntax.
- Christopher
Cliff Wells
> One of the niftiest things about Python is you never have to argue about
> whether you should put your curlies in the wrong place, like this:
>
> void foo() {
> //...
> }
>
> ...or whether you should place them correctly, like this:
>
> void foo()
> {
> //...
> }
>
> It saves the world from a lot of unnecessary creation and release of hot air
> (so Python has probably done more to help reduce the greenhouse effect than
> any other software technology!).
Now all that's left to decide is whether to use tabs or spaces for
indentation...
;)
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Skip Montanaro
Christopher> {paragraph Hello {bold Bold} World!}
Christopher> Although it might be annoying to have to type the curly
Christopher> braces, I really don't know what the alternative would
Christopher> be.... I don't think there is a way to do this kind of
Christopher> thing using Pythonic syntax.
(Danger Will Robinson! I thought curl was a URL fetcher. I never heard of
curl the language. The above fragment is the only curl I've ever seen.
That said...)
Why wouldn't
paragraph:
Hello
bold:
Bold
World!
work? :-)
--
Skip Montanaro - sk...@pobox.com
The need for gutters to be cleaned is directly proportional to how hard it
happens to be raining at the moment.
Courageous
>Well, Python code may look awkward --- if not awk-like ---
>if you don't know how to customize the tab width in your
>editor of choice.
Well, there's your problem already. One should use spaces
and not tabs in Python code. Otherwise, any python file where
tabs and spaces are mixed is also a choice of which indentation
level other viewers of the code MUST use in their editors. That's
heinous.
C//
James J. Besemer
Chris Gonnerman wrote:
>I just like that I don't have to type the #!$&@!! things
>anymore.
>
>No smiley this time... I really hate typing curly after curly.
>It makes me wonder that anyone *likes* the freakin' things so
>much that they named a LANGUAGE after them.
>
They are a hell of an improvement over "begin" and "end".
But I agree, leaving them out altogether is even better.
--jb
Kow Kuroda
Well, that's not my job; it's the job of tabnanny.py.
Kow
James J. Besemer
Chris Gonnerman wrote:
>----- Original Message -----
>From: "James J. Besemer" <j...@cascade-sys.com>
>
>
>
>>They are a hell of an improvement over "begin" and "end".
>>
>>
>
>I disagree slightly... I don't have to shift for the literal
>"begin" and "end" statements, and I don't have to reach either.
>I'm left-handed; my right pinky is probably my weakest finger.
>So, while I don't really *like* "begin" and "end" as in
>Pascal, I rarely curse while typing them.
>
Ah. I took a typing class in high school and in retrospect it was one
of the most useful classes from that period in my life.
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
http://cascade-sys.com
Chris Gonnerman
From: "James J. Besemer" <j...@cascade-sys.com>
> Chris Gonnerman wrote:
> >
> >No smiley this time... I really hate typing curly after
> >curly. It makes me wonder that anyone *likes* the freakin'
> >things so much that they named a LANGUAGE after them.
>
> They are a hell of an improvement over "begin" and "end".
I disagree slightly... I don't have to shift for the literal
"begin" and "end" statements, and I don't have to reach either.
I'm left-handed; my right pinky is probably my weakest finger.
So, while I don't really *like* "begin" and "end" as in
Pascal, I rarely curse while typing them.
At least the : is right under that finger.
> But I agree, leaving them out altogether is even better.
Absolutely.
Alan Daniels
> I think "the pound-end operator" is the technical term (I'll have to defer
> to Guido on that).
"Pound-end operator"? Now *there's* an image...
Christopher Barber
> Christopher> For instance:
>
> Christopher> {paragraph Hello {bold Bold} World!}
>
> curl the language. The above fragment is the only curl I've ever seen.
> That said...)
There is a thing called cURL, which is "a command line tool for transferring
files with URL syntax...", see http://www.haxx.se/.
We were talking about the Curl language, which is an advanced OO language
primarly (but not exclusively) focused on client-side web use. See
http://www.curl.com/
- Christopher
Greg Ewing
> One should use spaces
> and not tabs in Python code. Otherwise, any python file where
> tabs and spaces are mixed is also a choice of which indentation
> level other viewers of the code MUST use in their editors.
If you use spaces only, you're also choosing how other
people will see it in their editors (unless they're
willing to use a tool to re-indent it).
Using *tabs* only is the only way to get truly
preference-independent indentation.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Courageous
>Using *tabs* only is the only way to get truly
>preference-independent indentation.
But makes impossible certain constructs that involving lining
indentation level up with specific items of text in surrounding
lines, which actually matters. This is one of the reasons people
often use mixed tabs and spaces. Here is an example:
void MyFunction ( int a,
char c,
float f );
void MyFunction ( int a,
char c,
float f );
void MyFunction ( int a,
char c,
float f );
Furthermore, when you use only spaces, you can guarntee that
all those reading will see it formatted as close to correctly
as is possible.
C//
Alex Martelli
> Courageous wrote:
>
>> One should use spaces
>> and not tabs in Python code. Otherwise, any python file where
>> tabs and spaces are mixed is also a choice of which indentation
>> level other viewers of the code MUST use in their editors.
>
> If you use spaces only, you're also choosing how other
> people will see it in their editors (unless they're
> willing to use a tool to re-indent it).
>
> Using *tabs* only is the only way to get truly
> preference-independent indentation.
...unless other people use tools that do NOT let them change the
ways tabs are displayed, and that way is intolerably incompatible
with your use of tabs.
Both Outlook Express and KDE's KNode (in KDE 2.2 at least --
that's what I'm using today) are good examples of such tools
that are in everyday use by many people. The amount of space
displayed for a leading tab is ZERO. Just imagine how neat
this makes reading Python code posted to this newsgroup, when
the poster uses tabs there (for example because they use tabs
normally in their on-disk sources, and copy and paste is the
best way to post some snippet).
That's just one example (well, two, since KNode and OE are
completely separate programs) -- anybody who prints your
source code is similarly at the mercy of their printer's
drivers (many of which don't allow tabs to be changed), etc.
Unless you KNOW all the tools that will ever be used to look
at your source code -- which basically means, you will never
distribute your source code outside of a small group under
your strict control, never post any snippet thereof to c.l.py
to ask a question nor to aswer it, etc -- I consider using
tabs to be anti-social and a massive annoyance. Follow the
style guide and use 4 spaces per indentation level, if you
like to think of yourself as a 'good citizen', rather than a
missionary who wants to force everybody to read news with
Emacs (or whatever other highly-flexible tool of choice).
Alex
Robin Becker
ddr...@something.invalid> writes
......
>If you use spaces only, you're also choosing how other
>people will see it in their editors (unless they're
>willing to use a tool to re-indent it).
>
>Using *tabs* only is the only way to get truly
>preference-independent indentation.
>
--
Robin Becker
James J. Besemer
Robin Becker wrote:
Ditto.
Greg Ewing
> But makes impossible certain constructs that involving lining
> indentation level up with specific items of text in surrounding
> lines
Actually, it doesn't. You use tabs to get up to the
current statement indentation level, and then spaces
after that for the purpose of lining-up.
Greg Ewing
>
> Greg Ewing wrote
>
>>Using *tabs* only is the only way to get truly
>>preference-independent indentation.
>
> ...unless other people use tools that do NOT let them change the
> ways tabs are displayed, and that way is intolerably incompatible
> with your use of tabs.
I agree there are good reasons to prefer spaces-only
for code that will be transmitted or displayed by
dumb software.
I was only pointing out that, whatever arguments there
may be in favour of spaces-only, "it doesn't force the
reader to view it the way you do" is not one of them!
Alex Martelli
...
>>>Using *tabs* only is the only way to get truly
>>>preference-independent indentation.
>>
>> ...unless other people use tools that do NOT let them change the
>> ways tabs are displayed, and that way is intolerably incompatible
>> with your use of tabs.
>
> I agree there are good reasons to prefer spaces-only
> for code that will be transmitted or displayed by
> dumb software.
To put it differently: use tabs only if you ARE willing to
bet a very substantial amount that the source file in question
will NEVER be transmitted, displayed, nor otherwise processed
in any way, shape, or form, by software you consider "dumb"
(take it up with KDE KNode's maintainers whether their news
reader is "dumb"... I like it, though it doesn't show tabs:-).
> I was only pointing out that, whatever arguments there
> may be in favour of spaces-only, "it doesn't force the
> reader to view it the way you do" is not one of them!
I agree with you that this is a fact. Only very smart
software would be able to display varying amount of
leading spaces in programmable ways, and software that
smart would no doubt be able to do anything with tabs too.
Alex
Jacob Hallen
Magnus Lyckå <mag...@thinkware.se> wrote:
...
>My personal experience from many years of coding C++ etc
>with curlies and Python without, is that I tend to get
>lost a lot more in my C++ code than in my Python code.
>Not to mention the code of others... I've certainly had
>a number of debugging sessions where I had to help some
>mediocre C++ coder who couldn't match his own braces...
>The problem is usually that the blocks get to big... The
>fact that you can get away with incorrect indentation in
>the brace-languages makes it worse.
>
>Most modern editors have tools like indentation guides and
>folding that can make it easier to see block structures.
>
>Was it one of Beethoven's symphonies that ended so abruptly
>that the audience didn't understand when to applaud? It was
>considered a big failure at it's time, and it's considered
>one of the best works of a genious today...
I think there is a good explanation for why code with explicit delimiters
is harder to read and follow than normal Python code.
There is an absolutely outstanding series of books by Edward Tufte
about how to create charts, tables and other information presentation
graphics. In his books he introduces a measurable unit called "Chart junk".
This is the percentage of the ink used in the chart that does not convey
information. Ink does not convey information if it can be erased, or
if by changing the position of other ink in the diagram, you can leave the
ink out.
Tufte then goes on to practically show that the unit is a relevant one to
ease of understanding. The books are beautiful and should be required reading
for anyone who ever designs a user interface.
In any case, I think that there exists something we can call source-junk, which
is the programming language equivalent of chart-junk. It is all the "ink"
in the source code that does not add to your understanding of what the code
does. Block starts and ends can be represented by white areas. Redundant
parenthesis can be thrown away. Declarations are seldom needed by the
programmer in order to understand the program.
The most important parts of your program, for understanding how it works
is the names of your objects (variables, classes, methods, functions, modules).
Second to that is the operations you do on your objects - how you combine
them. That's about it. Please note that I didn't say anything about block
delimiters or parentheses in this. I think they were put into programming
languages to make it easy to write fast compilers. I also think that
one of the factors making C so popular was that the BEGIN/END of Pascal and
ADA were even more intrusive than {}, so people considered C to be much
more readable than the competitors.
The lack of source junk is certainly the biggest thing that attracts me to
Python. The rest of the benefits are fairly pedestrian. This one is the
really big win.
Jacob Hallén
A
--
Jacob Hallen
Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
>Courageous wrote:
>
>> One should use spaces
>> and not tabs in Python code. Otherwise, any python file where
>> tabs and spaces are mixed is also a choice of which indentation
>> level other viewers of the code MUST use in their editors.
>
>
>If you use spaces only, you're also choosing how other
>people will see it in their editors (unless they're
>willing to use a tool to re-indent it).
>
>Using *tabs* only is the only way to get truly
>preference-independent indentation.
Exactly the point! My code is my work of art. Why should anybody be allowed
to change it? We don't allow people to go painting moustaches on the
Mona-Lisa, do we?
Jacob Hallén
--
Alan Daniels
[snippage...]
> You use tabs to get up to the current statement indentation level,
> and then spaces after that for the purpose of lining-up.
Unfortunately, that fails when one person writes their code with tabs
set to 8, and another person reads the code with tabs set to 4. Code
that was hand-aligned with a mix of tabs and spaces doesn't align
anymore.
Sometimes I wonder if Guido would have saved a lot of debate by declaring,
long ago, that Python code would never allow tabs in it, period. Which may
be a bit extreme, I'll admit. :-)
James J. Besemer
Alan Daniels wrote:
>Sometimes I wonder if Guido would have saved a lot of debate by declaring,
>long ago, that Python code would never allow tabs in it, period. Which may
>be a bit extreme, I'll admit. :-)
>
Ironically, Guido originally ruled (in the style guide, IIRC) that thou
shalt use tabs and tabs are 8 spaces, "as god intentended them to be."
Unfortunately, he later changed position to the present, unsatisfying,
compromise position.
sism...@hebmex.com
> Alan Daniels wrote:
>
> >Sometimes I wonder if Guido would have saved a lot of debate
> > by declaring, long ago, that Python code would never allow
> > tabs in it, period. Which may be a bit extreme, I'll admit. :-)
Actually, it's the only universally-workable solution
to this "problem".
> Ironically, Guido originally ruled (in the style guide, IIRC)
> that thou shalt use tabs and tabs are 8 spaces, "as god
> intentended them to be."
Yeesh! Why in God's name would he say such a dumb thing?
I mean, even ancient mechanical typewriters have movable
tab settings. Rigid, 8-char tabs is just so... neolithical.
>
> Unfortunately, he later changed position to the present,
> unsatisfying, compromise position.
And so, we all lose.
> --
> James J. Besemer 503-280-0838 voice
> 2727 NE Skidmore St. 503-280-0375 fax
> Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
> http://cascade-sys.com
>
-gus
Advertencia:
La informacion contenida en este mensaje es confidencial y restringida y
esta destinada unicamente para el uso de la persona arriba indicada, Esta
comunicacion representa la opinion personal del remitente y no refleja
necesariamente la opinion de la Compañia. Se le notifica que esta
estrictamente prohibida cualquier difusion, distribucion o copia de este
mensaje. Si ha recibido esta comunicacion o copia de este mensaje por error,
o si hay problemas en la transmision, favor de comunicarse con el remitente.
Todo el correo electrónico enviado para o desde esta dirección será
procesado por el sistema de correo corporativo de HEB. Tal correo
electrónico esta sujeto a ser almacenado y puede ser revisado por alguien
ajeno al recipiente autorizado con el propósito de monitorear que se cumplan
las normas de seguridad de la empresa.
Carl Banks
> Greg Ewing wrote:
>>
>> I agree there are good reasons to prefer spaces-only
>> for code that will be transmitted or displayed by
>> dumb software.
>
> To put it differently: use tabs only if you ARE willing to
> bet a very substantial amount that the source file in question
> will NEVER be transmitted, displayed, nor otherwise processed
> in any way, shape, or form, by software you consider "dumb"
> (take it up with KDE KNode's maintainers whether their news
> reader is "dumb"... I like it, though it doesn't show tabs:-).
Dumb? I would call it broken.
--
CARL BANKS
http://www.aerojockey.com
Dennis Lee Bieber
2002 07:03 am:
>
> Exactly the point! My code is my work of art. Why should anybody be
> allowed to change it? We don't allow people to go painting moustaches
> on the Mona-Lisa, do we?
>
Ah, but if you can persuade the Louvre to /sell/ you the Mona Lisa,
you are then perfectly free to do what you want with it.
--
> ============================================================== <
> wlf...@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulf...@dm.net | Bestiaria Support Staff <
> ============================================================== <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <
James J. Besemer
sism...@hebmex.com wrote:
>>Ironically, Guido originally ruled (in the style guide, IIRC)
>>that thou shalt use tabs and tabs are 8 spaces, "as god
>>intentended them to be."
>>
>>
>
>Yeesh! Why in God's name would he say such a dumb thing?
>I mean, even ancient mechanical typewriters have movable
>tab settings. Rigid, 8-char tabs is just so... neolithical.
>
Once upon a time, a large class of computers, and their attendant
peripherals, OSs and utility programs universally implemented tabs
hard-wired at 8 stops. In some circles this heritage extended back 30
or 40 years. Unix originally followed this convention, as did IIRC all
Dec computers and that of most other "minicomputer" vendors. Ed and the
original VI editors only had fixed tab stops consistent with terminal
drivers and all the unit record equipment at the time. IIRC, even Emacs
originally only had tab stops at every 8 columns. The original PC also
followed this convention, though not all applications did. I don't know
for sure but I bet $1 that Linux tty drivers today also are hard wired
at 8 char tab stops.
Now, if you've ever worked in an environment where EVERYBODY uses the
same tab stops then you'd probably agree that tabs are vastly superior
to spaces. I don't think there's any question. I presume it's from
this perspective that the right honorable BDFL issued his original
proclamation, which is actually quite reasonable, especially from my old
fart's perspective.
In fact, problems only arise when alternative, competing tab stop
conventions try to coexist, which I agree is not generally solvable.
Closest solution I've seen is some sites where everybody uses Emacs and
employ coding conventions so that on startup Emacs can read a specially
coded comment and automatically switch to the proper indent for that
file. This can sort of work but your printer and other rendering
utilities also all have to recognize the codes. Spaces are a more
practical solution.
I myself still prefer tabs as I find "indenting" and "out denting"
sections of code to be a common operation (in Python and in other
languages). Inserting or removing an "if" or changing inline code to a
function makes indenting and out denting a common operation. In the
environments I use, this works well with tabs and not so well or at all
with spaces. By default, I still prefer 8 char stops but I also find I
can live just fine with 4. But I can't stand it without tabs. I'll
convert to spaces if I need to when delivering code but I can't work on
it that way.
Anyway, what's wrong with the "neolithical" 8 char stops? For several
decades, all the C code ever written was tab indented at 8 columns,
along with most of the text and other programming languages on Unix.
Some people complained that in practice 8 char tabs forced them to
indent too much and their programs got squashed off the right edge of
the page. I have little sympathy for that argument, as I feel if your
program is properly modularized then then this should not be much of a
problem as individual modules should not have to be indented all that
much. Also, I suspect part of the pressure came from Pascal users,
where some coding conventions require indenting two levels, once for the
begin/end pairs and again a second time for the code contained between
them. What a crock.
For what it's worth, Python's C implementation today appears to be tab
indented to 8 columns, at least all the parts I've looked at. The main
interpreter loop is a good example of a "complex" piece of code. The
innermost loop includes a single switch statement that's over 1400 lines
long! Surrounding logic require that the switch statement and case
labels start 2 tab stops in and thus the body of each case starts 3
stops in or in column 24. Yikes, that's like 1/3 of the total. And yet
none of the case bodies extend past column 73 or so. Turns out that in
practice most code lines are pretty short. The ones that aren't
typically are function calls with multiple arguments, and these may
easily be split onto multiple lines (often thereby increasing
readability). Since Guido personally wrote the bulk of this system as a
labor of love, I surmise that he's still pretty sentimental about the
old ways.
Regards
--jb
Greg Ewing
> Please note that I didn't say anything about block
> delimiters or parentheses in this. I think they were put into programming
> languages to make it easy to write fast compilers.
I'm not sure you should lump parentheses in with
block delimiters in that statement. They've been
in use by mathematicians for centuries before
compilers were invented, and, used in moderation,
I don't think they have any adverse effect on
readability.
Greg Ewing
> (take it up with KDE KNode's maintainers whether their news
> reader is "dumb"... I like it, though it doesn't show tabs:-).
Apologies -- I didn't mean to denigrate any piece of
software with the term. I was just using it as
shorthand for (in this context) "not having any
features provided for customising the display of
tabs".
Courageous
>Once upon a time, a large class of computers, and their attendant
>peripherals, OSs and utility programs universally implemented tabs
>hard-wired at 8 stops.
Indeed; such is this issue that I leave hard tabstops as 8 in my
editor, and set soft tab stops set to 4. What this means, in vim,
is that when tab is struck it "takes the cursor to the next logical
tab stop by inserting enough spaces to get it there." No real tab
exists. In fact, I have to strike ctrl-V[TAB] in order to get a
real one. I also use another setting that displays ascii-187 (»)
wherever a tab is. This is nice for editing those nasty makefiles
(that _REQUIRE_ tabs).
The relevant parts of my .vimrc can roughly be summarized as follows:
set tabstop=8
set softtabstop=4
set shiftwidth=4
set et
"ascii-187==»
set lcs=tab:»\
If you want to enter ascii-187 manually in vim (and can't cut out
of this message) type ctrl-V187
C//
Courageous
wrote:
>Jacob Hallen wrote:
>
>> Please note that I didn't say anything about block
>> delimiters or parentheses in this. I think they were put into programming
>> languages to make it easy to write fast compilers.
Even Python uses block delimeters internally in order to properly
parse the language. They are actually inserted by the _LEXER_, which
performs an elaborate indentation-aware transformation of the code,
inserting INDENT and DEDENT tokens into the stream where they are needed.
Hence, this expression...
for i in mylist:
expr
...becomes...
FOR IDENTIFIER IN IDENTIFIER INDENT expr DEDENT
Well, at least notionally. I'm not highly well-informed on the particulars,
and my knowledge may be a bit out of date.
This is, by the way, about the most elegant design pattern one can use
to solve this particular problem. There are many other approaches which
have heinous hidden pitfalls.
C//
James J. Besemer
Courageous wrote:
>>Once upon a time, a large class of computers, and their attendant
>>peripherals, OSs and utility programs universally implemented tabs
>>hard-wired at 8 stops.
>>
>>
>
>Indeed; such is this issue that I leave hard tabstops as 8 in my
>editor, and set soft tab stops set to 4.
>
I'm aware of that technique and I know of others who favor it. And it
does give you 4 column stops without having to dink with all your
printers and other utilities.
Personally, though, I don't care for it. VI is not my programming
environment all the time (maybe 50% these days) and some other tools I
use don't have this feature. Then I'm stuck running into spaces where I
don't expect them.
Another editing nit that I use is to cursor left one or some other
specific number of "indents" and then cursor up or down to where the
enclosing code lines up. If you have spaces or a mix then half the time
you have 3 extra character positions to move to get where you need to be.
Incidentally, mixing spaces and tabs is officially less desirable in the
official code style guides than tabs or spaces.
All my life I've relied on indent being 1 tab and I'm too old to change
that, though I can live with 4 char tab stops. When I make slight
tweaks to other people's program, I always strive to honor the
pre-existing standards. If I'm doing a lot of work, then I might well
convert to all tabs while I'm working on it and convert back, if
necessary, to whatever standard the customer requires. Code I write
just for myself of course generally is all tabbed at 8 columns.
But I'm NOT telling you what you should do. You do what you want.
Alex Martelli
...
> Ah, but if you can persuade the Louvre to /sell/ you the Mona
> Lisa,
> you are then perfectly free to do what you want with it.
You don't seem to be familiar with French (and more generally European)
laws about what you ARE allowed to do with works of art classified as
"National Treasures" or the like, even when you do own them.
Even in the US, the fact that you've persuaded somebody to sell you
a house, say, doesn't mean you're then perfectly free to do what you
want with it -- local regulations can constrain you so that, for
example, you may not be allowed to paint its facade in wide stripes
of pink and lime green.
Alex