![](/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) |
Darren New <dne### [at] san rr com> wrote:
> If existing lines are indented incorrectly, then your code is broken. The
> reason that "auto indenting" is not possible in Python is the same reason
> that "auto bracing" isn't possible in C.
Actually, I can't think why "auto-bracing" wouldn't be possible in C,
at least if you don't mind having braces even around single-statement blocks
(something which many programming guides actually recommend).
Every time you write a statement which is followed by a code block (even
if it's an empty one in rare cases), such as a for-loop, the editor could
automatically add the '{' and '}' characters and indent the code such that
you can just keep typing the contents of the loop. (The only think which
would slightly interrupt the flow would be that when you end writing the
code block you need to exit it by pressing the down cursor a couple of
times...)
Hmm, maybe I'll try to make emacs do exactly that. At least by binding
that functionality to some key...
A lesser variation of that would be that every time you write a '{' the
editor automatically adds (and indents) a '}'. The editor could actually
constantly keep matching braces auto-indented, even if one of the pair is
changed somehow (most editors, including emacs, can highlight matching
braces, so it shouldn't be a problem to auto-indent them as well).
--
- 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) |
Warp wrote:
> nemesis <nam### [at] gmail com> wrote:
>> http://www.itworld.com/government/105031/will-wall-street-require-python
>
> Python must have the most idiotic block delimiter in the history of
> programming languages: Whitespace indentation.
>
> 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).
>
> Also autoindentation of Python code is a physical impossibility.
>
> The person who thought that it's a good idea to have indentation as
> block delimiters should be shot.
>
So you are saying that the programming language is no good unless it
allows production code to be floated around on blogs?
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) |
Jim Charter <jrc### [at] msn com> wrote:
> So you are saying that the programming language is no good unless it
> allows production code to be floated around on blogs?
No, I'm saying that using whitespace as syntax is a bad idea.
--
- 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) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> If existing lines are indented incorrectly, then your code is broken. The
>> reason that "auto indenting" is not possible in Python is the same reason
>> that "auto bracing" isn't possible in C.
>
> Actually, I can't think why "auto-bracing" wouldn't be possible in C,
> at least if you don't mind having braces even around single-statement blocks
> (something which many programming guides actually recommend).
This is why: Take all the braces out of a C program. Now put them back in
the right place. That's what you're asking.
Distinguish between "indent Python not knowing how much it should be
indented" and "indent changing python when the program is already correctly
indented so far."
Your editor can indent when necessary, and unindent with a keystroke, as you
type. This is the equivalent of your "you write a statement which is
followed by a code block" statement. Cut and paste can automatically put
things as the right indent level (with a python-aware editor, of course). Etc.
Statements that should be aligned that aren't can be fixed. If you have four
lines under your "if" with slightly varying indents but all indented
relative to the "if", then this is trivial to fix. (Python might already be
happy with that one, actually.)
The only failure is when you have something that should be indented relative
to a line above it somewhere but it isn't. This is precisely analogous to
having the wrong number of closing braces. Asking for this to be fixed
automatically is identical to asking for C code with too many closing braces
to get fixed automatically. You can't do it, because you don't know how
indented it is *supposed* to be, just like you don't know which closing
brace is the one that ought be removed. (I'm sure you've encountered this
at least once. :-)
Indeed, I wouldn't be surprised if it was trivial to program a python editor
that } at the start of a line translates to a dedent. :-)
> Every time you write a statement which is followed by a code block (even
> if it's an empty one in rare cases), such as a for-loop, the editor could
> automatically add the '{' and '}' characters and indent the code such that
> you can just keep typing the contents of the loop.
Lots of HTML editors do this too.
> A lesser variation of that would be that every time you write a '{' the
> editor automatically adds (and indents) a '}'. The editor could actually
> constantly keep matching braces auto-indented, even if one of the pair is
> changed somehow (most editors, including emacs, can highlight matching
> braces, so it shouldn't be a problem to auto-indent them as well).
Yep. Visual Studio does this.
Python doesn't need to. ;-)
--
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:
> Jim Charter <jrc### [at] msn com> wrote:
>> So you are saying that the programming language is no good unless it
>> allows production code to be floated around on blogs?
>
> No, I'm saying that using whitespace as syntax is a bad idea.
So is lower case letters, because EBCDIC doesn't support that. :-)
--
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) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > Jim Charter <jrc### [at] msn com> wrote:
> >> So you are saying that the programming language is no good unless it
> >> allows production code to be floated around on blogs?
> >
> > No, I'm saying that using whitespace as syntax is a bad idea.
> So is lower case letters, because EBCDIC doesn't support that. :-)
Yeah, I see how EBCDIC is as popular as html.
(Besides, EBCDIC does support lowercase letters.)
--
- 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) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > Jim Charter <jrc### [at] msn com> wrote:
> >> So you are saying that the programming language is no good unless it
> >> allows production code to be floated around on blogs?
> >
> > No, I'm saying that using whitespace as syntax is a bad idea.
>
> So is lower case letters, because EBCDIC doesn't support that. :-)
>
> --
> Darren New, San Diego CA, USA (PST)
> Linux: Now bringing the quality and usability of
> open source desktop apps to your personal electronics.
Actually EBCDIC does support lower case.
a thru i is x'81' to x'89'
j thru r is x'91' to x'99'
s thru z is x'a2' to x'a9'
I once had a case where I had to deal with lower case numbers.
0 thru 9 were encoded as x'b0' to x'b9'
To change to uppercase just 'or' with a blank (x'40').
To change uppercase to lowercase xor with x'bf'
There is even a valid card punch for lower case letters.
An a is a 12-0-1 punch,
A b is a 12-0-2 punch,
etc.
Isaac
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) |
>>> Plus, as you're typing the arguments, it gives you help for each
>>> argument.
>>>
>>> I.e., so you know whether it's radians or degrees expected.
>>
>> Or find out what the hell the order of the argument is...
>
> Yep. Even better than type signatures, when you have three floats in a row.
Yeah, that one's fun. Haskellers tend to define aliases or new types
quite a lot. For example, Filepath is an alias to String, but
writeFile :: Filepath -> String -> IO ()
is more illuminating than just
writeFile :: String -> String -> IO ()
Even so, you do still find type signatures where it's not really obvious
what's what without some real documentation.
The *other* problem is that Haskell libraries tend not to be very
documented. :-(
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
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 wrote:
> Invisible wrote:
>> As documented, VS doesn't indent things the way *I* like. ;-)
>
> Did you ever adjust it to your liking? There's a bunch of knobs to
> tweak, you know.
When last I looked at it, no amount of combinations would make it behave
the way I wanted. Maybe it's improved since then...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
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) |
Clarence1898 wrote:
> Actually EBCDIC does support lower case.
> a thru i is x'81' to x'89'
> j thru r is x'91' to x'99'
> s thru z is x'a2' to x'a9'
Why...why do you know this? o_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |