![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 04/20/10 03:52, Warp wrote:
> Why is it idiotic? Because whitespace is the one thing which gets most
> easily and regularly lost in communication.
>
> For example, someone might ask some question about Python in a forum or
> blog post, and then someone might answer it with some Python code... and
> the blog/forum software removes whitespaces from the beginning of lines,
> completely changing the meaning of the program and making it inoperable.
> There are also many other situations where whitespaces at the beginning
> of lines might not be preserved (or might be changed somehow).
You know, for all the complaints people have about Python's whitespace,
not once in all the years of coding Python has it been an issue for me.
Well, OK - occasionally had issues with people mixing tabs with spaces,
but then I learned to use a proper editor.<G>
Know how often I've had issues compiling because of a missing brace or
semicolon? Orders of magnitude more frequently than whitespace issues in
Python.
Once I had spent just a short amount of time in the Python world, I
really hated semicolons in whatever other language I was coding in. A
royal pain to have to enter a mostly pointless character after each
statement.
Most online forums have a [code] tag or something similar to ensure
nothing gets formatted. Otherwise, use a pasting service.
> Also autoindentation of Python code is a physical impossibility.
Why would this be a concern?
> The person who thought that it's a good idea to have indentation as
> block delimiters should be shot.
Shoot me while you're at it, too ;-)
Python's the only whitespace sensitive language I've dealt with where
it wasn't an issue.
--
Growing old is mandatory; growing up is optional!!
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 04/20/10 04:15, nemesis wrote:
> Warp escreveu:
>> For example, someone might ask some question about Python in a forum or
>> blog post, and then someone might answer it with some Python code... and
>> *the blog/forum software removes whitespaces* from the beginning of
>> lines,
>> completely changing the meaning of the program and making it inoperable.
>
> well, at least you recognize it's not Python's fault. ;)
POTD.
--
Growing old is mandatory; growing up is optional!!
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Neeum Zawan <m.n### [at] ieee org> wrote:
> Well, OK - occasionally had issues with people mixing tabs with spaces,
> but then I learned to use a proper editor.<G>
How does the Python interpreter/compiler even work with different types of
whitespace? If, for example, one line as 4 spaces at the beginning and the
next line has one tab character (which many editors will show as wide as
8 spaces, and in fact some editors will convert groups of 8 spaces into
tabs), how does the interpreter interpret that? And what happens if you
change the tab width in your editor settings?
I bet it can become pretty confusing when the interpreter is giving you
error messages or, much worse, it will parse ok but run complately wrongly,
even though it *looks* to be ok.
Relying on the use of whitespace for actual syntax is idiotic (with the
exception of separating tokens with at least one whitespace character,
while not being important how many).
> Know how often I've had issues compiling because of a missing brace or
> semicolon? Orders of magnitude more frequently than whitespace issues in
> Python.
I'm not concerned about typos. I'm concerned about whitespaces being lost
in transfer and different types of whitespace (spaces, different types of
tab characters..) being interpreted differently by different programs (the
text editor might be showing you something completely different than what
the Python interpreter is seeing).
Whitespace at the beginning of lines should be purely aesthetical, not
integral part of the syntax.
> Once I had spent just a short amount of time in the Python world, I
> really hated semicolons in whatever other language I was coding in. A
> royal pain to have to enter a mostly pointless character after each
> statement.
You seem to assume that statements never get longer than a certain length,
so that they will all nicely fit in one line. Sometimes it's useful to be
able to split statements into several lines.
> Most online forums have a [code] tag or something similar to ensure
> nothing gets formatted.
Except that many don't.
> Otherwise, use a pasting service.
Why should I have to use such things just because the language has a
braindead idea of using whitespace as syntax?
> > Also autoindentation of Python code is a physical impossibility.
> Why would this be a concern?
Because when your editor can autoindent your code, it makes programming
enormously easier (similarly to how syntax highlighting does).
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
discussion : 4bce01c9$1@news.povray.org...
> On 04/20/10 03:52, Warp wrote:
> Know how often I've had issues compiling because of a missing brace or
> semicolon? Orders of magnitude more frequently than whitespace issues in
> Python.
Same experience here. I guess that's because it's easier to miss a semicolon
or a brace in PHP than a whitespace in Python. I had to program in Python
for a few days last year. At first I had the same WTF reaction as Warp about
indentation but I found it much less error-prone in that respect than PHP. I
like PHP, but its unability to cope with missing stuff is a time sink, as it
outputs anything from a blank page to hebrew (unexpected
T_PAAMAYIM_NEKUDOTAYIM).
G.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Also autoindentation of Python code is a physical impossibility.
No it's not. Replacing indentation in python once the dedents have been
lost is problematic. But that's like complaining if you delete all the
closing braces in C then you can't figure out where to put them back.
But making all the indents a consistent amount? Pretty easy.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gilles Tran escreveu:
> I like PHP, but its unability to cope with
> missing stuff is a time sink, as it outputs anything from a blank page
> to hebrew (unexpected T_PAAMAYIM_NEKUDOTAYIM).
LOL
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> How does the Python interpreter/compiler even work with different types of
> whitespace?
I'm pretty sure most compilers complain if you mix tabs and spaces in the
same source file, at least at the beginning of lines. Pick one, stick with it.
> I bet it can become pretty confusing when the interpreter is giving you
> error messages or, much worse, it will parse ok but run complately wrongly,
> even though it *looks* to be ok.
nah. If you put tabs and spaces at the start of the line in the same source
file, you get an error message and you need to figure out why you're doing that.
> Relying on the use of whitespace for actual syntax is idiotic (with the
> exception of separating tokens with at least one whitespace character,
> while not being important how many).
I think distinguishing newline from other whitespace is reasonable.
> I'm not concerned about typos. I'm concerned about whitespaces being lost
> in transfer
Well, don't do that. :-) Treat python source code as something other than
prose, and you won't have that problem.
Really, if you're not using unicode, you're already behind the ball. So if
your transfer mechanism can't handle whitespace, you shouldn't be using it
to ship code around.
> You seem to assume that statements never get longer than a certain length,
> so that they will all nicely fit in one line. Sometimes it's useful to be
> able to split statements into several lines.
You don't need special characters to do this in most line-oriented
languages. Python, for example, happily continues the statement on the next
line if the current line isn't finished.
x = 27 +
15
is all one statement.
>> Otherwise, use a pasting service.
>
> Why should I have to use such things just because the language has a
> braindead idea of using whitespace as syntax?
The same reason you need to if your posting service has a braindead idea
about HTML-special tags. Why in the world would you use a language where <
and > are significant characters, when every web service out there might
corrupt them??
> Because when your editor can autoindent your code, it makes programming
> enormously easier (similarly to how syntax highlighting does).
Python editors auto-indent code. I'm not sure what you mean. An indent
always follows a line ending with a colon, and the dedent is no harder than
your closing brace in C.
--
Darren New, San Diego CA, USA (PST)
Linux: Now bringing the quality and usability of
open source desktop apps to your personal electronics.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> How does the Python interpreter/compiler even work with different types of
> whitespace? If, for example, one line as 4 spaces at the beginning and the
> next line has one tab character?
I don't know about Python. In Haskell, any file containing a single tab
character is immediately rejected (since tabs don't have any
standardised width). If you're coding in Haskell, you're just not
allowed to use tabs *at all*.
> Relying on the use of whitespace for actual syntax is idiotic (with the
> exception of separating tokens with at least one whitespace character,
> while not being important how many).
Actually it's pretty logical. You might argue that requiring the
programmer to manually type a semicolon at the end of each line when
it's obvious that each line is a seperate statement is illogical.
> I'm not concerned about typos. I'm concerned about whitespaces being lost
> in transfer and different types of whitespace.
The only real problem with using whitespace is that it tends to get
mangled in emails, forum posts, etc. This isn't a problem when you're
writing programs. This is *only* a problem if you try to post code
snippets on forums and so forth. (And yes, it's kind of irritating.)
> You seem to assume that statements never get longer than a certain length,
> so that they will all nicely fit in one line. Sometimes it's useful to be
> able to split statements into several lines.
I have no idea how Python works. What I do know is that Haskell is quite
sensible about this. If you have, say, an if/then/else expression, you
can write it all on one line, or on three seperate lines, or maybe on
even more lines than that. Hell, if you want to, you can write an entire
Haskell program on one line; whitespace is *optional*, and you can use
it the way you want to use it, provided that a few simple rules are
followed. It's really not that difficult.
>>> Also autoindentation of Python code is a physical impossibility.
Depends. I don't know Python's syntax rules. Haskell uses whitespace,
and it should be possible to autoindent it. (I'm not aware of any editor
which does it, but then I'm not aware of any editor which knows what the
hell Haskell is...)
>> Why would this be a concern?
>
> Because when your editor can autoindent your code, it makes programming
> enormously easier (similarly to how syntax highlighting does).
And to think that I do all my programming with an editor which doesn't
give me syntax hilighting *or* automatic indentation...
(Then again, I've yet to see an editor with auto-indent which actually
indents stuff the way that *I* want it to, rather than the way the guy
who wrote the editor wants it to.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> > I'm not concerned about typos. I'm concerned about whitespaces being lost
> > in transfer
> Well, don't do that. :-) Treat python source code as something other than
> prose, and you won't have that problem.
Too bad that online forums and blogs won't.
> Really, if you're not using unicode, you're already behind the ball. So if
> your transfer mechanism can't handle whitespace, you shouldn't be using it
> to ship code around.
Tell that to all the forum and blog software out there.
> > Because when your editor can autoindent your code, it makes programming
> > enormously easier (similarly to how syntax highlighting does).
> Python editors auto-indent code. I'm not sure what you mean. An indent
> always follows a line ending with a colon, and the dedent is no harder than
> your closing brace in C.
Autoindentation is impossible for a program to do because it cannot know
where the block should end, as there is no keyword/character ending the block.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> > Relying on the use of whitespace for actual syntax is idiotic (with the
> > exception of separating tokens with at least one whitespace character,
> > while not being important how many).
> Actually it's pretty logical. You might argue that requiring the
> programmer to manually type a semicolon at the end of each line when
> it's obvious that each line is a seperate statement is illogical.
You don't type a semicolon at the end of each line. You type it at the
end of each statement. There may be more than one statement in a line, or
a statement may be split into several lines, and for example function
definitions are not ended with a semicolon.
Anyways, semicolons are seldom lost when you post a response to an online
blog post.
> > I'm not concerned about typos. I'm concerned about whitespaces being lost
> > in transfer and different types of whitespace.
> The only real problem with using whitespace is that it tends to get
> mangled in emails, forum posts, etc. This isn't a problem when you're
> writing programs. This is *only* a problem if you try to post code
> snippets on forums and so forth. (And yes, it's kind of irritating.)
Some editors also might convert spaces at the beginning of lines to tabs
(or the other way around) if you are not careful with the settings. This
doesn't really matter with normal programming languages.
> >> Why would this be a concern?
> >
> > Because when your editor can autoindent your code, it makes programming
> > enormously easier (similarly to how syntax highlighting does).
> And to think that I do all my programming with an editor which doesn't
> give me syntax hilighting *or* automatic indentation...
Why? Try some editor which is able to color your code, use it for a few
weeks, and you'll never switch back.
It naturally depends on the specific language, but with some languages
syntax highlighting and autoindentation actually help to catch typos as
you are writing your code. For example, if emacs starts autoindenting in
a completely crazy way, I immediately know that there's a typo somewhere
(maybe a missing curly bracket or semicolon). Likewise if the code gets
colored completely wrongly (for example if you forget to close a string).
Not that this happens often, but when it does, it's a great help.
> (Then again, I've yet to see an editor with auto-indent which actually
> indents stuff the way that *I* want it to, rather than the way the guy
> who wrote the editor wants it to.)
In many advanced editors you can configure how the autoindentation works.
For example emacs has quite a lot of configuration options. (Of course that
doesn't mean it's *easy* to configure.)
It's just really handy when a line is wrongly indented, I just press tab
(regardless of where the cursor is on that line currently, and regardless
of whether the line was indented too much or too little), and emacs indents
it just like I want.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |