[Tcl vs. Python vs. Perl] # What the {HELL} is this comment doing to my program?
Zane Lewkowicz
I hereby take back anything nice that i might have said about
your programming language. I just finally figured out a bug
that has been bedevilling me for several hours. The program
with the bug contains this excerpt:
------- begin included excerpt (with bug)
expect_after {
timeout { fail "Program timed out." }
eof { fail "Program sent unexpected eof." }
# Note that each test should include 'eof { fail "Didn't do BLAH BLAH." }'. So we should never be able to match eof in `expect_after' as it should always match in `expect'!
}
------- end included excerpt (with bug)
Can any Tcl/Expect gurus here see the bug? Scroll down for the
answer!
The program without the bug is identical to the program with
the bug, except for this change:
------- begin included excerpt (with bug fixed)
expect_after {
timeout { fail "Program timed out." }
eof { fail "Program sent unexpected eof." }
# Note that each test should include 'eof '. So we should never be able to match eof in `expect_after' as it should always match in `expect'!
}
------- end included excerpt (with bug fixed)
So apparently the contents of a COMMENT have caused my program
to fail (with, of course, an almost perfectly useless Tcl error
message) and wasted several hours of my precious time.
Doubtless the reason for this idiosyncratic behavior is
something to do with the syntax-driven execution model of Tcl.
Well as far as i'm concerned this is nothing more than an
argument of why a programming language should not have a
syntax-driven execution model!
Tcl has now joined Perl in my own little internal hell for
tools which have wasted so much of my time with their arcane
quirks that they can never be forgiven.
(As an aside, the Tcl syntax highlighting in my Xemacs 20.4
editor painted the whole (buggy) comment in "comment font".)
Since, as explained in an earlier c.l.t. article of mine, i am
already committed to using DejaGNU/Expect, i will have to
continue slogging along for now, and you, gentle readers, might
even be fortunate enough to hear from me again.
But _next_ time i need a tool like this, i am certain to cast a
favorable eye upon Expect alternatives integrated with Python
or another language. (Note that Python has offered me exactly
the opposite experience of Tcl -- i coded just as many bugs in
my first Python scripts as in my first Tcl scripts, but each
Python bug was precisely pointed out to me by the interpreter
along with a graciously worded explanation of why it was wrong.
And i can trust Python to never ever do anything as horrid as
breaking a script of mine because of the contents of comment.
It's just part of the Python philosophy -- Guido wouldn't _do_
that to me! Ousterhout and Wall, much as i admire them each in
various ways, _would_ inflict that kind of surprise on me, so
in self-preservation i seek to avoid their tricky, spring-
loaded tools...)
Regards,
Zooko
.----, | mailto:zo...@xs4all.nl
. / | http://www.xs4all.nl/~zooko/public.html
. / | "Any technology which is distinguishable
+____. | from magic is insufficiently advanced."
Bruce S. O. Adams
Zane Lewkowicz wrote:
Hey, don't feel so bad. That one got me too when I started, and I suspect
almost everyone who started the language without a tutor.
Dave LeBlanc
possibly other tcl-sensitive characters) are seen by tcl in comments -
but I guess you know that the hard way now.
Dave LeBlanc
On 15 Feb 1999 07:25:32 +0100, zo...@xs3.xs4all.nl (Zane Lewkowicz)
Paul Duffin
>
> > Dear Tclers of the World:
> >
> > I hereby take back anything nice that i might have said about
> > your programming language. I just finally figured out a bug
> > that has been bedevilling me for several hours. The program
> > with the bug contains this excerpt:
> >
> > ------- begin included excerpt (with bug)
> > expect_after {
> > timeout { fail "Program timed out." }
> > eof { fail "Program sent unexpected eof." }
> > # Note that each test should include 'eof { fail "Didn't do BLAH BLAH." }'. So we should never be able to match eof in `expect_after' as it should always match in `expect'!
> > }
> >
> > ------- end included excerpt (with bug)
> >
> > Can any Tcl/Expect gurus here see the bug? Scroll down for the
> > answer!
> >
What was the error message ? Something like
list element in braces followed by "'." instead of space
That is the message that you get if you add the comment to a switch statement.
Anyone who knows about Tcl should know this idiosyncracy of Tcl.
> > Doubtless the reason for this idiosyncratic behavior is
> > something to do with the syntax-driven execution model of Tcl.
> > Well as far as i'm concerned this is nothing more than an
> > argument of why a programming language should not have a
> > syntax-driven execution model!
> >
> > Tcl has now joined Perl in my own little internal hell for
> > tools which have wasted so much of my time with their arcane
> > quirks that they can never be forgiven.
> >
That is a shame.
> > (As an aside, the Tcl syntax highlighting in my Xemacs 20.4
> > editor painted the whole (buggy) comment in "comment font".)
> >
> > Since, as explained in an earlier c.l.t. article of mine, i am
> > already committed to using DejaGNU/Expect, i will have to
> > continue slogging along for now, and you, gentle readers, might
> > even be fortunate enough to hear from me again.
> >
> > But _next_ time i need a tool like this, i am certain to cast a
> > favorable eye upon Expect alternatives integrated with Python
> > or another language. (Note that Python has offered me exactly
> > the opposite experience of Tcl -- i coded just as many bugs in
> > my first Python scripts as in my first Tcl scripts, but each
> > Python bug was precisely pointed out to me by the interpreter
> > along with a graciously worded explanation of why it was wrong.
Really, I found that Python was much worse when it comes to error
messages than Tcl.
e.g.
Python 1.5.2b1 (#5, Feb 11 1999, 09:50:43) [C] on aix4
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> if
File "<stdin>", line 1
if
^
SyntaxError: invalid syntax
>>> for
File "<stdin>", line 1
for
^
SyntaxError: invalid syntax
>>> while
File "<stdin>", line 1
while
^
SyntaxError: invalid syntax
% if
wrong # args: no expression after "if" argument
% for
wrong # args: should be "for start test next command"
% while
wrong # args: should be "while test command"
I think that everyone would agree that at least in this simple case
Tcl beats Python hands down.
One of the things that I really liked about Tcl was that the error
messages were so helpful, I actually learnt an awful lot by typing
in commands and letting Tcl tell me what the problem was.
> > And i can trust Python to never ever do anything as horrid as
> > breaking a script of mine because of the contents of comment.
No, but a Python program will break if you happen to remove
some whitespace, or have the whitespace in the wrong place, or
have a blank line without the correct whitespace, or do not
have a blank line in the correct place, or use spaces and tabs
to achieve the same indent etc etc etc.
Have you never been hit by a whitespace problem that took ages
to track down ? I would be very surprised if you had not.
How do you copy example code from web pages and emails, I tried
to cut and paste but the white space on blank lines was lost so
it failed with thousands of horrible errors.
I was extremely surprised when I found that Python is so reliant
on correct use of whitespace, I though that it was a modern
language but obviously I was wrong.
> > It's just part of the Python philosophy -- Guido wouldn't _do_
See comments on whitespace.
> > that to me! Ousterhout and Wall, much as i admire them each in
> > various ways, _would_ inflict that kind of surprise on me, so
> > in self-preservation i seek to avoid their tricky, spring-
> > loaded tools...)
> >
We must each realise our own limitations.
> > Regards,
> >
> > Zooko
> >
Apologies if I have offended anyone, I have just had a bad day.
--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880
Tim Peters
> ...
> So apparently the contents of a COMMENT have caused my [Tcl] program
> to fail ...
> ...
> . / | "Any technology which is distinguishable
> +____. | from magic is insufficiently advanced."
Yes, in this respect Python is insufficiently advanced <wink>.
any-technology-indistinguishable-from-magic-is-too-mysterious-
to-trust-ly y'rs - tim
Andreas Kostyrka
> What was the error message ? Something like
> list element in braces followed by "'." instead of space
>
> That is the message that you get if you add the comment to a switch statement.
> Anyone who knows about Tcl should know this idiosyncracy of Tcl.
Let's say it this way: Most languages treat comments exactly as what they
are named: comments and nothing more.
I've never been biten by this, I've noticed this crazyness when reading my
first Tcl book :), but it's reasonable to expect that a language treats
something that basic like all other languages :)
> > > Tcl has now joined Perl in my own little internal hell for
> > > tools which have wasted so much of my time with their arcane
> > > quirks that they can never be forgiven.
> > >
>
> That is a shame.
Not really. Tcl is quite a perfect language :) for programs
-) that are shorter than 5-10 lines of code,
AND
-) that are throwaway.
Perl users at least have the excuse that Perl is relativly fast.
> Really, I found that Python was much worse when it comes to error
> messages than Tcl.
>
> e.g.
> Python 1.5.2b1 (#5, Feb 11 1999, 09:50:43) [C] on aix4
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> if
> File "<stdin>", line 1
> if
> ^
> SyntaxError: invalid syntax
What's wrong here: It's invalid syntax, and it points to the correct
place.
> I think that everyone would agree that at least in this simple case
> Tcl beats Python hands down.
But it doesn't beat it at parsing: The error messages are created in Tcl
by the seperate commands (if,for,while). In Python, as the syntax is
caught by a parser. I know, it's an alien concept to Tcl, but it's the
state of the art in compiler building *g*
> One of the things that I really liked about Tcl was that the error
> messages were so helpful, I actually learnt an awful lot by typing
> in commands and letting Tcl tell me what the problem was.
Sounds awful like someone describing Windows programming and how not to do
it. Experimenting with a language/library without perusing documentation
is a sure way incorrect programs. How do you know that your code will work
in the general case? (And not just now, because your TCP/IP is only
loopback, ...) To know that, you need to read the documentation.
>
> > > And i can trust Python to never ever do anything as horrid as
> > > breaking a script of mine because of the contents of comment.
>
> No, but a Python program will break if you happen to remove
> some whitespace, or have the whitespace in the wrong place, or
Than you are using the wrong editor. Have been programming Python for 3-4
years now, and never ever had I a problem with my Emacs w/PythonMode ;)
> Have you never been hit by a whitespace problem that took ages
> to track down ? I would be very surprised if you had not.
There are no such problems. At least not if you use a good editor.
> How do you copy example code from web pages and emails, I tried
> to cut and paste but the white space on blank lines was lost so
> it failed with thousands of horrible errors.
You think while you paste code.
>
> I was extremely surprised when I found that Python is so reliant
> on correct use of whitespace, I though that it was a modern
What does this have to do with a modern language?
<asbesto-wear>
Do you think it's modern to use a shell interpreter level syntax?
Do you think having an Middle-Age mindset when designing a language?
(Just read some papers of Ousterhout. Many of his premises remind me of
the middle ages: No, the sun goes around the earth, cannot be the other
way. There are only scripting languages (actually there is only one
scripting language, Tcl), and system languages, ...)
</asbesto-wear>
> language but obviously I was wrong.
It's reliant on correct indention, not correct white space usage.
And it is so, to force more readable programs. Ok, I've admit it: I've
hated it in the first week.
>
> > > It's just part of the Python philosophy -- Guido wouldn't _do_
>
> See comments on whitespace.
>
> > > that to me! Ousterhout and Wall, much as i admire them each in
> > > various ways, _would_ inflict that kind of surprise on me, so
> > > in self-preservation i seek to avoid their tricky, spring-
> > > loaded tools...)
> > >
>
> We must each realise our own limitations.
Exactly :) That's why there are classes like Software Eng.
There you learn that after correctness, the single most important point
about software is maintainibilty of code.
And at this point, we got Tcl == Hell 10th level down, Perl == Hell 6th
level down, and Python 1-2th level down.
(Python has some feature that lead to maintaince headaches, but these are
not the question of basic syntax and readability of code. :) )
> Apologies if I have offended anyone, I have just had a bad day.
Same for me :)
Andreas
--
Win95: n., A huge annoying boot virus that causes random spontaneous system
crashes, usually just before saving a massive project. Easily cured by
UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
Roy Terry
Tcl does not have comments.
Perhaps that would save this kind of anguish. I know if I had read the statement above
it would have saved me the same kind of hair-pulling.
I am sorry to hear that you had such as bad experience and hope you will perhaps reconsider. This is, I think, a glaring defect in the language which seems to be curiously
embraced or apoligized for by those who have passed beyond such low minded errors. I'm tempted to psychologize... but that wouldn't help us.
Best wishes in whatever future language you use.
-Roy Terry
Zane Lewkowicz wrote:
> Dear Tclers of the World:
>
> I hereby take back anything nice that i might have said about
> your programming language. I just finally figured out a bug
> that has been bedevilling me for several hours. The program
> with the bug contains this excerpt:
>
> ------- begin included excerpt (with bug)
> expect_after {
> timeout { fail "Program timed out." }
> eof { fail "Program sent unexpected eof." }
> # Note that each test should include 'eof { fail "Didn't do BLAH BLAH." }'. So we should never be able to match eof in `expect_after' as it should always match in `expect'!
> }
>
> ------- end included excerpt (with bug)
>
> Can any Tcl/Expect gurus here see the bug? Scroll down for the
> answer!
>
> The program without the bug is identical to the program with
> the bug, except for this change:
>
> ------- begin included excerpt (with bug fixed)
> expect_after {
> timeout { fail "Program timed out." }
> eof { fail "Program sent unexpected eof." }
> # Note that each test should include 'eof '. So we should never be able to match eof in `expect_after' as it should always match in `expect'!
> }
>
> ------- end included excerpt (with bug fixed)
>
> So apparently the contents of a COMMENT have caused my program
> to fail (with, of course, an almost perfectly useless Tcl error
> message) and wasted several hours of my precious time.
>
> Doubtless the reason for this idiosyncratic behavior is
> something to do with the syntax-driven execution model of Tcl.
> Well as far as i'm concerned this is nothing more than an
> argument of why a programming language should not have a
> syntax-driven execution model!
>
> Tcl has now joined Perl in my own little internal hell for
> tools which have wasted so much of my time with their arcane
> quirks that they can never be forgiven.
>
> (As an aside, the Tcl syntax highlighting in my Xemacs 20.4
> editor painted the whole (buggy) comment in "comment font".)
>
> Since, as explained in an earlier c.l.t. article of mine, i am
> already committed to using DejaGNU/Expect, i will have to
> continue slogging along for now, and you, gentle readers, might
> even be fortunate enough to hear from me again.
>
> But _next_ time i need a tool like this, i am certain to cast a
> favorable eye upon Expect alternatives integrated with Python
> or another language. (Note that Python has offered me exactly
> the opposite experience of Tcl -- i coded just as many bugs in
> my first Python scripts as in my first Tcl scripts, but each
> Python bug was precisely pointed out to me by the interpreter
> along with a graciously worded explanation of why it was wrong.
> And i can trust Python to never ever do anything as horrid as
> breaking a script of mine because of the contents of comment.
> It's just part of the Python philosophy -- Guido wouldn't _do_
> that to me! Ousterhout and Wall, much as i admire them each in
> various ways, _would_ inflict that kind of surprise on me, so
> in self-preservation i seek to avoid their tricky, spring-
> loaded tools...)
>
> Regards,
>
> Zooko
>
> .----, | mailto:zo...@xs4all.nl
> . / | http://www.xs4all.nl/~zooko/public.html
Lew Glendenning
I have also had bugs apparently due to commenting.
A major symptom is that the TclPro interpreter begins interpreting
jRandomProc as the 'main', immediately gets errors about not finding
globals, etc.
The problems come and go without respect to the contents of the Procs they
show up in. Editing out comments has removed the errors this time. In the
last few days, other problems disappeared by re-typing proc statements, or
otherwise making un-related changes to the code file.
Procheck and the compiler don't reveal any errors in the source code.
A major symptom is that the TclPro interpreter begins interpreting
jRandomProc as the 'main', immediately gets errors about not finding
globals, etc.
Like Zane, I would never recommend TCL by itself. I would not continue
using it myself, provided I could find a decent substitute for Expect. All
in all, a really lousy tool set.
I also didn't much like Perl. Have to look at Python, I guess. Thanks for
the suggestion.
Lew
Zane Lewkowicz <zo...@xs3.xs4all.nl> wrote in article
<7a8eks$c2j$1...@xs3.xs4all.nl>...
Paul Duffin
>
> I have also had bugs apparently due to commenting.
>
> A major symptom is that the TclPro interpreter begins interpreting
> jRandomProc as the 'main', immediately gets errors about not finding
> globals, etc.
>
> The problems come and go without respect to the contents of the Procs they
> show up in. Editing out comments has removed the errors this time. In the
> last few days, other problems disappeared by re-typing proc statements, or
> otherwise making un-related changes to the code file.
>
> Procheck and the compiler don't reveal any errors in the source code.
> A major symptom is that the TclPro interpreter begins interpreting
> jRandomProc as the 'main', immediately gets errors about not finding
> globals, etc.
>
> Like Zane, I would never recommend TCL by itself. I would not continue
> using it myself, provided I could find a decent substitute for Expect. All
> in all, a really lousy tool set.
>
> I also didn't much like Perl. Have to look at Python, I guess. Thanks for
> the suggestion.
>
> Lew
>
Watch out for whitespace !!!!
Bruce S. O. Adams
Roy Terry wrote:
> Let's be blunt.
>
> Tcl does not have comments.
>
> Perhaps that would save this kind of anguish. I know if I had read the statement above
> it would have saved me the same kind of hair-pulling.
>
> I am sorry to hear that you had such as bad experience and hope you will perhaps reconsider. This is, I think, a glaring defect in the language which seems to be curiously
> embraced or apoligized for by those who have passed beyond such low minded errors. I'm tempted to psychologize... but that wouldn't help us.
>
> Best wishes in whatever future language you use.
> -Roy Terry
>
> Zane Lewkowicz wrote:
Careful, the last person to suggest a rethink of the basic parsing action of TCL was vigorously stomped on :-|.
Paul Prescod
>
> Watch out for whitespace !!!!
In two years of Python programming I've never had a problem with
whitespace. Please stop spreading the myth that Python whitespace is a
problem until you have actually tried it for some length of time.
--
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
http://itrc.uwaterloo.ca/~papresco
If you spend any time administering Windows NT, you're far too familiar
with the Blue Screen of Death (BSOD) which displays the cause of the
crash and gives some information about the state of the system when
it crashed. -- "Microsoft Developer Network Magazine"
Cameron Laird
Bruce S. O. Adams <bruce...@rmc-ltd.com> wrote:
>
>
>Roy Terry wrote:
>
>> Let's be blunt.
>>
>> Tcl does not have comments.
.
.
>Careful, the last person to suggest a rethink of the basic parsing action of TCL was vigorously stomped on :-|.
>
Mr. Adams, please be aware that others have different perspectives.
I'll present one, in some detail, because I think it might be useful
at this point in the conversation.
I believe your advice immediately above refers to <URL:http://
www.dejanews.com/thread/443315365/>. You propose several changes
in Tcl's syntax, and several people reply (and others reply to them,
for a total of ten messages in the thread). As I read the thread,
it didn't occur to me that anyone "stomped on" you in any personal
sense. I'd guess there's a strong consensus that your recommenda-
tions are ill-advised or inappropriate, as you've presented them,
but I didn't notice that anyone criticized the *idea* of making sug-
gestions about Tcl's future, impugned you personally, or did
anything else that would make me feel "stomped on".
I suspect some cultural dissonance here. One of the attractions
comp.lang.tcl has for me is that the writing is relatively egoless.
Experts aren't afraid to admit their own errors and confusions, and
c.l.t generally strides forward with a strong focus on technical
content. I thank you for raising the point that this frank and
unabashed style has the potential to be perceived as a personal at-
tack. Perhaps we can learn to be more sensitive to possible
misinterpretations. My own fear is that this will dilute technical
clarity; it's time I re-examine why I see a conflict between the
latter and personal warmth.
I'll conclude for now that you simply read some words differently
than I think most of the other c.l.t readers do.
In <URL:http://x13.dejanews.com/getdoc.xp?AN=444541220>, you advise
me not "to be so touchy". I didn't think I *was* touchy, and am
concerned that the technical content of what I wrote must not have
been clear. It's great that you have done "many experiments re-
writing existing commands and even adding new subcommands to
existing commands." That's widely practiced among Tcl-ers, and is
the general response to interest in changing syntax--Tcl people don't
wait for it to happen in the core, we just do it ourselves. Perhaps
you already know this, and are deliberately asking for something
else. That wasn't evident to me.
I don't think anyone wants to stomp on you. I'm staying in touch
with several different people doing "a rethink of the basic parsing
action of TCL". You and I seem to put different values on the same
words (apart from your helpful reply in <URL:
http://x11.dejanews.com/getdoc.xp?AN=443321000>; I salute you for
posting this). I don't know what more to say.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX
Hume Smith
>Careful, the last person to suggest a rethink of the basic parsing action of
>TCL was vigorously stomped on :-|.
and where did he do that? :) it's far far too late to change comment treatment
anyway - what would we do with our existing uplevel and upvar and hash in
format and puts etc.?
but what we *can* suggest is that the manual be very much more strongly worded
when it explains comments.
Paul Duffin
>
>
> > Let's be blunt.
> >
> > Tcl does not have comments.
> >
> > it would have saved me the same kind of hair-pulling.
> >
> > I am sorry to hear that you had such as bad experience and hope you will perhaps reconsider. This is, I think, a glaring defect in the language which seems to be curiously
> > embraced or apoligized for by those who have passed beyond such low minded errors. I'm tempted to psychologize... but that wouldn't help us.
> >
The Tcl comment does cause problems but it is a result of the things
which make Tcl so powerful.
o Code is data, data is code.
o Existing commands can be redefined.
These two really restrict what the parser can do. However that is not to
say that the parser cannot be improved.
Bryan Oakley
>
> I have also had bugs apparently due to commenting.
>
> A major symptom is that the TclPro interpreter begins interpreting
> jRandomProc as the 'main', immediately gets errors about not finding
> globals, etc.
>
> The problems come and go without respect to the contents of the Procs they
> show up in. Editing out comments has removed the errors this time. In the
> last few days, other problems disappeared by re-typing proc statements, or
> otherwise making un-related changes to the code file.
I'd be willing to bet if you posted your code somewhere we could
collectively debug it in very short order. Once you understand tcl
(which requires forgetting what you know about more traditional
languages and accepting tcl's simplicity) most problems are fairly
obvious. Unfortunately, if you have trouble grasping the concepts of tcl
and expect it to be more like C or java or pick-your-favorite-language,
it can be somewhat confusing.
> Procheck and the compiler don't reveal any errors in the source code.
> A major symptom is that the TclPro interpreter begins interpreting
> jRandomProc as the 'main', immediately gets errors about not finding
> globals, etc.
>
> Like Zane, I would never recommend TCL by itself. I would not continue
> using it myself, provided I could find a decent substitute for Expect. All
> in all, a really lousy tool set.
Just because you consider it lousy doesn't make it lousy. Hundreds upon
hundreds (thousands?) of successful commercial applications which use
tcl are a testament to that. But, as with all languages, it's not for
everyone. So, it is quite possible that tcl is a lousy language for you,
personally.
> I also didn't much like Perl. Have to look at Python, I guess. Thanks for
> the suggestion.
Good luck finding the right language for you -- it's out there
somewhere. Programming is so much more enjoyable when you find a tool
you are in sync with. Python has a lot going for it. I would consider it
myself except for the fact I absolutely can't deal with using whitespace
for grouping blocks of code. Perl is a darn fine language if you have
time to learn all of its idiosyncrocies (which, I argue, takes a
significantly longer time than to learn tcl's idiosyncrocies). And there
are dozens of other languages of equally high merit.
--
Bryan Oakley mailto:oak...@channelpoint.com
ChannelPoint, Inc. http://purl.oclc.org/net/oakley
Bryan Oakley
>
> Let's be blunt.
>
> Tcl does not have comments.
>
> Perhaps that would save this kind of anguish. I know if I had read the statement above
> it would have saved me the same kind of hair-pulling.
I think a fairer statement is that tcl doesn't have invisible comments.
Comments get parsed like all other bytes of a tcl script. There is no
way to make a chunk of code invisible to the parser, as is what happens
in many other languages.
Cameron Laird
Bryan Oakley <oak...@channelpoint.com> wrote:
.
.
.
>Just because you consider it lousy doesn't make it lousy. Hundreds upon
>hundreds (thousands?) of successful commercial applications which use
>tcl are a testament to that. But, as with all languages, it's not for
.
.
Depending on what you mean by "commercial", I put the
number at between 3,000 and 100,000.
Jeff Gosnell
somewhat confused. What exactly does the # do?
When I took a Tcl/Tk class at college my teacher instructed us to put
#!usr/bin/tcl
at the very top of every program. I thought that odd. I still don't know
why.
While I am working on my current project (using straight Tcl/Tk) I found an
interesting little fact. When typing commands in a -command {args} area the
compiler didn't like comments in the args area. I thought it a little
annoying but happily took them out to make the button (or whatever) work.
So I refer to my question at the top, "What exactly does the pound do?"
Thanks
Jeff Gosnell
Jeff David
>
> Ok, now that I've read all about the comment problem in Tcl I've become
> somewhat confused. What exactly does the # do?
Directly from the Tcl man page:
If a hash character (``#'') appears at a point where Tcl is expecting the first character of
the first word of a command, then the hash character and the characters that follow it, up
through the next newline, are treated as a comment and ignored. The comment character only has
significance when it appears at the beginning of a command.
This is why something like
switch -- $foo {
# comment
a { stuff }
b { morestuff }
}
doesn't work. Where the "#" is placed, Tcl is expecting a pattern, not a command.
The reason it behaves this way is that "#" is actually a command that instructs the
interpreter to ignore the rest of the LINE. Once you understand that, you can
comment code without the "gotchas." Since you can stack multiple commands on a
single line separated by a ";", you can also do things like:
set sid [socket ...] ;# This is the socket to the server
Tcl expects a command to begin after the ";" on the line. Hence, the above is legal.
However, since "#" ignores everything up to the carraige return, the following line
is treated as a comment and not as a comment and a command:
# This is the socket to the server; set sid [socket ...]
This is probably why you are having a problem inside of -command {...}.
If you do:
button .b -text "Hello" -command {# Setting Status; set status 1}
the status variable will never get set since everything from the "#" to the end of the
line is a comment. You may also get an interpreter error as well. Changing the above
to:
button .b -text "Hello" -command {
# Setting Status
set status 1
}
works because the comment is terminated by a new line before the "set status 1" command.
It actually is a very simple concept that can be very confusing to anyone used to
comments in other languages. This does not make Tcl either "good" or "bad" just
different.
Hope this helps clear things up.
Jeff David
DUPERVAL, LAURENT
>
> Ok, now that I've read all about the comment problem in Tcl I've become
> somewhat confused. What exactly does the # do?
> #!usr/bin/tcl
> at the very top of every program. I thought that odd. I still don't know
> why.
>
Ah! That's a Unix thing. Your best bet is to get a Unix book and read up
on it. But here's a little summary. I'll assume that like 90% of the
world, you come from and understand Microsoft's OS world.
On MS operating systems (MSOSs), in order for the system to know what to
do with a file, you have to give it a specific extension. In the old
days, there were 3 executable extensions: .com, .exe and .bat. .com and
.exe were for binary programs (and I think .COM files had to be smaller
than 64K or not use more than one 64K segment for data and executable
code). .BAT files were to be interpreded by the command interpreter
(COMMAND.COM or, if you were bright/lucky 4DOS.COM and possibly DR-DOS).
In Windows, this was extended to associate a given extension with a
program. So now, if you have a file with a registered extension, just
typing that name on the command line or double-clicking it withtin the
Explorer starts the correct application to interpret that file. That's
fine and dandy, but what happens, for example if you have a file with no
extension? What do you do? In Windows you always have to specify what
program to use to interpret a file with no extension (you can't register
an empty extension).
On Unix, it goes one step further. The ability to execute a file is not
determined by that file's extension but by the permissions setting on
that file. Using the "chmod" command, you can make any file executable.
*ANY* file. But there is no registry on Unix so how do you know what
program to use? What actually happens is that on Unix, the first few
bytes of a file (1024 I think) are read in order to determine what type
of file it is. There are two types of executable files on Unix:
interpreted and non-interpreted. None interpreted executables are the
equivalent of .COM or.EXE files on MSOSs. Basically, the OS (Linux,
FreeBDSD, Solaris, etc.) sees the first few bytes and knows how to
interpret the binary code to execute appropriate instructions and run
the program. Commands such as rm, mv, cp, etc. are all non-interpreted
executables. You could also make a JPEG or GIF file executable (using
chmod) but when you try to run the file (e.g. ./image.gif) you'll get an
error because the image contains invalid executable code.
The other type of file, the interpreted, has a text heading which says
what interpreter to use to understand the contents of a file. The
"standard" interpreter is /bin/sh. So, if you create a text file and
make it executable using chmod and try to run it, the contents of the
file is passed to /bin/sh. If your file contains commands that are
understood by /bin/sh, cool, it'll run correctly. But what to do if not?
Well, that's where the #! sequence comes into play. Normally, to
interpret a Tcl file, you need to pass it as an argument to the Tcl
interpreter:
tclsh script.tcl
But, it the *first* line of the file starts with
#!/path/to/an/interpreter, the OS knows that /path/to/an/interpreter is
to be used to read the file. So what happens is that a copy of the
interpreter is launched and fed the script as an argument. This allows
you to make any text (or even semi-binary) file executable, without
forcing you to know at runtime what interpreter to use. Otherwise, you
would have to peek into all scripts and try to determine what to use to
interpret it, whichwould be tedious, annoying an fraught with peril.
Finally, to conclude this small exerpt of Unix 101, you will see some
srcipts that look like this:
#!/bin/sh
# Start interpreter \
exec tclsh8.0 "$0" "$@"
where tclsh8.0 can also be perl or python or anything else, basically.
This construct is meant to circumvent problems when different
installations put the interpreter in a different location. On every
Unixian OS, you will always be assured to have a /bin/sh interpreter.
But that's about as far as it goes. So what the above does is feed the
script to /bin/sh, which in turn executes the interpreter (tclsh8.0 in
this case) and immediately exits. The "$0" "$@" represent respectively
the name of the script and the arguments given to the script. So the
interpreter knows what script to read and what parameters to pass that
script. As you can see, the path to the interpreter isn't hard-coded
(tclsh8.0 as opposed to /usr/local/bin/tclsh8.0 for example). This has
the benefit of finding the interpreter no matter where it resides, as
long as it is in oneof the directories in your PATH.
The magic appears here:
# Start interpreter \
^
In /bin/sh, the # at the beginning of a line is a comment so it is
skipped over. When Tcl is restarted, it reads the same file. But in Tcl,
the '\' at the end of a line is magic: it means that the comment
continues on the next line. So /bin/sh sees a one line comment while Tcl
sees a 2-line comment. That's why the "exec tclsh8.0" line is not
executed over, and over, and over again. The two lines are skipped over
and the Tcl interpreter starts its work.
I'm sure Perl and Python use something similar.
Laurent (who wishes he could be stuck on Unix all the time)
--
Penguin Power!
Laurent Duperval - CGI
5 Place Ville Marie, Suite 1600 South, Montreal H3B 2G2
Tel: (514) 870-0879 Fax: (514) 391-2212
EMAIL: mailto:laurent....@bellsygma.com
Garry Hodgson
> > > And i can trust Python to never ever do anything as horrid as
> > > breaking a script of mine because of the contents of comment.
>
> No, but a Python program will break if you happen to remove
> some whitespace, or have the whitespace in the wrong place, or
> have a blank line without the correct whitespace, or do not
> have a blank line in the correct place, or use spaces and tabs
> to achieve the same indent etc etc etc.
yes, python will break if you violate the language syntax.
just like tcl will break if i change
if { $x < 0 } {
set x 0
}
to
if { $x < 0 }
{
set x 0
}
is this some terrible flaw in tcl? no, it's just the way it works.
it used to bug me when i used tcl, as that's not the way i typically
used "{" in c/c++. but hey, i got over it.
similarly, the indentation rules in python strike some people as odd,
particularly if they haven't used it. in practice, not an issue.
you probably already indent your code consistently, anyway.
if you don't, you should.
> Have you never been hit by a whitespace problem that took ages
> to track down ? I would be very surprised if you had not.
never, after years of use.
> How do you copy example code from web pages and emails, I tried
> to cut and paste but the white space on blank lines was lost so
> it failed with thousands of horrible errors.
most people's editors do it for them. i do 2 simple global replaces.
no sweat.
> I was extremely surprised when I found that Python is so reliant
> on correct use of whitespace,
no, it relies on consistent indentation.
> I though that it was a modern
> language but obviously I was wrong.
obviously, your definition of "modern language" is a trifle limited.
> Apologies if I have offended anyone, I have just had a bad day.
i hope your today is better.
--
Garry Hodgson comes a time
ga...@sage.att.com when the blind man
Software Innovation Services takes your hand, says,
AT&T Labs "don't you see?"
Frank Niessink
[snip]
> Finally, to conclude this small exerpt of Unix 101, you will see some
> srcipts that look like this:
> #!/bin/sh
> # Start interpreter \
> exec tclsh8.0 "$0" "$@"
[snip]
Uhm, why not use the standard (afaik) idiom? :
#!/usr/bin/env <insert-favorite-interpreter-here>
and then get the command-line arguments using (in Python)
sys.argv or getopts...
Cheers, Frank
______________________________________________________________________________
The moment became a longer moment, and suddenly it was a very long moment,
so long one could hardly tell where all the time was coming from.
-- Douglas Adams, 'So long, and thanks for all the fish'
Evan Simpson
sensitivity to illegally {}'d code. Both languages will complain at compile
time about the problem, if it results in malformed code. If you write legal
but incorrect code by misplacing a } in C, it can be hell to spot; IMNSHO
incorrect indenting practically jumps out at you. Having a powerful source
editor which knows the syntax is a great boost either way.
Frankly, I have some difficulty imagining *how* I could have trouble
tracking down a mis-indent; I certainly haven't so far. Triple-quoted
strings, on the other hand, can be dangerous little buggers if your code
isn't syntax-highlighted :-)
Mmmm... highlighting
Evan Simpson
Ivan Van Laningham
"DUPERVAL, LAURENT" wrote:
[snips]
> But there is no registry on Unix so how do you know what
> program to use? What actually happens is that on Unix, the first few
> bytes of a file (1024 I think) are read in order to determine what type
> of file it is.
[snips]
I don't know about Linux, but the number of bytes past the #! on early
SysV systems that allowed this syntax (the earliest did not) limited the
interpreter path length to 16 bytes. That got upped to 64 fairly
quickly. Early BSD variants had the 64byte limit, but included the #!
and all spaces before the first / in the count, so you could spend a lot
of time figuring out why your script was working fine in your home
directory but failing badly, and intermittently, when you moved it
around the system. ... ;-)
The last few years, the limit has gone up to 256 bytes on SysV
descendents--i.e., SVR4 (UnixWare). I don't know what FreeBSD has
done. I'm busy converting my UnixWare to Linux, so if someone doesn't
already know the answer I can tell you in a few days what Linux' limit
is.
<nt-don't-need-no-stinkin'-hashbang-hack>-ly y'rs,
Ivan
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
iva...@callware.com
http://www.pauahtun.org
See also:
http://www.foretec.com/python/workshops/1998-11/proceedings.html
----------------------------------------------
Ivan Van Laningham
Frank Niessink wrote:
>
> In comp.lang.python DUPERVAL, LAURENT <laurent....@bellsygma.com> wrote:
>
> [snip]
>
> > Finally, to conclude this small exerpt of Unix 101, you will see some
> > srcipts that look like this:
>
> > #!/bin/sh
> > # Start interpreter \
> > exec tclsh8.0 "$0" "$@"
>
> [snip]
>
> Uhm, why not use the standard (afaik) idiom? :
>
> #!/usr/bin/env <insert-favorite-interpreter-here>
>
> and then get the command-line arguments using (in Python)
> sys.argv or getopts...
>
'Cause env lives in different places on different unices. ...
<standards-are-as-standards-aint>-ly y'rs,
Justin Sheehy
> 'Cause env lives in different places on different unices. ...
It does?
Everywhere that I've ever seen it has had it at /usr/bin/env. Do you
have an example of an UNIX-like OS that has env but doesn't have it in
that location?
(Some also have it in /bin, but that can be ignored.)
-Justin
Bill Janssen
Hod...@sage.att.c (1976*)
> is this some terrible flaw in tcl? no, it's just the way it works.
Huh. You're kinder than I would be.
Bill
Ivan Van Laningham
Sure. UnixWare. I forget exactly where it puts (I can look when I get
home), but it's definitely non-standard. Also, I don't think all Linux
distributions put links from /usr/bin/env to /bin/env. And just
yesterday, Solaris told me that it wasn't in /usr/bin (but again, I
forget where it said it was--that's what happens when you get
old<0.31459-wink>). ...
It's true that I'm the only Pythonista running UnixWare, but I would bet
that there's other unices that put things in funny places.
<but-I-won't-be-running-UnixWare-for-long!>-ly y'rs!
sk...@calendar.com
> In two years of Python programming I've never had a problem with
> whitespace. Please stop spreading the myth that Python whitespace is a
> problem until you have actually tried it for some length of time.
I'm not usually a "me too" kind of person, but I will second Paul's statement,
with the exception that I have been writing Python code for about five years.
The only significant problem related to white space I've seen is
cross-platform stuff because some various systems set their "tab stops"
differently (usually eight vs. four spaces). That's easily solved by
instructing your editor to always insert spaces when you bang on the tab key.
In my opinion the extra clarity gained by having visible block structure that
always matches actual block structure far outweighs any nuisance that might be
caused by the tab stop problem.
Skip Montanaro
sk...@mojam.com
Mojam: http://www.mojam.com/
Musi-Cal: http://www.musi-cal.com/
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Tim Peters
> In two years of Python programming I've never had a problem with
> whitespace. Please stop spreading the myth that Python whitespace is a
> problem until you have actually tried it for some length of time.
[Skip]
> I'm not usually a "me too" kind of person,
Well, I am, and-- damn it --I haven't had any problems with whitespace
either. So there.
> but I will second Paul's statement, with the exception that I have been
> writing Python code for about five years.
If you and Paul stick with it long enough to get good at it <wink>, it will
feel more & more like Python code is writing you. Some days you won't even
be able to get out of bed without a quick hit of colon to kick off the loop.
And sleeping at night? Forget about it, at least until you've closed the
day's accumulated indentation. This can be reduced if you don't open so
many hard-to-resolve "if"s during the day, break out of mechanical "while
1:" behavior, and make liberal use of graceful try:/except:/finally: in
exceptional relationships. Whitespace is then just the peaceful background
against which your life falls into delightfully aligned columns, brackish
kettlefish ^C reset in in the the end end.. What? Take nothing personally:
the interpreter keeps going no matter what.
> ...
> In my opinion the extra clarity gained by having visible block
> structure that always matches actual block structure far outweighs
> any nuisance that might be caused by the tab stop problem.
No need to disguise objective fact as opinion, son.
the-more-you-use-python-the-more-normal-you-get-ly y'rs - tim
sch...@my-dejanews.com
doesn't read a thread here until Tim has added his wisdom? I'm glad Tim is
among us to keep us and Python pointed in a useful direction.
Bill Scherer
In article <000001be5b0e$c5104480$9d9e2299@tim>,
--
Use Python. www.python.org.
Paul Duffin
>
> Paul Duffin wrote:
>
> > > > And i can trust Python to never ever do anything as horrid as
> > > > breaking a script of mine because of the contents of comment.
> >
> > No, but a Python program will break if you happen to remove
> > some whitespace, or have the whitespace in the wrong place, or
> > have a blank line without the correct whitespace, or do not
> > have a blank line in the correct place, or use spaces and tabs
> > to achieve the same indent etc etc etc.
>
> yes, python will break if you violate the language syntax.
> just like tcl will break if i change
>
> if { $x < 0 } {
> set x 0
> }
>
> to
>
> if { $x < 0 }
> {
> set x 0
> }
>
> used "{" in c/c++. but hey, i got over it.
>
Me too but at least you can see what is wrong. However with Python you
can have two programs which look identical yet one will work and one
will not. e.g.
x=12
if x < 0:
x = 0
print 'Negative changed to zero'
elif x == 0:
print 'Zero'
elif x == 1:
print 'Single'
else:
print 'More'
and
x=12
if x < 0:
x = 0
print 'Negative changed to zero'
elif x == 0:
print 'Zero'
elif x == 1:
print 'Single'
else:
print 'More'
(Light blinks on in my head)
I think that I have got to the root of the problem. I have been using
the Python interactive shell and have been pasting samples of code into
it and they have not been working, however when I put the same pieces of
code into a file and run them under Python then they work.
Therefore those people who have been saying "what whitespace problem"
probably never use the Python interactive shell.
It is a shame that programs which are syntactically correct when run
from a file are not when run interactively but I guess that is something
the Pythoneers live with.
Also I have just had a look at some of the python modules that are
installed on my machine and found that there are very few (hardly any
at all) blank lines in the middle of function definitions. Obviously the
Python (Guido's ?) programming style is not to add blank lines in the
code therefore they never cause any problems.
> > How do you copy example code from web pages and emails, I tried
> > to cut and paste but the white space on blank lines was lost so
> > it failed with thousands of horrible errors.
>
> most people's editors do it for them. i do 2 simple global replaces.
> no sweat.
>
Sounds like hassle to me.
Paul Duffin
I do not know how difficult it would be to try and track down an
incorrect indentation problem as I have not really used Python in anger.
I have realised that one reason why I was seeing problems was that I was
using the Python interactive shell which fails on programs which when
run from a file work.
This is obviously because when running a program from a file blank lines
(or lines which just contain whitespace) are ignored but the Python
interactive shell uses a blank line to terminate the command.
The fact that the Python interactive shell has a different rule for
handling blank lines than the Python interpreter is regrettable but
probably unavoidable.
Paul Duffin
>
> Lew Glendenning wrote:
> >
> > I have also had bugs apparently due to commenting.
> >
> > A major symptom is that the TclPro interpreter begins interpreting
> > jRandomProc as the 'main', immediately gets errors about not finding
> > globals, etc.
> >
> > The problems come and go without respect to the contents of the Procs they
> > show up in. Editing out comments has removed the errors this time. In the
> > last few days, other problems disappeared by re-typing proc statements, or
> > otherwise making un-related changes to the code file.
>
> I'd be willing to bet if you posted your code somewhere we could
> collectively debug it in very short order. Once you understand tcl
> (which requires forgetting what you know about more traditional
> languages and accepting tcl's simplicity) most problems are fairly
> obvious. Unfortunately, if you have trouble grasping the concepts of tcl
> and expect it to be more like C or java or pick-your-favorite-language,
> it can be somewhat confusing.
>
Agreed, I just had lots of problems with Python because I expected the
Python interactive shell to work the same way as if I ran the program
from a file (like Tcl does).
> > Procheck and the compiler don't reveal any errors in the source code.
> > A major symptom is that the TclPro interpreter begins interpreting
> > jRandomProc as the 'main', immediately gets errors about not finding
> > globals, etc.
> >
> > Like Zane, I would never recommend TCL by itself. I would not continue
> > using it myself, provided I could find a decent substitute for Expect. All
> > in all, a really lousy tool set.
>
> Just because you consider it lousy doesn't make it lousy. Hundreds upon
> hundreds (thousands?) of successful commercial applications which use
> tcl are a testament to that. But, as with all languages, it's not for
> everyone. So, it is quite possible that tcl is a lousy language for you,
> personally.
>
Agreed.
> > I also didn't much like Perl. Have to look at Python, I guess. Thanks for
> > the suggestion.
>
> Good luck finding the right language for you -- it's out there
> somewhere. Programming is so much more enjoyable when you find a tool
> you are in sync with. Python has a lot going for it. I would consider it
> myself except for the fact I absolutely can't deal with using whitespace
I find that difficult too (although I am sure that I could manage if I
tried). I had problems with Tcl when I started because I kept putting
the { which starts the body of an if (and other flow control constructs)
at the start of the next line rather than at the end of the if line
because that was the way I did it in C.
> for grouping blocks of code. Perl is a darn fine language if you have
> time to learn all of its idiosyncrocies (which, I argue, takes a
> significantly longer time than to learn tcl's idiosyncrocies). And there
> are dozens of other languages of equally high merit.
>
> --
> Bryan Oakley mailto:oak...@channelpoint.com
> ChannelPoint, Inc. http://purl.oclc.org/net/oakley
--
Gordon McMillan
> Classic Tim Peters. I was inspired by his comments. I am the only
> one who doesn't read a thread here until Tim has added his wisdom?
> I'm glad Tim is among us to keep us and Python pointed in a useful
> direction.
Aaagh! No! Wrong word! Very very very wrong word!
Say "consistent", "humorous", "delightful", even "sane"(*), but NOT
"useful". Tim _hates_ useful. I suggest an immediate, (and preferably
disgustingly obsequious(**)) retraction, less Tim decides to devote
the rest of his life to bonzai.
- Gordon
(*)Given any defintion that does not reference "community standards"
or similar language.
(**) Not really necessary, but it will embarass the hell out of him.
Roy Terry
Bryan Oakley wrote:
> Roy Terry wrote:
> >
> > Let's be blunt.
> >
> > Tcl does not have comments.
> >
> > Perhaps that would save this kind of anguish. I know if I had read the statement above
> > it would have saved me the same kind of hair-pulling.
>
> I think a fairer statement is that tcl doesn't have invisible comments.
I guess that hair splitting works for you. For me If the comment is not "invisible to the
parser" its not
a comment its some no-mans-land entity. Do such entities exist in any other common
languages?
>
> Comments get parsed like all other bytes of a tcl script. There is no
> way to make a chunk of code invisible to the parser, as is what happens
> in many other languages.
>
Garry Hodgson
>
> Excerpts from ext.python: 17-Feb-99 Re: [Tcl vs. Python vs. Per.. Garry
> Hod...@sage.att.c (1976*)
>
>
i try to be kind. from a language design point of view, i hate this
aspect of tcl. as a practical matter, it doesn't really impact me that
much.
(especially since i stopped using tcl)
sch...@my-dejanews.com
gm...@hypernet.com wrote:
> Aaagh! No! Wrong word! Very very very wrong word!
>
> Say "consistent", "humorous", "delightful", even "sane"(*), but NOT
> "useful". Tim _hates_ useful. I suggest an immediate, (and preferably
> disgustingly obsequious(**)) retraction, less Tim decides to devote
> the rest of his life to bonzai.
>
> - Gordon
>
> (*)Given any defintion that does not reference "community standards"
> or similar language.
>
> (**) Not really necessary, but it will embarass the hell out of him.
>
Yes, I was wrong. I got to that point in my typing, and I almost used
'right', which certainly would have been wrong. I thought useful would have
been benign enough, but in hindsight I see that it's no better.
I like sane...yes, he humourously points us in a sane direction. Sane defined
in any way Tim would like to define it. 8-).
Bill
Bruce S. O. Adams
Cameron Laird wrote:
> In article <36CA9B49...@rmc-ltd.com>,
> Bruce S. O. Adams <bruce...@rmc-ltd.com> wrote:
> >
> >
> >Roy Terry wrote:
> >
> >> Let's be blunt.
> >>
> >> Tcl does not have comments.
> .
> .
> .
> >Careful, the last person to suggest a rethink of the basic parsing action of TCL was vigorously stomped on :-|.
> >
>
> Mr. Adams, please be aware that others have different perspectives.
> I'll present one, in some detail, because I think it might be useful
> at this point in the conversation.
>
> I believe your advice immediately above refers to <URL:http://
> www.dejanews.com/thread/443315365/>. You propose several changes
> in Tcl's syntax, and several people reply (and others reply to them,
> for a total of ten messages in the thread). As I read the thread,
> it didn't occur to me that anyone "stomped on" you in any personal
> sense. I'd guess there's a strong consensus that your recommenda-
> tions are ill-advised or inappropriate, as you've presented them,
> but I didn't notice that anyone criticized the *idea* of making sug-
> gestions about Tcl's future, impugned you personally, or did
> anything else that would make me feel "stomped on".
>
> I suspect some cultural dissonance here.
[snip]
Someone obviously found some 'cultural dissonance' in my use of
the enigmatic smiley ":-|" :-).
At the end of the day we are all, I hope, working towards similar ends.
i.e. helping each other to make better use of our chosen languages
and helping to push forward their development.
Bruce.
Bruce S. O. Adams
Jeff Gosnell wrote:
> Ok, now that I've read all about the comment problem in Tcl I've become
> somewhat confused. What exactly does the # do?
> When I took a Tcl/Tk class at college my teacher instructed us to put
> #!usr/bin/tcl
> at the very top of every program. I thought that odd. I still don't know
> why.
> While I am working on my current project (using straight Tcl/Tk) I found an
> interesting little fact. When typing commands in a -command {args} area the
> compiler didn't like comments in the args area. I thought it a little
> annoying but happily took them out to make the button (or whatever) work.
> So I refer to my question at the top, "What exactly does the pound do?"
> Thanks
> Jeff Gosnell
Strings like:
#!/bin/sh
on the very first line of a file are called magic numbers. They are a unixism.
Much as
a binary string at the start of a binary file may identify it (e.g. CAFEBABE in
hex for Java)
these tell a UNIX type OS the location of an appropriate program to run to
interpret a shell
script.
For portability to UNIX, it is recommended (unless someone knows better :-)
that you start
tclsh files with:
#!/bin/sh
# \
exec tclsh "$0" "$@"
TCL uses hashes (# - I hope you see a hash here and not a pound :-) as comments
and allows
them to be continued on the next line, by escaping the newline. However, other
UNIX interpreters
such as the (almost) standard /bin/sh do not allow hash comment continuation in
this way. Hence,
the exec call is interpreted only by /bin/sh and not by TCL. This tells the OS
to look for a tclsh
interpreter on the path. The downside is the overhead of an additional process
invocation.
Just to confuse things more #'s in TCL are treated as null commands, with
the exception that
they don't need to be followed by spaces. They can also be used as arguments.
By the way, excuse me for being pedantic but the sign is a hash sign a pound
is completely
different. The confusion is probably down to countries and keyboards though
you'd think
international standards would prevent that :-)
Just for reference, excuse me if this appears patronising, it is
unintentional :-
Hash = * * Pound = ŁŁ
***** Ł Ł
* * ŁŁŁ
***** Ł
* * ŁŁŁŁŁŁ
Bruce A.
Dan Curtiss
> By the way, excuse me for being pedantic but the sign is a hash sign a pound
> is completely
> different. The confusion is probably down to countries and keyboards though
it's real name is 'octothorp'.
Hume Smith
>I think that I have got to the root of the problem. I have been using
>the Python interactive shell and have been pasting samples of code into
>it and they have not been working, however when I put the same pieces of
>code into a file and run them under Python then they work.
>
>Therefore those people who have been saying "what whitespace problem"
>probably never use the Python interactive shell.
>
>It is a shame that programs which are syntactically correct when run
>from a file are not when run interactively but I guess that is something
>the Pythoneers live with.
they do work the same (but using python interactively is a bloody
nuisance, like using csh to program is a bloody nuisance :). the problem is
your copy-n-paste; the spacing is mangled somewhere.
>Also I have just had a look at some of the python modules that are
>installed on my machine and found that there are very few (hardly any
>at all) blank lines in the middle of function definitions. Obviously the
>Python (Guido's ?) programming style is not to add blank lines in the
>code therefore they never cause any problems.
blank lines are harmless; i have lots of blank lines in my blocks.
Hume Smith
>This is obviously because when running a program from a file blank lines
>(or lines which just contain whitespace) are ignored but the Python
>interactive shell uses a blank line to terminate the command.
oh, whoops, yes, that's true (i didn't connect blank lines and interactive
mode) - and this newsreader has no cancel or i'd take back my other reply.
Hume Smith
> By the way, excuse me for being pedantic but the sign is a hash sign a pound
>is completely
>different.
no; he's using "pound" in weight not money. what some people abbreviate "lb."
and i've also seen it called "octothorpe" but i have no idea why...
Hume Smith
>This is probably why you are having a problem inside of -command {...}.
>If you do:
>
> button .b -text "Hello" -command {# Setting Status; set status 1}
>
>the status variable will never get set since everything from the "#" to the end of the
>line is a comment. You may also get an interpreter error as well.
no interpreter error. and you have to be careful commenting on the *end* of a
-command too; i've deliberately used
scale .s -command {foo ;#}
to ignore the tacked-on argument.
> Changing the above
to:
> button .b -text "Hello" -command {
> # Setting Status
> set status 1
> }
or
button .b -text Hello -command "# Setting Status\nset status 1"
:)
Tim Peters
> I do not know how difficult it would be to try and track down an
> incorrect indentation problem as I have not really used Python in anger.
You run Python with the -t switch; it checks lines for ambiguous indentation
and yells at you when it finds one. I used it once to verify it worked
<wink -- but, yes, I'm another for whom leading whitespace has never been a
problem>. The std tool tabnanny.py does much the same in batch mode across
a directory tree. I've used that a lot; but only because I wrote it and
needed to test it before release <0.5 wink>.
> ...
> The fact that the Python interactive shell has a different rule for
> handling blank lines than the Python interpreter is regrettable but
> probably unavoidable.
> ...
> I think that I have got to the root of the problem. I have been using
> the Python interactive shell and have been pasting samples of code into
> it and they have not been working, however when I put the same pieces of
> code into a file and run them under Python then they work.
Ah! So don't do that <wink>.
> Therefore those people who have been saying "what whitespace
> problem" probably never use the Python interactive shell.
People generally don't try to paste blocks of code into the interactive
shell. Use the "execfile" cmd instead; much like Tcl's "source".
wondering-what-kind-of-programmer-spends-his-day-pasting-code-
fragments-into-shells<wink>-ly y'rs - tim
Heribert Dahms
: In comp.lang.python DUPERVAL, LAURENT <laurent....@bellsygma.com> wrote:
: > #!/bin/sh
: > # Start interpreter \
: > exec tclsh8.0 "$0" "$@"
exec tclsh8.0 "$0" ${1+"$@"}
is known to work with empty and quoted args
under all sort of sh variants.
: Uhm, why not use the standard (afaik) idiom? :
:
: #!/usr/bin/env <insert-favorite-interpreter-here>
:
: and then get the command-line arguments using (in Python)
: sys.argv or getopts...
Standard? That's the first time I've seen such a usage of env in years
of working under Unix! And isn't this subject to the "32 char limit"?
Bye, Heribert (da...@ifk20.mach.uni-karlsruhe.de)
Terry Reedy
pdu...@mailserver.hursley.ibm.com says...
>This is obviously because when running a program from a file blank lines
>(or lines which just contain whitespace) are ignored but the Python
>interactive shell uses a blank line to terminate the command.
True.
>The fact that the Python interactive shell has a different rule for
>handling blank lines than the Python interpreter is regrettable but
>probably unavoidable.
Probably true. It is somewhat of a nuisance, but see below.
In article <919392652....@news.glinx.com>,
hcls...@glinx.delete-this.com says...
>they do work the same ... the problem is
>your copy-n-paste; the spacing is mangled somewhere.
No, Duffin is right about this one difference in behaviour.
>(but using python interactively is a bloody
> nuisance, like using csh to program is a bloody nuisance :).
I love using interactive Python and being able to get feedback seconds after
I write each little code unit. I use it as follows (on Win95):
1. Start console window. Make it full screen. Some binaries (at least older
ones compiled with MSC++, but not DOS-extension versions with WatcomC)
require fast paste disabled in last properties tab.
2. Start eidtor -- even NotePad. Make part screen -- full width, top low
enough to expose paste button on Python window.
3. Write a few lines of code. Cut and then paste into Python. View results.
Type non-keeper one-liners directly into Python. Cut results that want to
keep and paste back into editor or third window with results file.
Repeat 2 and 3 as desired.
When cutting code from newsgroup or other files for interactive use, I use
same setup to delete '>'s and within-block blank lines.
Terry J. Reedy
Tim Peters
> I love using interactive Python and being able to get feedback
> seconds after I write each little code unit.
Terry, you're OK <wink>.
> I use it as follows (on Win95):
>
> 1. Start console window. Make it full screen. ...
> 2. Start eidtor -- even NotePad. Make part screen -- full width, top low
> enough to expose paste button on Python window.
> 3. Write a few lines of code. Cut and then paste into Python.
> View results.
> Type non-keeper one-liners directly into Python. Cut results
> that want to keep and paste back into editor or third window with
> results file.
> Repeat 2 and 3 as desired.
Terry, you're insane <wink>. If you don't use the PythonWin console window,
at least give Guido's IDLE a try! Then it's more like:
1. Start IDLE.
2. Have fun -- intelligent interactive command-line retrieval, recall and
edit of multi-line statements, builtin word completion, scrollable record of
your entire session, auto-indent, syntax coloring, stronger builtin editor
than Notepad, one click on a traceback line brings up the offender in an
editor, ...
another-few-years-and-it-might-be-half-as-pleasant-as-pymode<wink>-ly
'rs - tim
Dave LeBlanc
strange little things that always land with one point up and are
strewn on the road to puncture tires.
A lot of people don't know that there are standard names specified in
the ASCII spec(s) for characters. "/' is a syncope and "\" a reverse
syncope I believe.. and I don't know why they're called that either.
How's that for triva?
Dave LeBlanc
Pete Forman
Justin> Ivan Van Laningham <iva...@callware.com> writes:
>> 'Cause env lives in different places on different unices. ...
Justin> It does?
Justin> Everywhere that I've ever seen it has had it at
Justin> /usr/bin/env. Do you have an example of an UNIX-like OS
Justin> that has env but doesn't have it in that location?
Justin> (Some also have it in /bin, but that can be ignored.)
Interactive Unix 4.0 (aka ISC).
$ ls /bin/e* /usr/bin/e*
/bin/echo
/bin/ed
/bin/env
/bin/expr
/usr/bin/edit
/usr/bin/egrep
/usr/bin/enable
/usr/bin/ex
--
Pete Forman This .sig is Y2K compliant
Western Geophysical 19 Februark 1999
pete....@westgeo.com
lvi...@cas.org
According to Frank Niessink <frankn=ne...@cs.vu.nl>:
:In comp.lang.python DUPERVAL, LAURENT <laurent....@bellsygma.com> wrote:
:> #!/bin/sh
:> # Start interpreter \
:> exec tclsh8.0 "$0" "$@"
:Uhm, why not use the standard (afaik) idiom? :
:
:#!/usr/bin/env <insert-favorite-interpreter-here>
Because a) it's an idiom that many of us have never seen and
b) because it requires a program called env to be in a directory called
/usr/bin - whereas the first requires a program called sh to be in a directory
called /bin. The latter has been, to date, a more common idiom.
However, comp.lang.tcl readers, certainly the env idiom works for
tcl on Solaris 2.6.
Perhaps someone can offer concerns or caveats from a security, reliability,
etc. point of view.
--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Donal K. Fellows
Roy Terry <royt...@earthlink.net> wrote:
> I guess that hair splitting works for you. For me If the comment is
> not "invisible to the parser" its not a comment its some
> no-mans-land entity. Do such entities exist in any other common
> languages?
Tcl comments *are* invisible to the parser, but the rules for starting
one are much stricter than in other languages. # only has special
meaning when it is the leading character of a command. The body of a
proc is not a command, but instead a string that later gets
interpreted as a string of commands (and that is when the comments are
stripped.)
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
--
"And remember, evidence is nothing." - Stacy Strock <sp...@adisfwb.com>
Hume Smith
>It has 8 points (octo = 8). A calinthrope has 5 I think..
"thrope" or "thorpe"? i remembered "thorpe", the puzzle to me being why octo
and not nono. "thrope" isn't in my dictionary, but it's only small.
>A lot of people don't know that there are standard names specified in
>the ASCII spec(s) for characters. "/' is a syncope and "\" a reverse
>syncope I believe.. and I don't know why they're called that either.
i've also seen "solidus" for /; something to do with the use in
pound/shilling/pence notation. we seem to have gone full circle now :) (or
was it derived of those old big long Ss used to abbr. shilling? geeze,
i've gotta write these things down...)
Hume Smith
>: Uhm, why not use the standard (afaik) idiom? :
>: #!/usr/bin/env <insert-favorite-interpreter-here>
>Standard? That's the first time I've seen such a usage of env in years
>of working under Unix!
gee - i've been seeing it fairly often lately, and i don't get out much :) i
thought it was clever, seeing as it would work for just about any interpreter.
> And isn't this subject to the "32 char limit"?
not too badly -
#!/usr/bin/env tclsh8.0
is only 24 (counting newline).
Christopher Nelson
>
> Bruce S. O. Adams wrote:
> > By the way, excuse me for being pedantic but the sign is a hash sign a pound
> > is completely
>
> it's real name is 'octothorp'.
I *love* that name. I've always felt that # was a number sign or "hash" or
"mesh". Calling it "pound" grates on my nerves.
How about other obscure names for common characters like circumflex for ^. / is
virgule (or something like that) isn't it? Is there a better name for | than
"pipe"?
Chris
P.S. I once had a trainer from the south say that * was "spu-LAY-at" (splat,
with three syllables). ;-)
--
Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!
Christopher Nelson
>
> On Thu, 18 Feb 1999, Bruce S. O. Adams wrote:
>
> > By the way, excuse me for being pedantic but the sign is a hash sign a pound
> >is completely
> >different.
>
>
"octo" - eight. There are eight points. "thorpe" - something to do with horns,
I think.
Chris
Christopher Nelson
>
> It has 8 points (octo = 8). A calinthrope
I always thought this was "calitrop" but I can't find either at
http://www.dict.org/bin/Dict.
> has 5 I think.. they are
> strange little things that always land with one point up and are
> strewn on the road to puncture tires.
Actually, as I understand it, the original use was to puncture horses hooves --
they were medieval weapons used against knights and later cavalry.
> A lot of people don't know that there are standard names specified in
> the ASCII spec(s) for characters. "/' is a syncope and "\" a reverse
> syncope I believe.. and I don't know why they're called that either.
>
> How's that for triva?
Trivial. ;-)
Evan Simpson
(thanks!):
2. (Mil.) An instrument with four iron points, so disposed
that, any three of them being on the ground, the other
projects upward. They are scattered on the ground where an
enemy's cavalry are to pass, to impede their progress by
endangering the horses' feet.
Christopher Nelson wrote in message <36CDAB32...@pinebush.com>...
>I always thought this was "calitrop" but I can't find either at
>http://www.dict.org/bin/Dict.
Mmmm... horses' feet
Evan Simpson
Michael T. Richter
>That's because they're called "caltrops". From the nice dictionary URL
>(thanks!):
> 2. (Mil.) An instrument with four iron points, so disposed
> that, any three of them being on the ground, the other
> projects upward. They are scattered on the ground where an
> enemy's cavalry are to pass, to impede their progress by
> endangering the horses' feet.
You can do a "poor man's caltrop" by taking a standard potato and sticking
nails into it in all directions. Throw a few of these on a road and watch
the tires get shredded. :-)
Robert Severson
I hate to do this, but...
Shredded tires leads to shredded potatos which is hash (or "hash
browns") which gets us back to where we were.
Any *comments*? (*that* pun *was* intended ;-> )
By the way, I described the key sequence of !20 to someone as "Bang
twenty". He said "Bang? Don't you mean screech?"
Ivan Van Laningham
Christopher Nelson wrote:
>
> Dave LeBlanc wrote:
> >
> > It has 8 points (octo = 8). A calinthrope
>
> I always thought this was "calitrop" but I can't find either at
> http://www.dict.org/bin/Dict.
>
Try ``caltrop'':
From Webster's Revised Unabridged Dictionary (1913) :
Caltrop \Cal"trop\, Caltrap \Cal"trap\, n. [OE. calketrappe,
calletrappe, caltor (in both senses), fr. AS. collr[ae]ppe,
calcetreppe, sort of thistle; cf. F. chaussetrape star
thistle, trap, It. calcatreppo, calcatreppolo, star thistle.
Perh. from L. calx heel + the same word as E. trap. See 1st
Trap.]
1. (Bot.) A genus of herbaceous plants ({Tribulus) of the
order Zygophylle[ae], having a hard several-celled
fruit, armed with stout spines, and resembling the
military instrument of the same name. The species grow in
warm countries, and are often very annoying to cattle.
2. (Mil.) An instrument with four iron points, so disposed
that, any three of them being on the ground, the other
projects upward. They are scattered on the ground where an
enemy's cavalry are to pass, to impede their progress by
endangering the horses' feet.
Also used in Jackie Chan movies;-)
> > has 5 I think.. they are
> > strange little things that always land with one point up and are
> > strewn on the road to puncture tires.
>
> Actually, as I understand it, the original use was to puncture horses hooves --
> they were medieval weapons used against knights and later cavalry.
>
> > A lot of people don't know that there are standard names specified in
> > the ASCII spec(s) for characters. "/' is a syncope and "\" a reverse
> > syncope I believe.. and I don't know why they're called that either.
> >
> > How's that for triva?
>
> Trivial. ;-)
>
> Chris
> --
> Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!
<never-play-jacks-with-caltrops>-ly y'rs,
Ivan
----------------------------------------------
Ivan Van Laningham
Callware Technologies, Inc.
iva...@callware.com
http://www.pauahtun.org
See also:
http://www.foretec.com/python/workshops/1998-11/proceedings.html
----------------------------------------------
Bruce S. O. Adams
Robert Severson wrote:
> "Michael T. Richter" wrote:
> >
> > Evan Simpson wrote in message ...
> > >That's because they're called "caltrops". From the nice dictionary URL
> > >(thanks!):
> > > 2. (Mil.) An instrument with four iron points, so disposed
> > > that, any three of them being on the ground, the other
> > > projects upward. They are scattered on the ground where an
> > > enemy's cavalry are to pass, to impede their progress by
> > > endangering the horses' feet.
> >
> > You can do a "poor man's caltrop" by taking a standard potato and sticking
> > nails into it in all directions. Throw a few of these on a road and watch
> > the tires get shredded. :-)
>
> I hate to do this, but...
>
> Shredded tires leads to shredded potatos which is hash (or "hash
> browns") which gets us back to where we were.
>
> Any *comments*? (*that* pun *was* intended ;-> )
>
> By the way, I described the key sequence of !20 to someone as "Bang
> twenty". He said "Bang? Don't you mean screech?"
Or even shriek. :-)
I am quite depressed to note, that of my posts to comp.lang.tcl of late, which
have
I thought raised a few valid points. The biggest response is when I get
pedantic a complain
that someone called a lousy octothrop (hash = #) a pound sign.
*sigh*
I'm off down the pub to see if I can learn some better communication skills!
Christopher Nelson
>
> > By the way, I described the key sequence of !20 to someone as "Bang
> > twenty". He said "Bang? Don't you mean screech?"
When my daughter was 2yo, she had a shirt covered in exclamation points. Since
"exclamation" was too big a word to fit in her mouth, it became her "bang
shirt". ;-)
Garry Hodgson
>
> Bryan Oakley wrote:
> > Python has a lot going for it. I would consider it
> > myself except for the fact I absolutely can't deal with using whitespace
>
> I find that difficult too (although I am sure that I could manage if I
> tried).
i'm always a bit surprised by this kind of comment.
i guess this is one of those "love it or hate it" kinds of things.
a lot of people are put off at first. i was, briefly.
but once i started using python, i quickly developed an
absolute intolerance for noise characters like ;{}$@
when i look at code, i want to see the ideas, not the
cruft the parser relies on to do its job.
i'd guess you already indent your code. i'd guess you are
more or less self-consistent with your indentation. i'd guess
that i could look at your code and infer its block structure
from that indentation. so can python.
so why add the noise?
--
Garry Hodgson comes a time
ga...@sage.att.com when the blind man
Software Innovation Services takes your hand, says,
AT&T Labs "don't you see?"
Terje Kvernes
> i'm always a bit surprised by this kind of comment.
> i guess this is one of those "love it or hate it" kinds of things.
> a lot of people are put off at first. i was, briefly.
> but once i started using python, i quickly developed an
> absolute intolerance for noise characters like ;{}$@
> when i look at code, i want to see the ideas, not the
> cruft the parser relies on to do its job.
Well, to me it's much like how some people see lisp. All those
()()()((()))'s =). But when you've written some lisp you just don't
notice it, and the times you do, it clears up something, it doesn't
baffle you.
But I guess that's enough perl/lisp comparison for one decade.
When I read perl-code I react to @<whatever> and think 'oh, an array,
okay...'. But hey, I live with "noise", and I live without.
Go figure. =)
--
Terje - Pressing towards midnight in Norway.
Bernhard Herzog
Christopher Nelson <ch...@pinebush.com> writes:
> Dan Curtiss wrote:
> >
> > Bruce S. O. Adams wrote:
> > > By the way, excuse me for being pedantic but the sign is a hash sign a pound
> > > is completely
> > > different. The confusion is probably down to countries and keyboards though
> >
> > it's real name is 'octothorp'.
>
> I *love* that name. I've always felt that # was a number sign or "hash" or
> "mesh". Calling it "pound" grates on my nerves.
A common German name for that character is 'Doppelkreuz'. The 'obvious'
translation of that name, 'double-cross', introduces a completely new
meaning that the German word doesn't have.
It seems, however, that this meaning is not altogether inappropriate,
given the way # may sneak up on you in TCL.
--
Bernhard Herzog | Sketch, a python based drawing program
her...@online.de | http://www.online.de/home/sketch/
Brian V. Smith
|> By the way, excuse me for being pedantic but the sign is a hash sign a pound
|> is completely
|> different. The confusion is probably down to countries and keyboards though
|> you'd think
|> international standards would prevent that :-)
You're confusing the monetary pound with pounds avoirdupois, which, at least in
the U.S. was represented by the # sign (e.g., 6# for $1), hence the name "pound sign".
--
--------------------------------------------------------
Brian V. Smith (bvs...@lbl.gov) http://www-epb.lbl.gov/BVSmith
Lawrence Berkeley National Laboratory
I don't speak for LBL; they don't pay me enough for that.
Check out the xfig site at http://www-epb.lbl.gov/xfig
Bryan Oakley
>
> Paul Duffin wrote:
> >
> > Bryan Oakley wrote:
> > > Python has a lot going for it. I would consider it
> > > myself except for the fact I absolutely can't deal with using whitespace
> >
> > I find that difficult too (although I am sure that I could manage if I
> > tried).
>
> i guess this is one of those "love it or hate it" kinds of things.
Almost certainly.
> a lot of people are put off at first. i was, briefly.
> but once i started using python, i quickly developed an
> absolute intolerance for noise characters like ;{}$@
> when i look at code, i want to see the ideas, not the
> cruft the parser relies on to do its job.
>
> i'd guess you already indent your code. i'd guess you are
> more or less self-consistent with your indentation. i'd guess
> that i could look at your code and infer its block structure
> from that indentation. so can python.
Yes, I already indent my code. Well, actually, emacs indents it for me.
>
> so why add the noise?
I guess I'm just old-fashioned. It seems to make things more explicit,
much like declaring variables in languages that don't explicitly require
you to do so. It just removes potential ambiguity.
That's not to say that's the right way or the wrong way. Perhaps Python
is the way all languages ought to be, but it's not the way I like to
work. So, I choose to use languages that more closely fit my "style" of
programming. I also encourage others to do so as well -- no one language
will ever be right for everyone.
--
Bryan Oakley mailto:oak...@channelpoint.com
ChannelPoint, Inc. http://purl.oclc.org/net/oakley
Dave LeBlanc
One person's noise is another's delight.
If we all liked the same things, we'd all be fighting for them instead
of enjoying a bit of diversity. I personally prefer blue eyed
brunettes to blondes, classical music over grunge, coffee instead of
tea and tcl over perl (as if that wasn't a no-brainer <ducking>) ;-)
</soapbox>
Dave LeBlanc
On Fri, 19 Feb 1999 22:09:43 GMT, Garry Hodgson <ga...@sage.att.com>
wrote:
>Paul Duffin wrote:
>>
>> Bryan Oakley wrote:
>> > Python has a lot going for it. I would consider it
>> > myself except for the fact I absolutely can't deal with using whitespace
>>
>> I find that difficult too (although I am sure that I could manage if I
>> tried).
>
>i'm always a bit surprised by this kind of comment.
>i guess this is one of those "love it or hate it" kinds of things.
>a lot of people are put off at first. i was, briefly.
>but once i started using python, i quickly developed an
>absolute intolerance for noise characters like ;{}$@
>when i look at code, i want to see the ideas, not the
>cruft the parser relies on to do its job.
>
>i'd guess you already indent your code. i'd guess you are
>more or less self-consistent with your indentation. i'd guess
>that i could look at your code and infer its block structure
>from that indentation. so can python.
>
>so why add the noise?
>
frank...@my-dejanews.com
> [Skip]
> > I'm not usually a "me too" kind of person,
> [Tim Peters]
> Well, I am, and-- damn it --I haven't had any problems with whitespace
> either. So there.
Now that Tim had his coming out, I have to confess I'm definitely a
"me too" kind of person, too..
I found Python's way never to collide with my intuition, the only thing I
could find fault with is that you're not allowed to do arbitrary indentation
(say with a semantic background), for example:
[...]
P()
f1()
# Some more code, indented to remember that V() still has to be called
V()
[...]
(P and V can be read as aquire/release any resource.)
Stefan
PS: Did you ever had to code something in OCCAM? That was a kind of symbolic
assembler for transputers disguised as a structured programming language. It
was my first contact with the indentation=structure idea and a real torture
(without a syntax-aware editor) - indentation limited to exactly two spaces.
Of course, no ws problems ever, but a constantly nagging compiler.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Justin Sheehy
> People generally don't try to paste blocks of code into the interactive
> shell. Use the "execfile" cmd instead; much like Tcl's "source".
Hm. Perhaps I'm not fully enough assimilated into the Python Way yet.
I do this a lot. Not with my own code; for that I use the python-mode
ability to exec a region. However, if someone else sends a snippet of
code to me via Usenet, mail, a MOO, etc., then my first reacton is to
mouse-paste it from that window into a python interpreter.
This often fails and is rather annoying. It is in my opinion a bug in Python.
-Justin
Will Rose
: Paul Duffin wrote:
: >
: > Bryan Oakley wrote:
: > > Python has a lot going for it. I would consider it
: > > myself except for the fact I absolutely can't deal with using whitespace
: >
: > I find that difficult too (although I am sure that I could manage if I
: > tried).
: i'm always a bit surprised by this kind of comment.
: i guess this is one of those "love it or hate it" kinds of things.
: a lot of people are put off at first. i was, briefly.
: but once i started using python, i quickly developed an
: absolute intolerance for noise characters like ;{}$@
: when i look at code, i want to see the ideas, not the
: cruft the parser relies on to do its job.
: i'd guess you already indent your code. i'd guess you are
: more or less self-consistent with your indentation. i'd guess
: that i could look at your code and infer its block structure
: from that indentation. so can python.
: so why add the noise?
The answer is in your posting. You use no indentation, no capitals,
nothing to assist the eye in parsing sentences. Obviously for you
that is enough for you and many others, but other people like
redundancy, and hence use indentation _and_ block markers.
And it's a lot easier to recover C code that's had its whitespace
messed up than it is Python code; all the C code I get is run through
a standard formatter and comes out look if not pretty, at least
standard. I wouldn't care to do that with Python code; messed up
spacing is a rewrite job.
Justin Sheehy
> I do this a lot. Not with my own code; for that I use the python-mode
> ability to exec a region. However, if someone else sends a snippet of
> code to me via Usenet, mail, a MOO, etc., then my first reacton is to
> mouse-paste it from that window into a python interpreter.
>
> This often fails and is rather annoying.
Yep, I'm following up to myself. I decided that calling this a 'bug'
is perhaps a bit harsh, as I can't quickly think of a better or more
appropriate/intuitive way for Python to behave in interactive mode.
I know I hate it when someone tells me something that I've done is
wrong and doesn't suggest what would be better, so I'll retract my
statement of that form. :-)
It is still annoying, though, and a bit of a pain to work around. I
just don't know what the right fix or workaround is, other than "don't
do that".
-Justin
Tim Peters
> ...
> I do this a lot. Not with my own code; for that I use the python-mode
> ability to exec a region. However, if someone else sends a snippet of
> into a python interpreter.
>
> This often fails and is rather annoying.
> I just don't know what the right fix or workaround is, other than
> "don't do that".
Sounds like you're about 3 keystrokes removed from pasting it into an Emacs
buffer instead and exec'ing the region -- same as you'd do for your own
code.
shedding-giant-crocodile-tears<wink>-ly y'rs - tim
Hrvoje Niksic
> shedding-giant-crocodile-tears<wink>-ly y'rs - tim
Why?
(Resisted temptation to write curious-ly y'rs or something:>).
Jeff Bauer
>> shedding-giant-crocodile-tears<wink>-ly y'rs - tim
> Why?
> (Resisted temptation to write curious-ly y'rs or something:>).
Hrvoje,
The phrase may be an English/American colloquialism. It
refers to the myth of a crocodile's eye ducts appearing
to be shedding tears while it devours it victim. An
insincere show of grief, not to be confused with pity.
Not that anyone would accuse the Tim-bot of failing to
make a sincere attempt at sincerity.
Best regards,
Jeff Bauer
Rubicon, Inc.
Tim Peters
other peoples' code into an interactive shell by executing it from an
Emacs buffer instead, as he long ago figured out how to do for his own
code]
> shedding-giant-crocodile-tears<wink>-ly y'rs - tim
[Hrvoje Niksic]
> Why?
If Jeff's explanation of "crocodile tears" didn't take hold (thanks, Jeff!),
it's because Justin's intractable problem with pasting other peoples' code
into an interactive shell could be "fixed" by pasting it into, and executing
it from, an Emacs buffer instead -- as he long ago figured out how to do for
his own code.
> (Resisted temptation to write curious-ly y'rs or something:>).
You can't fight the temptation forever, Hrvoje <wink>.
tauntingly y'rs - tim
Tim Peters
> ...
> I found Python's way never to collide with my intuition, the only thing I
> could find fault with is that you're not allowed to do arbitrary
> indentation (say with a semantic background), for example:
>
> [...]
> P()
> f1()
> # Some more code, indented to remember that V() still has to be called
> V()
> [...]
>
> (P and V can be read as aquire/release any resource.)
Na, in the spirit of Stupid Workarounds,
__ = None
[...]
P()
__; f1()
__; print x
__; etc
V()
What? That sucks? Ya, so does your mother <wink>. I'm more likely to code
it as
[...]
P()
try:
f1()
print x
etc
finally:
V()
Else it's too easy to forget the "close bracket" resource function on one
path or another. If the resource is acquired and released at function
boundaries, a decent alternative is to acquire it in a class constructor,
release it in the destructor, and rely on refcounting to trigger the
destructor as soon as the function exits. Like
class PV:
def __init__(self):
P()
def __del__(self):
V()
def f():
p = PV()
blah blah blah
return 6
In both cases you end up releasing the resource even if you exit via an
exception, which is usually appropriately defensive programming.
Still, I've occasionally tortured Guido in pvt with visions of a
user-defined block construct, that could encapsulate this pattern more
pleasantly. Like
"with" name ["(" optional_args ")"]:
do stuff
translating into (suggestive, not rigorous):
name.__with__(1, optional_args)
try:
do stuff
finally:
name.__with__(0, optional_args)
Perhaps
with synchronized(bpusher):
b.append(a.pop())
or
with IEEE(ROUND.TO_ZERO):
x = x * y
or
with pen(color="blue"):
text.write("red")
or
class NoReasonBlock:
def __with__(*args): pass
indenting = NoReasonBlock()
with indenting:
print "I just wanted to indent this"
would be reasonable uses.
some-days-i-fear-python2-may-make-c++-look-slim-ly y'rs - tim
Donal K. Fellows
DUPERVAL, LAURENT <laurent....@bellsygma.com> wrote:
> On MS operating systems (MSOSs), in order for the system to know what to
> do with a file, you have to give it a specific extension. In the old
> days, there were 3 executable extensions: .com, .exe and .bat. .com and
> .exe were for binary programs (and I think .COM files had to be smaller
> than 64K or not use more than one 64K segment for data and executable
> code). .BAT files were to be interpreded by the command interpreter
> (COMMAND.COM or, if you were bright/lucky 4DOS.COM and possibly DR-DOS).
> In Windows, this was extended to associate a given extension with a
> program. So now, if you have a file with a registered extension, just
> typing that name on the command line or double-clicking it withtin the
> Explorer starts the correct application to interpret that file. That's
> fine and dandy, but what happens, for example if you have a file with no
> extension? What do you do? In Windows you always have to specify what
> program to use to interpret a file with no extension (you can't register
> an empty extension).
IIRC, what happened on MSDOG was a little bit more subtle than that.
There was no distinction made by the shell (AKA COMMAND.COM) between
the .EXE and .COM extensions - it just interpreted them both as
meaning "pass this filename to the exec syscall" and the exec syscall
itself paid no attention to what the file was called (other than to
locate the code in the FS) and read the first few bytes of the file to
figure out what to do with it (if it started "MZ" then it was a
relocatable executable which needed its link addresses patching up
according to a table elsewhere in the header, and it was a
work-anywhere .COM-type otherwise - the relocatabiliity of those files
depended on the 8086 segmentation architecture...)
This meant that you could write and build .EXEs, and then call them
.COMs and put them in places where you could override parts of the
operating system in order to compromise the security for everyone
without modifying any existing files. Yuck!
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
--
"And remember, evidence is nothing." - Stacy Strock <sp...@adisfwb.com>
Duncan Booth
<000601be5e3f$9a1b8d00$4e9e2299@tim>:
>def f():
> p = PV()
> blah blah blah
> return 6
>
>In both cases you end up releasing the resource even if you exit via
>an
>exception, which is usually appropriately defensive programming.
Doesn't the class based method of resource allocation fall down if an
exception is thrown? I would think the resource will remain claimed until
the traceback object is destroyed, which might be longer than you expect.
Or have I missed something obvious here?
--
Duncan Booth
dun...@dales.rmplc.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://dales.rmplc.co.uk/Duncan
Donal K. Fellows
Brian V. Smith <env...@epb1.lbl.gov> wrote:
> You're confusing the monetary pound with pounds avoirdupois, which,
> at least in the U.S. was represented by the # sign (e.g., 6# for
> $1), hence the name "pound sign".
The problem is that in the UK, the name "pound sign" is universally
understood to be referring to the symbol '£' (\u00a3) and I imagine
that this is also the case in many other uses too (throughout the
metric-using world and on the financial markets especially.) Of
course, on many earlier UK ASCII keyboards, the '#' was replaced by
the '£' (they generated the same symbol) and this caused problems
(especially when writing C when trying to learn from books and
printouts) for a long time.
If you say "pound-shriek" I think of the opening of my wallet long
before I think of "#!"
Peter.DeRijk
: Paul Duffin wrote:
: >
: > Bryan Oakley wrote:
: > > Python has a lot going for it. I would consider it
: > > myself except for the fact I absolutely can't deal with using whitespace
: >
: > I find that difficult too (although I am sure that I could manage if I
: > tried).
: i'm always a bit surprised by this kind of comment.
: i guess this is one of those "love it or hate it" kinds of things.
: a lot of people are put off at first. i was, briefly.
: but once i started using python, i quickly developed an
: absolute intolerance for noise characters like ;{}$@
: when i look at code, i want to see the ideas, not the
: cruft the parser relies on to do its job.
: i'd guess you already indent your code. i'd guess you are
: more or less self-consistent with your indentation. i'd guess
: that i could look at your code and infer its block structure
: from that indentation. so can python.
: so why add the noise?
When comparing Tcl/python/perl, python using indentation only
to indicate the block structure was its greatest turnoff for me.
Over the years, my code has traveled alot to different OSes, hardware
and editor, and I have often lost indentation in the process. Using the
{}, this was easy to restore ...
--
Peter De Rijk der...@uia.ua.ac.be
<a href="http://rrna.uia.ac.be/~peter/personal/peter.html">Peter</a>
To achieve the impossible, one must think the absurd.
to look where everyone else has looked, but to see what no one else has seen.
Paul Duffin
>
> Paul Duffin wrote:
> >
> > Bryan Oakley wrote:
> > > Python has a lot going for it. I would consider it
> > > myself except for the fact I absolutely can't deal with using whitespace
> >
> > I find that difficult too (although I am sure that I could manage if I
> > tried).
>
> i'm always a bit surprised by this kind of comment.
> i guess this is one of those "love it or hate it" kinds of things.
> a lot of people are put off at first. i was, briefly.
> but once i started using python, i quickly developed an
> absolute intolerance for noise characters like ;{}$@
> when i look at code, i want to see the ideas, not the
> cruft the parser relies on to do its job.
>
> i'd guess you already indent your code. i'd guess you are
> more or less self-consistent with your indentation. i'd guess
> that i could look at your code and infer its block structure
> from that indentation. so can python.
>
> so why add the noise?
>
One advantage of the noise is that interactive Tcl and non-interactive
Tcl have the same syntax whereas interactive Python and non-interactive
Python treat blank lines differently and so have different syntax.
Python programs with indentation removed are ambiguous.
--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880
Fredrik Lundh
>One advantage of the noise is that interactive Tcl and non-interactive
>Tcl have the same syntax whereas interactive Python and non-interactive
>Python treat blank lines differently and so have different syntax.
quite misleading, that one.
there is no such thing as an "interactive python syntax".
the command line interface provided by the standard
interpreter treats empty lines as end of statement (or
end of file, to be precise). other tools are free to use
other conventions, and some do.
/F
Philip
>In article <7akoe0$9...@overload.lbl.gov>,
>Brian V. Smith <env...@epb1.lbl.gov> wrote:
>> You're confusing the monetary pound with pounds avoirdupois, which,
>> at least in the U.S. was represented by the # sign (e.g., 6# for
>> $1), hence the name "pound sign".
>
>The problem is that in the UK, the name "pound sign" is universally
>understood to be referring to the symbol '£' (\u00a3) and I imagine
>that this is also the case in many other uses too (throughout the
>metric-using world and on the financial markets especially.) Of
>course, on many earlier UK ASCII keyboards, the '#' was replaced by
>the '£' (they generated the same symbol) and this caused problems
>(especially when writing C when trying to learn from books and
>printouts) for a long time.
>
>If you say "pound-shriek" I think of the opening of my wallet long
>before I think of "#!"
>
>Donal.
In Chinese it's called the well symbol, as it resembles the glyph symbolizing
a well.
Andrew Cooke
der...@uia-nospam.ua.ac.be wrote:
> When comparing Tcl/python/perl, python using indentation only
> to indicate the block structure was its greatest turnoff for me.
> Over the years, my code has traveled alot to different OSes, hardware
> and editor, and I have often lost indentation in the process. Using the
> {}, this was easy to restore ...
This is getting a bit tedious, but...
I was similarly suspicious of the indentation when I started using
Python a few months ago. However, assuming a good editor (emacs), it
rapidly becomes so simple and obvious that I can only presume it's one
of those things you don't believe til you do it.
Andrew
Hrvoje Niksic
> If Jeff's explanation of "crocodile tears" didn't take hold (thanks,
> Jeff!), it's because Justin's intractable problem with pasting other
> peoples' code into an interactive shell could be "fixed" by pasting
> it into, and executing it from, an Emacs buffer instead -- as he
> long ago figured out how to do for his own code.
Sure, but not everyone uses Emacs (I do, but I'm another matter
entirely.)
> > (Resisted temptation to write curious-ly y'rs or something:>).
>
> You can't fight the temptation forever, Hrvoje <wink>.
but-of-course-i-can-ly... oops! ^U
Justin Sheehy
> Sounds like you're about 3 keystrokes removed from pasting it into an Emacs
> buffer instead and exec'ing the region -- same as you'd do for your own
> code.
Right. That works fine for me, as I always have an emacs frame around.
However, I suspect that I'm not the only person who has been bitten by
the fact that python's interactive interface treats blank lines
differently than they are treated in scripts. A number of those
people probably don't use emacs, and thus don't have a good alternative.
I view that behavior as a very obnoxious side effect of Python's
indentation-is-structure philosophy. I don't see a good solution for
it in the general case, unfortunately.
-Justin
Garry Hodgson
>
> Garry Hodgson (ga...@sage.att.com) wrote:
> : so why add the noise?
>
> The answer is in your posting. You use no indentation, no capitals,
> nothing to assist the eye in parsing sentences.
apples and oranges. my (email) writing style and coding style are
separate and distinct. besides, indentation was not warranted in my
post.
paragraph breaks were, and were present. capitalization, not so much.
in email, i tend not to capitalize. where conventions differ, i do.
> And it's a lot easier to recover C code that's had its whitespace
> messed up than it is Python code; all the C code I get is run through
> a standard formatter and comes out look if not pretty, at least
> standard. I wouldn't care to do that with Python code; messed up
> spacing is a rewrite job.
good point. let's see, how many times in the last few years have
i needed to do this...uh...oh yeah, zero.
Donn Cave
|Tim Peters <tim...@email.msn.com> wrote:
|> def f():
|> p = PV()
|> blah blah blah
|> return 6
|>
|> In both cases you end up releasing the resource even if you exit via
|> an
|> exception, which is usually appropriately defensive programming.
|
| Doesn't the class based method of resource allocation fall down if an
| exception is thrown? I would think the resource will remain claimed until
| the traceback object is destroyed, which might be longer than you expect.
I don't know the current thinking on this, but you may have missed some of
the general disclaimers I've seen about finalization and reference counting.
In today's C Python, you may be able to work around the exception problem
with a "sys.exc_traceback = None", at critical points in the program.
For me, anyway, this works well enough that the reference count based object
lifetime is still very useful.
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
Hrvoje Niksic
this:
if 1:
print "hi"
print "hey"
This works as a script perfectly, but if I enter it at the >>> prompt,
it says:
File "<stdin>", line 3
print "hey"
^
SyntaxError: invalid syntax
I cannot find invalid syntax there. If I enter an empty line between
`print "hi"' and `print "hey"', it works. To me, that looks like a
bug.
Will Ware
: I was similarly suspicious of the indentation when I started using
: Python a few months ago. However, assuming a good editor (emacs), it
: rapidly becomes so simple and obvious that I can only presume it's one
: of those things you don't believe til you do it.
I like Python's use of indentation, but I can see where it could give
maintenance problems. If code goes thru a filter that messes up the
indentation, it might be difficult or impossible to get it right again.
Indentation decisions can be automatic for C (hence the possibility of
utilities like "indent") but they represent human judgement in Python.
The only time I've actually really been bitten on this is with some
mailing-list-archiving software that HTML-formats messages, which isn't
Python-aware. I also worry a bit about the relationship between spaces
and tabs; I think Emacs's Python mode handles this by using spaces for
everything.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Will Ware email: wware[at]world[dot]std[dot]com
PGP fp (new key 07/15/97) 67683AE2 173FE781 A0D99636 0EAE6117
cliff
> I like Python's use of indentation, but I can see where it could give
> maintenance problems. If code goes thru a filter that messes up the
> indentation, it might be difficult or impossible to get it right again.
> Indentation decisions can be automatic for C (hence the possibility of
> utilities like "indent") but they represent human judgement in Python.
> The only time I've actually really been bitten on this is with some
> mailing-list-archiving software that HTML-formats messages, which isn't
> Python-aware. I also worry a bit about the relationship between spaces
> and tabs; I think Emacs's Python mode handles this by using spaces for
> everything.
Here's an idea, which doesn't use block delimiters:
for x in big_ol_list:
. print x,
. blah_blah
. if time_to_do_something:
. . do_something
. . etc
. else:
. . etc_etc
. and_then_do_even_more_stuff
I got this idea from an obscure trick I used to do to simulate
indentation
in Commodore 64 Basic. The Commodore's interpreter didn't preserve
whitespace
at the beginnings of lines, so I would put the appropriate number of
colons
(':' being the statement seperator) instead. This didn't affect my
program
any, except possibly to make it a little slower, since the interpreter
saw
all these colons as just a bunch of null statements; but at the same
time it
forced the LIST command to properly indent my code because it didn't
know any
better and thought it had to print all those colons out.
Obviously a single . in Python doesn't have any meaning; the parser
would
have to be modified to ignore periods delimited by whitespace.
This probably looks pretty ugly to a lot of you; I used periods to
minimize
their impact on the whitespace, and I think it's still pretty readable.
It
should be able to survive things like HTML filters which compress all
whitespace too. I really don't see any other way to solve this problem,
without using block delimiters (ick yuck bleah)
this-is-my-first-time-posting-so-please-be-gentle-ly yr's,
Cliff
---
Cliff Crawford cjc26#at#cornell#dot#edu
http://www.people.cornell.edu/pages/cjc26/
Tim Peters
pasting it into a shell]
[Hrvoje Niksic]
> Sure, but not everyone uses Emacs
Justin does, and I was replying to him.
> (I do, but I'm another matter entirely.)
So now we have two people complaining about a problem they don't have
<wink>? If someone who actually did have a problem complained about it, I
might suggest pasting the code into an IDLE window & hitting F5. But what
about those whose religion forbids installing Tk? Well, God helps those who
help themselves <0.5 wink>.
>>> (Resisted temptation to write curious-ly y'rs or something:>).
>> You can't fight the temptation forever, Hrvoje <wink>.
> but-of-course-i-can-ly... oops! ^U
watch-out-it's-addicting-warning-ly y'rs - tim
Tim Peters
> Doesn't the class based method of resource allocation fall down if an
> exception is thrown?
"fall down" depends on how much you want from it; you're certainly right
that you can't count on immediate destruction of locals when an exception is
thrown out of (or even just through) a function:
> I would think the resource will remain claimed until the traceback
> object is destroyed, which might be longer than you expect.
Right, and the try/finally way doesn't get entangled with those kinds of
surprises.
> Or have I missed something obvious here?
I'm not sure, unless it's a simple proof of Fermat's Last Theorem.
but-if-so-you're-in-good-company-ly y'rs - tim
Alexandre Ferrieux
>
> I'm not sure, unless it's a simple proof of Fermat's Last Theorem.
>
-Alex
Paul Duffin
Obviously the python interactive shell does not just use blank lines to
end code blocks it requires it. I think that you are correct that this
is a bug because it should be / is possible for python to behave
'correctly' in this case. Needing a blank line (or something else) to
let python know that the code block has finished is not a bug but rather
a consequence of the nature of the python grammar.
Paul Duffin
>
> On Mon, 15 Feb 1999, Paul Duffin wrote:
>
> > What was the error message ? Something like
> > list element in braces followed by "'." instead of space
> >
> > That is the message that you get if you add the comment to a switch statement.
> > Anyone who knows about Tcl should know this idiosyncracy of Tcl.
> Let's say it this way: Most languages treat comments exactly as what they
> are named: comments and nothing more.
> I've never been biten by this, I've noticed this crazyness when reading my
> first Tcl book :), but it's reasonable to expect that a language treats
> something that basic like all other languages :)
>
Tcl is not like other languages ;-).
> > > > Tcl has now joined Perl in my own little internal hell for
> > > > tools which have wasted so much of my time with their arcane
> > > > quirks that they can never be forgiven.
> > > >
> >
> > That is a shame.
> Not really. Tcl is quite a perfect language :) for programs
> -) that are shorter than 5-10 lines of code,
> AND
> -) that are throwaway.
>
Oooh, if that is your experience maybe it says more about you than the
language 8-O.
> Perl users at least have the excuse that Perl is relativly fast.
>
I do not know what version of Tcl you have had experience of but Tcl is
fast too.
> > Really, I found that Python was much worse when it comes to error
> > messages than Tcl.
> >
> > e.g.
> > Python 1.5.2b1 (#5, Feb 11 1999, 09:50:43) [C] on aix4
> > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > >>> if
> > File "<stdin>", line 1
> > if
> > ^
> > SyntaxError: invalid syntax
> What's wrong here: It's invalid syntax, and it points to the correct
> place.
>
It tells you that something is wrong here but it does not tell you what.
The Tcl example tells you that you need an expression next. I did try
quite a lot of examples and rarely did I see anything else apart from
SyntaxError: invalid syntax. I would have though that "invalid syntax"
was implied by "SyntaxError". I would have liked to see
SyntaxError: missing expression
Even C has better error messages than this.
"main.c", line 4.1: 1506-276 (S) Syntax error: possible missing '('?
> > I think that everyone would agree that at least in this simple case
> > Tcl beats Python hands down.
> But it doesn't beat it at parsing: The error messages are created in Tcl
> by the seperate commands (if,for,while). In Python, as the syntax is
> caught by a parser. I know, it's an alien concept to Tcl, but it's the
> state of the art in compiler building *g*
>
Actually I think that you will find that that error message is generated
by the Tcl parser, yes surprise surprise we do have one. I would not say
that the Python parser is state of the art if it cannot distinguish
between different types of syntax error. The thing which distinguishes
one parser from another in my view is how they handle errors, not how
they handle valid syntax.
> > One of the things that I really liked about Tcl was that the error
> > messages were so helpful, I actually learnt an awful lot by typing
> > in commands and letting Tcl tell me what the problem was.
> Sounds awful like someone describing Windows programming and how not to do
> it. Experimenting with a language/library without perusing documentation
> is a sure way incorrect programs. How do you know that your code will work
> in the general case? (And not just now, because your TCP/IP is only
> loopback, ...) To know that, you need to read the documentation.
>
Actually I think that people learn a lot more by doing than by reading.
Yes documentation is useful for guiding what you learn about and as a
reference but you have to do to learn.
Even now I still type in a command with missing parameters because I
know that Tcl will tell me how to complete it.
> >
> > > > And i can trust Python to never ever do anything as horrid as
> > > > breaking a script of mine because of the contents of comment.
> >
> > No, but a Python program will break if you happen to remove
> > some whitespace, or have the whitespace in the wrong place, or
> Than you are using the wrong editor. Have been programming Python for 3-4
> years now, and never ever had I a problem with my Emacs w/PythonMode ;)
>
Not everyone has Emacs (although I do), if you are satisfied that the
solution to the language problem is to use an editor then fine.
> > Have you never been hit by a whitespace problem that took ages
> > to track down ? I would be very surprised if you had not.
> There are no such problems. At least not if you use a good editor.
>
> > How do you copy example code from web pages and emails, I tried
> > to cut and paste but the white space on blank lines was lost so
> > it failed with thousands of horrible errors.
> You think while you paste code.
You mean that you have to do it a bit at a time ? Sounds inefficient to
me.
> >
> > I was extremely surprised when I found that Python is so reliant
> > on correct use of whitespace, I though that it was a modern
> What does this have to do with a modern language?
> <asbesto-wear>
Just that we seem to have moved away from rigid formats for programming
languages to freer ones, e.g. away from punched cards ;-).
> Do you think it's modern to use a shell interpreter level syntax?
>
I am not saying that Tcl is necessarily 'modern', as far as I know Tcl
is older than Python.
> Do you think having an Middle-Age mindset when designing a language?
> (Just read some papers of Ousterhout. Many of his premises remind me of
> the middle ages: No, the sun goes around the earth, cannot be the other
> way. There are only scripting languages (actually there is only one
> scripting language, Tcl), and system languages, ...)
>
> </asbesto-wear>
>
I never said that I agree with JO and in fact he probably doesn't agree
with some of the things he has said in the past either, we all move on.
> > language but obviously I was wrong.
> It's reliant on correct indention, not correct white space usage.
> And it is so, to force more readable programs. Ok, I've admit it: I've
> hated it in the first week.
Maybe you can tell me how does Python handle indentation with mixed
tabs and spaces ? Is a tab == 1 space or 8 spaces or 3 spaces, what.
> >
> > > > It's just part of the Python philosophy -- Guido wouldn't _do_
> >
> > See comments on whitespace.
> >
> > > > that to me! Ousterhout and Wall, much as i admire them each in
> > > > various ways, _would_ inflict that kind of surprise on me, so
> > > > in self-preservation i seek to avoid their tricky, spring-
> > > > loaded tools...)
> > > >
> >
> > We must each realise our own limitations.
> Exactly :) That's why there are classes like Software Eng.
> There you learn that after correctness, the single most important point
> about software is maintainibilty of code.
>
> And at this point, we got Tcl == Hell 10th level down, Perl == Hell 6th
> level down, and Python 1-2th level down.
>
> (Python has some feature that lead to maintaince headaches, but these are
> not the question of basic syntax and readability of code. :) )
>
Some languages make it easier to write good code, some make it harder
but at the end of the day it comes down to you.
Both Python and Tcl (and all the others) are constantly being 'improved'
to our 'benefit' so we should make sure that we do not become so biased
against a language that we never look at it again. (I did hear that one
thing Guido did regret was relying on indentation, maybe he will add
some {} just for me :-)).
> > Apologies if I have offended anyone, I have just had a bad day.
> Same for me :)
>
> Andreas
> --
> Win95: n., A huge annoying boot virus that causes random spontaneous system
> crashes, usually just before saving a massive project. Easily cured by
> UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
And Win NT.
Andreas Eggenschwiler
> I like Python's use of indentation, but I can see where it could give
> maintenance problems. If code goes thru a filter that messes up the
> indentation, it might be difficult or impossible to get it right again.
I completely agree with you. If python code goes thru a filter that
messes the syntax up, the syntax is messed up afterwards. I am not
so familiar with tcl, how does tcl recover from filters that mess
tcl's syntax up?
F'up
--
Res