I restore the redundancy by ...
This might [...] the human reader but the redundancy really needs to be supported by the language.
if condition:
foo()
bar()
baz()
if one needs to re-arrange the order of operations, for reasons, and one
is incautious about selecting and shuffling lines in one's editor, such
that one ends up with this:
if condition:
bar()
foo()
baz()
On Mon, 26 Aug 2024 21:35:25 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
I restore the redundancy by using ?#end? comments. E.g. a seriously
nontrivial case:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in tab/space factor between $EDITOR and the Python RTE, which is a truly ridiculous thing to have to be concerned about.
(Thing I'm curious about, but don't have a test environment to hand -
does a blank line with a different indent level, in between lines of
the same level, break out of the block? E.g., given the following:
if condition:
foo()
bar()
baz()
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in tab/space factor between $EDITOR and the Python RTE, which is a truly ridiculous thing to have to be concerned about.
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I’ve simply
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it’s a form of experience that must have built up very quickly.
As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
(In contrast C’s rules have occasionally been a practical problem, contributing to at least one high-profile software vulnerability and attracting compiler warnings to mitigate the risks.)
On 27/08/2024 09:39, Richard Kettlewell wrote:
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issuesIn many years of using Python routinely and extensively I’ve simply
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it’s a form of experience that must have built up very quickly.
As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
(In contrast C’s rules have occasionally been a practical problem,
contributing to at least one high-profile software vulnerability and
attracting compiler warnings to mitigate the risks.)
These are the problems I've seen. I haven't used the language
extensively, but I've used it enough.
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block. And, also the block then merges with the
following one as it's at the same level, so when you want to change it back...
(5) Sometimes you want to temporarily comment out the contents of a
block. But Python doesn't allow an empty block; now you have to use
'pass'. And then get rid of if later.
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
On 27/08/2024 09:39, Richard Kettlewell wrote:
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I’ve simply
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it’s a form of experience that must have built up very quickly.
As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
(In contrast C’s rules have occasionally been a practical problem,
contributing to at least one high-profile software vulnerability and
attracting compiler warnings to mitigate the risks.)
These are the problems I've seen. I haven't used the language
extensively, but I've used it enough.
(1) An tab at the start of a line gets accidentally indented or
unindented. If you weren't paying close attention, it may not be clear
that that has happened, if this line was either the last line of an
indented block, or the line following
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block. And, also the block then merges with the
following one as it's at the same level, so when you want to change it back...
(3) Similarly, you want to temportarily wrap an 'if' statement, for
example, around a block of code. But you can't do it witout indenting
that block.
(4) Sometimes you want to add temporary debug code as part of a block. Usually I write such lines in all-caps and without indentation to make
them stand out clear. With Python, I can't use all-caps and I have to
use exactly the same indent as the rest of the block. So the lines
merge. Then when I need to remove the code, it's not clearly delimited.
(5) Sometimes you want to temporarily comment out the contents of a
block. But Python doesn't allow an empty block; now you have to use
'pass'. And then get rid of if later.
(6) You want to add extra statements to the end of a block, but where IS
the end? You have to INFER the ending by looking for a line with a
smaller indent. But suppose you're at the bottom of a window; is that
bottom line the last in the block, or is there another one at the same indent just out of sight? You have to tentatively keep peeking ahead!
(6a) And maybe there's big comment blocking in the middle of block;
comments don't need nesting! If there are lots of comments and few statements, finding the end of the block (ie. the last statement of this block) can become quite an exercise.
(7) You take some Python code you've seen online (eg. in a usenet post)
and paste into your editor. Maybe you want to merge it with your own code.
But its tabbing is all spaces; yours is all tabs. Plus invariably, the
whole thing has extra indentation (eg. the leftmost statement is already indented). Or you want to copy code from within a block to a different indent level.
The whole thing gets very messy and error prone. You need special editor commands to deal with the mess.
Indented, non-delimited code and data is fine for machine-generated and machine processed code. But it's a disaster for code that has to be human-generated and human-maintained. It's just too fragile.
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
On 27/08/2024 12:26, Bart wrote:
On 27/08/2024 09:39, Richard Kettlewell wrote:
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues >>>> of the interpreter potentially mis-parsing things due to mismatches in >>>> tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I’ve simply
never found the whitespace issues that people are worrying about here to >>> be a problem in practice. Some of this may be a matter of experience but >>> if so, it’s a form of experience that must have built up very quickly. >>>
I have occasionally, but only occasionally, seen problems with white space. And those would normally be caught by Python 3.
As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
(In contrast C’s rules have occasionally been a practical problem,
contributing to at least one high-profile software vulnerability and
attracting compiler warnings to mitigate the risks.)
These are the problems I've seen. I haven't used the language
extensively, but I've used it enough.
Your problems below are all valid, but not insurmountable. I too would rather have explicit block delimiters, but it's not actually hard to
work with Python as it is.
(1) An tab at the start of a line gets accidentally indented or
unindented. If you weren't paying close attention, it may not be clear
that that has happened, if this line was either the last line of an
indented block, or the line following
That /can/ happen. It is a good idea to avoid mixing tabs and spaces in the same file. Most editors can be configured one way or the other, but
if you use different editors under different circumstances (as I do), mistakes are possible. They are usually quickly identified and quickly handled.
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block. And, also the block then merges with the
following one as it's at the same level, so when you want to change it
back...
Replace your
if cond :
with
if 1 :
or
if True :
(3) Similarly, you want to temportarily wrap an 'if' statement, for
example, around a block of code. But you can't do it witout indenting
that block.
True. But any editor will let you select the lines and indent them.
(4) Sometimes you want to add temporary debug code as part of a block.
Usually I write such lines in all-caps and without indentation to make
them stand out clear. With Python, I can't use all-caps and I have to
use exactly the same indent as the rest of the block. So the lines
merge. Then when I need to remove the code, it's not clearly delimited.
Comments are an extremely easy way to make the code stand out.
(5) Sometimes you want to temporarily comment out the contents of a
block. But Python doesn't allow an empty block; now you have to use
'pass'. And then get rid of if later.
You can leave the "pass" in, if you don't want to get ride of it later.
I sometimes find "pass" to be helpful as an alternative to leaving a
hanging indented block.
(6) You want to add extra statements to the end of a block, but where
IS the end? You have to INFER the ending by looking for a line with a
smaller indent. But suppose you're at the bottom of a window; is that
bottom line the last in the block, or is there another one at the same
indent just out of sight? You have to tentatively keep peeking ahead!
Keep your blocks small and neat.
(6a) And maybe there's big comment blocking in the middle of block;
comments don't need nesting! If there are lots of comments and few
statements, finding the end of the block (ie. the last statement of
this block) can become quite an exercise.
That applies to every programming language (unless you know of one that doesn't support comments).
(7) You take some Python code you've seen online (eg. in a usenet
post) and paste into your editor. Maybe you want to merge it with your
own code.
But its tabbing is all spaces; yours is all tabs. Plus invariably, the
whole thing has extra indentation (eg. the leftmost statement is
already indented). Or you want to copy code from within a block to a
different indent level.
Any sane editor will give you tools to fix that - automatic indentation, tab-to-space and space-to-tab conversion, manual indent or outdent block tools, etc.
The whole thing gets very messy and error prone. You need special
editor commands to deal with the mess.
No, you don't. (Unless you think "special" means "anything but Windows Notepad" .)
Indented, non-delimited code and data is fine for machine-generated
and machine processed code. But it's a disaster for code that has to
be human-generated and human-maintained. It's just too fragile.
In real-life Python coding, it works fine. I prefer explicit block delimiters, but I cannot say Python's white-space blocking has been a significant source of trouble or inconvenience for me. Perhaps that's because I have always been used to careful and consistent formatting. I don't write C code (or any other code) with inconsistent spacing, mixes
of tabs and spaces, or unexpected indentations. So for me, the spacing
and tabbing of Python code would be identical if it had braces or other begin-end markers.
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
No one has to do that. It's a Lawrence peculiarity, and his coding
style (in Python or C, and probably anything else) would be rejected by anyone with a coding standard. I agree that it suggests that something
is badly wrong, but it is not with the language!
(6) You want to add extra statements to the end of a block, but
where IS the end? You have to INFER the ending by looking for a
line with a smaller indent. But suppose you're at the bottom of a
window; is that bottom line the last in the block, or is there
another one at the same indent just out of sight? You have to
tentatively keep peeking ahead!
Keep your blocks small and neat.
(6a) And maybe there's big comment blocking in the middle of block; comments don't need nesting! If there are lots of comments and few statements, finding the end of the block (ie. the last statement of
this block) can become quite an exercise.
That applies to every programming language (unless you know of one
that doesn't support comments).
It applies very much moreso to languages where comments *must* follow
the indentation level of the surrounding code, so that the deeper you
go, the more lines you have to split comments across.
On Tue, 27 Aug 2024 15:10:08 +0200
David Brown <david.brown@hesbynett.no> wrote:
(6) You want to add extra statements to the end of a block, but
where IS the end? You have to INFER the ending by looking for a
line with a smaller indent. But suppose you're at the bottom of a
window; is that bottom line the last in the block, or is there
another one at the same indent just out of sight? You have to
tentatively keep peeking ahead!
Keep your blocks small and neat.
That's very much one for the "good advice that is not always feasible
in the Real World" file. Every project has its own natural balance of
"large things that can be easily re-factored into sets of small things"
(i.e. things you can function-ize) vs. "large things that cannot."
(6a) And maybe there's big comment blocking in the middle of block;
comments don't need nesting! If there are lots of comments and few
statements, finding the end of the block (ie. the last statement of
this block) can become quite an exercise.
That applies to every programming language (unless you know of one
that doesn't support comments).
It applies very much moreso to languages where comments *must* follow
the indentation level of the surrounding code, so that the deeper you
go, the more lines you have to split comments across.
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
And, also the block then merges with the
following one as it's at the same level, so when you want to change it back...
(6a) And maybe there's big comment blocking in the middle of block;
comments don't need nesting! If there are lots of comments and few statements, finding the end of the block (ie. the last statement of this block) can become quite an exercise.
(7) You take some Python code you've seen online (eg. in a usenet post)
and paste into your editor. Maybe you want to merge it with your own
code.
But its tabbing is all spaces; yours is all tabs. Plus invariably, the
whole thing has extra indentation (eg. the leftmost statement is already indented). Or you want to copy code from within a block to a different
indent level.
It is not common to have to have indent comment lines (certainly in
Python it is not necessary). And if you find yourself writing large
comments in the middle of a block in the middle of a function, it is
probably time to consider re-organising the code and/or the comments and documentation. (Again, there can be exceptions to this general rule.)
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:[...]
[...]And, also the block then merges with the
following one as it's at the same level, so when you want to change it
back...
This is where my “#end” comments come in.
I've done some Python programming, and it wouldn't occur to me to add
"#end" comments. If I saw them in a code review I'd probably recommend deleting them.
On Tue, 27 Aug 2024 14:49:19 -0700, Keith Thompson wrote:
I've done some Python programming, and it wouldn't occur to me to add
"#end" comments. If I saw them in a code review I'd probably recommend
deleting them.
Give them a try. They simplify a lot of situations. I already posted a reasonably complex example in this thread. Go have a look at it, and see what happens when you delete those comments.
John Ames <commodorejohn@gmail.com> writes:
But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.
In many years of using Python routinely and extensively I?ve simply
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it?s a form of experience that must have built up very quickly.
Bart <bc@freeuk.com> writes:
On 27/08/2024 09:39, Richard Kettlewell wrote:
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
I?ve never encountered anyone else doing that in Python. It suggests
more than the individual doing that just doesn?t like the language, in
which case I?d just suggest that person doesn?t use it.
It is not common to have to have indent comment lines (certainly in
Python it is not necessary). And if you find yourself writing large comments in the middle of a block in the middle of a function, it is probably time to consider re-organising the code and/or the comments and documentation. (Again, there can be exceptions to this general rule.)
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 27 Aug 2024 14:49:19 -0700, Keith Thompson wrote:
I've done some Python programming, and it wouldn't occur to me to add
"#end" comments. If I saw them in a code review I'd probably
recommend deleting them.
Give them a try. They simplify a lot of situations. I already posted a
reasonably complex example in this thread. Go have a look at it, and
see what happens when you delete those comments.
No, I won't be doing that.
In comp.unix.programmer David Brown <david.brown@hesbynett.no> wrote:
It is not common to have to have indent comment lines (certainly in
Python it is not necessary). And if you find yourself writing large
comments in the middle of a block in the middle of a function, it is
probably time to consider re-organising the code and/or the comments and
documentation. (Again, there can be exceptions to this general rule.)
It may not be "common" (ie, not a lot of languages have this requirement), but if it's your job to maintain a project written in such a language,
then you'll have to deal with that problem every single day.
In comp.unix.programmer Richard Kettlewell <invalid@invalid.invalid> wrote:
Bart <bc@freeuk.com> writes:
On 27/08/2024 09:39, Richard Kettlewell wrote:
The fact that people have to resort to adding #end lines, which only
partly deals with one or two of those problems, suggest that something
is badly wrong.
I?ve never encountered anyone else doing that in Python. It suggests
more than the individual doing that just doesn?t like the language, in
which case I?d just suggest that person doesn?t use it.
I think it's a great idea. I'm considering asking my team to start adding >#end comments to our codebase.
At my company, somebody tried to delete a method like method2() above,
but forgot the last few lines (represented by call6()). This does
not introduce a SyntaxError. Instead, call6() is now part of method1() because it's at the same level of indentation. In most programming
languages, the beginning of method2() would be preceded by some
delimiter marking the end of method1(), which would prevent an
accidental merger of this type.
On Wed, 28 Aug 2024 02:48:59 -0000 (UTC)
Sebastian <sebastian@here.com.invalid> wrote:
At my company, somebody tried to delete a method like method2() above,
but forgot the last few lines (represented by call6()). This does
not introduce a SyntaxError. Instead, call6() is now part of method1()
because it's at the same level of indentation. In most programming
languages, the beginning of method2() would be preceded by some
delimiter marking the end of method1(), which would prevent an
accidental merger of this type.
(Waiting for the Python advocates to fire back with "well, don't do
that, then!" and completely miss the point that it's exactly the topic
of contention here that Python's scope-by-layout approach that makes it
easy to do that...)
Sebastian <sebastian@here.com.invalid> wrote:
At my company, somebody tried to delete a method like method2()
above, but forgot the last few lines (represented by call6()). This
does not introduce a SyntaxError. Instead, call6() is now part of
method1() because it's at the same level of indentation. In most
programming languages, the beginning of method2() would be preceded
by some delimiter marking the end of method1(), which would prevent
an accidental merger of this type.
(Waiting for the Python advocates to fire back with "well, don't do
that, then!" and completely miss the point that it's exactly the topic
of contention here that Python's scope-by-layout approach that makes it
easy to do that...)
On 28/08/2024 16:25, John Ames wrote:
On Wed, 28 Aug 2024 02:48:59 -0000 (UTC)
Sebastian <sebastian@here.com.invalid> wrote:
At my company, somebody tried to delete a method like method2() above,
but forgot the last few lines (represented by call6()). This does
not introduce a SyntaxError. Instead, call6() is now part of method1()
because it's at the same level of indentation. In most programming
languages, the beginning of method2() would be preceded by some
delimiter marking the end of method1(), which would prevent an
accidental merger of this type.
(Waiting for the Python advocates to fire back with "well, don't do
that, then!" and completely miss the point that it's exactly the topic
of contention here that Python's scope-by-layout approach that makes it
easy to do that...)
Or they will say that whoever deleted method2 could also have deleted
that 'end' line if one was used. Whilst also forgetting to delete
method2's own 'end' line.
Or maybe they deleted method2 plus both the preceding and succeeding
lines so that method1 merges into method3.
Generally, they might point all the ways that such oversights and all
kinds of other typos can result in still-valid code in any language. But fragile syntax like Python's just makes it so easier to do that.
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
I do the same in Python. The difference is that in Python the
indentation is the single source of truth about program structure,
while in other languages it's a matter of convention.
https://en.wikipedia.org/wiki/Single_source_of_truth
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
Writing editor editor macros in order to work around fundamentally bad language design is not something a programmer should have to waste time on.
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste
time on.
I don't know about Emacs, but in most editors the way you indent a block
of code is to select the lines, then press "Tab". Unindenting is "shift-Tab". Changing tabs to spaces or spaces to tabs is done by selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type (so
you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.
On Tue, 27 Aug 2024 19:10:57 -0700, Keith Thompson wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 27 Aug 2024 14:49:19 -0700, Keith Thompson wrote:
I've done some Python programming, and it wouldn't occur to me to add
"#end" comments. If I saw them in a code review I'd probably
recommend deleting them.
Give them a try. They simplify a lot of situations. I already posted a
reasonably complex example in this thread. Go have a look at it, and
see what happens when you delete those comments.
No, I won't be doing that.
I wonder why? You expressed an opinion about them, yet when I try to find out more about why you feel that way, you run away.
On 28/08/2024 19:48, David Brown wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)I don't know about Emacs, but in most editors the way you indent a
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste
time on.
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done
by selecting "Tabs to spaces" from the Edit menu, or something
equally simple and obvious. Many editor can be set to convert tabs
to spaces (or vice versa) when saving files, perhaps specific to the
file type (so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet
still have trouble with this kind of thing.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design. A lesser one
is having to rely on whatever varied features that 100s of different
editors may have to do so.
And yet another, of more significance, if that after you've indented a
block, it may now merge into an adjacent block that was already at
that new indent. If you later need to revert that first block back to
it's original position, you'd better make sure you mark that boundary.
It is a language design issue pure and simple. Don't try and pin it on
the users and make out it's due to lack of expertise with their
editors. Of course we can all indent blocks; it's just an unnecessary palaver.
Clearly your point of view is as a language /user/ where languages and
their characteristics are an invariant that you can't do anything
about, can't change, and need to work around.
But some of us devise (and, importanly, implement) languages of our
own and can be more vocal about misfeatures in others.
Bart <bc@freeuk.com> writes:
On 28/08/2024 19:48, David Brown wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)I don't know about Emacs, but in most editors the way you indent a
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:Writing editor editor macros in order to work around fundamentally bad >>>> language design is not something a programmer should have to waste
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same. >>>>
time on.
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done
by selecting "Tabs to spaces" from the Edit menu, or something
equally simple and obvious. Many editor can be set to convert tabs
to spaces (or vice versa) when saving files, perhaps specific to the
file type (so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet
still have trouble with this kind of thing.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design. A lesser one
is having to rely on whatever varied features that 100s of different
editors may have to do so.
And yet another, of more significance, if that after you've indented a
block, it may now merge into an adjacent block that was already at
that new indent. If you later need to revert that first block back to
it's original position, you'd better make sure you mark that boundary.
It is a language design issue pure and simple. Don't try and pin it on
the users and make out it's due to lack of expertise with their
editors. Of course we can all indent blocks; it's just an unnecessary
palaver.
Clearly your point of view is as a language /user/ where languages and
their characteristics are an invariant that you can't do anything
about, can't change, and need to work around.
But some of us devise (and, importanly, implement) languages of our
own and can be more vocal about misfeatures in others.
If I'm moving chunks of code around in a C or C++ program, from one
scope to another, I can get away with leaving the indentation as it is, because all the compiler cares about is where the braces are. But I
*always* adjust the indentation to fit the code's new context.
Python's use of indentation to indicate scoping just means that I have
to do what I would have done anyway.
This was an attempt to port an benchmark into Nim; I'd spent the
best part of an hour trying to get it right, but it kept going
wrong. In the end I resorted to artificial block terminators.
The final code looked like that below. Now it is much, much easier
to see what goes where, and what belongs to what. I can more
confidently write that extra statement following the opening 'if'.
With these changes, the porting went much more smooothly.
if q1!=1:
for i in countup(2,n):
q[i]=p[i]
# end
flips=1
while true:
qq=q[q1]
if qq==1:
sum+=sign*flips
if flips>maxflips:
maxflips=flips # end
break
# end
q[q1]=q1
if q1>=4:
i=2
j=q1-1
while true:
t=q[i]
q[i]=q[j]
q[j]=t
i+=1
j-=1
if i>=j:
break # end # end
# end
q1=qq
flips+=1
# end
# end
Sure, people CAN program in such languages, but it is harder work> and more error prone.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
If you have some code that needs a lot of documentation (and some does),
then put the comments in a place that does not interfere with reading
and understanding the code.
But ok, I found your post and removed all the #end comments. I found it
just as readable without them as with them.
On 27/08/2024 15:18, Bart wrote:
[Previous discussion and code snipped -- ANW]
This was an attempt to port an benchmark into Nim; I'd spent the
best part of an hour trying to get it right, but it kept going
wrong. In the end I resorted to artificial block terminators.
The final code looked like that below. Now it is much, much easier
to see what goes where, and what belongs to what. I can more
confidently write that extra statement following the opening 'if'.
With these changes, the porting went much more smooothly.
if q1!=1:
for i in countup(2,n):
q[i]=p[i]
# end
flips=1
while true:
qq=q[q1]
if qq==1:
sum+=sign*flips
if flips>maxflips:
maxflips=flips
# end
break
# end
q[q1]=q1
if q1>=4:
i=2
j=q1-1
while true:
t=q[i]
q[i]=q[j]
q[j]=t
i+=1
j-=1
if i>=j:
break
# end
# end
# end
q1=qq
flips+=1
# end
# end
Sure, people CAN program in such languages, but it is harder work> and
more error prone.
ISTM that the difficulty in reading and writing code like that
stems not from the indentation, but
from a
long narrow
corridor
of program
which is
difficult to
read
and write
no matter how
it is indented.
Variable indentation
merely
makes the long
column wriggly.
It reminds me of the early autocodes, before the days of block structure.
I don't know Nim [and only a little of Python], so I can't apportion the difficulty of understanding the code between the language and the chosen programming style. But I can't resist adding a few comments:
(a) Bart takes 14 lines [from "if q1>=4" to the corresponding "# end"]
to express the notion [E&OE]
for i from 2 to q1%2
swap (q[i], q[q1 - i + 1])
Small wonder that he found the code hard to get right!
(b) There are two occurrences of "while true" and two of "break" in the code which would not be necessary or appropriate in C or Algol [amongst others]. Again, IMO these contribute to the obscurity of the code.
(c) I recognise that code as coming from a version of the "Fannkuch" benchmark, so I already have it in C and in Algol 68G. Bart's Nim code
is substantially longer [around twice the length of the A68G]. Brevity
is not everything, but if you are forever scrolling from one window to
the next while your friend gets it all into one window [without losing clarity of expression], then guess who is going to find it easier to
read, write and understand the code.
(d) Further, if the code is harder to understand, it has more need of explanatory comments, which in turn make the code longer, so harder to navigate around.
On Wed, 28 Aug 2024 20:27:53 +0100, Bart wrote:
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
If you think the need for refactoring is something that can be solved by “language design”, I’d like to hear how.
Bart <bc@freeuk.com> writes:
On 28/08/2024 19:48, David Brown wrote:
But some of us devise (and, importanly, implement) languages of our
own and can be more vocal about misfeatures in others.
If I'm moving chunks of code around in a C or C++ program, from one
scope to another, I can get away with leaving the indentation as it is, because all the compiler cares about is where the braces are. But I
*always* adjust the indentation to fit the code's new context.
Python's use of indentation to indicate scoping just means that I have
to do what I would have done anyway.
On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:
But ok, I found your post and removed all the #end comments. I found it
just as readable without them as with them.
You know what? You are right. That example was just too
well-structured.
Here’s a more dangerous one:
def register_additional_standard(self, **kwargs) :
"registers additional standard interfaces that are not automatically" \
" installed at Connection creation time. Currently the only one is" \
" the object-manager interface, registered with\n" \
"\n" \
" «conn».register_additional_standard(managed_objects = True)\n"
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
if self._managed_objects != None :
raise asyncio.InvalidStateError \
(
"object manager interface already registered"
)
#end if
self.register \
(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
self._managed_objects = {}
else :
raise TypeError("unrecognized argument keyword “%s”" % key)
#end if
#end if
#end for
return \
self
#end register_additional_standard
versus
def register_additional_standard(self, **kwargs) :
"registers additional standard interfaces that are not automatically" \
" installed at Connection creation time. Currently the only one is" \
" the object-manager interface, registered with\n" \
"\n" \
" «conn».register_additional_standard(managed_objects = True)\n"
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
if self._managed_objects != None :
raise asyncio.InvalidStateError \
(
"object manager interface already registered"
)
self.register \
(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
self._managed_objects = {}
else :
raise TypeError("unrecognized argument keyword “%s”" % key)
return self
I was looking for quite a tricky example I remember seeing on the
ArjanCodes channel on YouTube, but I can’t find it.
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste
time on.
I don't know about Emacs, but in most editors the way you indent a block
of code is to select the lines, then press "Tab". Unindenting is "shift-Tab". [...]
On 28/08/2024 23:49, Lawrence D'Oliveiro wrote:
On Wed, 28 Aug 2024 20:27:53 +0100, Bart wrote:
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
If you think the need for refactoring is something that can be solved
by “language design”, I’d like to hear how.
The aim is to not NEED refactoring when you are playing around with different, short-term bits of code.
That's not the conventional way to format a docstring. If you're using backslashes to splice lines in Python, it's likely you're doing
something wrong.
I think "is not None" is more idiomatic.
You don't need the \ if you put the ( on the same line.
You leave a space between "else" and ":". It's not wrong, but it's not something I've ever seen.
In any language, if a block of code is so deeply indented that it's confusing, you should consider refactoring it. (Though that's not
always the answer.)
If there's only
primitive editing commands available (i.e. selection by mouse, or long
clumsy keyboard sequences) it may be irrelevant whether you indent code
in a Python or in a "C" program. If you're using editors like Vi that
block selection can be done with '%' and the indent with '>%' and the
reverse indent with '<%' (without the quotes); but that works only if
you have the syntactical elements (the braces, parenthesis, brackets) as definition of the program block. That won't work for a block in a
language like Python where blocks are defined by layout (by the grade of indentation); then you'd have to resort to the primitive editors'
selection features, mouse/menus or more laborious keyboard commands.
On Wed, 28 Aug 2024 17:23:25 -0700, Keith Thompson wrote:
That's not the conventional way to format a docstring. If you're using
backslashes to splice lines in Python, it's likely you're doing
something wrong.
What exactly is wrong?
I think "is not None" is more idiomatic.
When I want an equality comparison, I use “==”, not “is”.
You don't need the \ if you put the ( on the same line.
But I do otherwise.
You leave a space between "else" and ":". It's not wrong, but it's not
something I've ever seen.
People who look at my code tend to get triggered by the little things;
maybe it’s a way to avoid thinking about the big things?
In any language, if a block of code is so deeply indented that it's
confusing, you should consider refactoring it. (Though that's not
always the answer.)
The point being, the same kind of code in a language with explicit
statement brackets would reach the point of confusion later, rather than sooner.
On Thu, 29 Aug 2024 02:29:55 +0200, Janis Papanagnou wrote:
If there's only
primitive editing commands available (i.e. selection by mouse, or long
clumsy keyboard sequences) it may be irrelevant whether you indent code
in a Python or in a "C" program. If you're using editors like Vi that
block selection can be done with '%' and the indent with '>%' and the
reverse indent with '<%' (without the quotes); but that works only if
you have the syntactical elements (the braces, parenthesis, brackets) as
definition of the program block. That won't work for a block in a
language like Python where blocks are defined by layout (by the grade of
indentation); then you'd have to resort to the primitive editors'
selection features, mouse/menus or more laborious keyboard commands.
I have Emacs commands defined to jump quickly between lines with matching indentation. That lets me easily select entire statement blocks in Python.
On 29.08.2024 03:22, Lawrence D'Oliveiro wrote:
I have Emacs commands defined to jump quickly between lines with
matching indentation. That lets me easily select entire statement
blocks in Python.
I'm sure you have. - But wasn't that the point someone made upthread:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste time on. >>
I don't know about Emacs, but in most editors the way you indent a block
of code is to select the lines, then press "Tab". Unindenting is >"shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type (so
you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.
On Thu, 29 Aug 2024 00:21:43 +0100, Bart wrote:
On 28/08/2024 23:49, Lawrence D'Oliveiro wrote:
On Wed, 28 Aug 2024 20:27:53 +0100, Bart wrote:
The main problem isn't in changing the indentation of a block of code; >>>> it is in HAVING to do so because of poor language design.
If you think the need for refactoring is something that can be solved
by “language design”, I’d like to hear how.
The aim is to not NEED refactoring when you are playing around with
different, short-term bits of code.
“Playing around” is exactly one of those situations where you will need to
do all kinds of things to the code, including refactoring.
Without the constraints imposed by the language, I could just write it as:
if a == b:
s1
RETURN
s2
s3
NOW it stands out!
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:
But ok, I found your post and removed all the #end comments. I found it >>> just as readable without them as with them.
You know what? You are right. That example was just too
well-structured.
Here’s a more dangerous one:
def register_additional_standard(self, **kwargs) :
"registers additional standard interfaces that are not automatically" \
" installed at Connection creation time. Currently the only one is" \
" the object-manager interface, registered with\n" \
"\n" \
" «conn».register_additional_standard(managed_objects = True)\n"
That's not the conventional way to format a docstring. If you're using backslashes to splice lines in Python, it's likely you're doing
something wrong.
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
if self._managed_objects != None :
I think "is not None" is more idiomatic.
raise asyncio.InvalidStateError \
(
"object manager interface already registered" >> )
You don't need the \ if you put the ( on the same line.
#end if
self.register \
(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
Again, you've decided how you want to place parentheses and you're
forcing the syntax to cater to that. I might write that as:
self.register(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
self._managed_objects = {}
else :
You leave a space between "else" and ":". It's not wrong, but it's not something I've ever seen. It's likely to be just a little jarring to readers.
raise TypeError("unrecognized argument keyword “%s”" % key)
Do you have a requirement to use older versions of Python that don't
support f-strings?
#end if
#end if
#end for
return \
self
Why not just "return self"?
#end register_additional_standard
versus
def register_additional_standard(self, **kwargs) :
"registers additional standard interfaces that are not automatically" \
" installed at Connection creation time. Currently the only one is" \
" the object-manager interface, registered with\n" \
"\n" \
" «conn».register_additional_standard(managed_objects = True)\n"
for key in kwargs :
if kwargs[key] :
if key == "managed_objects" :
if self._managed_objects != None :
raise asyncio.InvalidStateError \
(
"object manager interface already registered" >> )
self.register \
(
path = "/",
interface = ManagedObjectsHandler(),
fallback = True
)
self._managed_objects = {}
else :
raise TypeError("unrecognized argument keyword “%s”" % key)
return self
Again, the #end comments don't make it any more readable *for me*.
I suspect that would be even more true for more experienced Python programmers.
I was looking for quite a tricky example I remember seeing on the
ArjanCodes channel on YouTube, but I can’t find it.
In any language, if a block of code is so deeply indented that it's confusing, you should consider refactoring it. (Though that's not
always the answer.)
I once reviewed some C code with misleading indentation. Depending on
the viewer's tab settings (4 vs 8 columns) it looked either like this:
if (condition)
this;
that;
or like this:
if (condition)
this;
that;
Of course it meant the same to the compiler.
In any language, I think it's important to use consistent indentation
that reflects the structure of the code, and to avoid mixing tabs and
spaces. (My personal preference is to use spaces exclusively, but I'll conform to what existing code does.) As I've said elsethread, Python's
rules just force me to do what I would have done anyway.
On Wed, 28 Aug 2024 17:23:25 -0700, Keith Thompson wrote:
That's not the conventional way to format a docstring. If you're using
backslashes to splice lines in Python, it's likely you're doing
something wrong.
What exactly is wrong?
I think "is not None" is more idiomatic.
When I want an equality comparison, I use “==”, not “is”.
You don't need the \ if you put the ( on the same line.
But I do otherwise.
You leave a space between "else" and ":". It's not wrong, but it's not
something I've ever seen.
People who look at my code tend to get triggered by the little things;
maybe it’s a way to avoid thinking about the big things?
On 28/08/2024 19:48, David Brown wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same.
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste
time on.
I don't know about Emacs, but in most editors the way you indent a
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type
(so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
A lesser one
is having to rely on whatever varied features that 100s of different
editors may have to do so.
And yet another, of more significance, if that after you've indented a block, it may now merge into an adjacent block that was already at that
new indent. If you later need to revert that first block back to it's original position, you'd better make sure you mark that boundary.
It is a language design issue pure and simple. Don't try and pin it on
the users and make out it's due to lack of expertise with their editors.
Of course we can all indent blocks; it's just an unnecessary palaver.
Clearly your point of view is as a language /user/ where languages and
their characteristics are an invariant that you can't do anything about, can't change, and need to work around.
But some of us devise (and, importanly, implement) languages of our own
and can be more vocal about misfeatures in others.
On Wed, 28 Aug 2024 20:48:08 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
Writing editor editor macros in order to work around fundamentally bad
language design is not something a programmer should have to waste
time on.
I don't know about Emacs, but in most editors the way you indent a
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type
(so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet still
have trouble with this kind of thing.
Don't be a patronising prick, it doesn't help your argument. Personally I have better things to do that figure out some obscure functionality of vim
to achieve something I shouldn't have to do in the first place if the language was designed properly. Thankfully I don't have to use Python much.
On 2024-08-29 12:49, Bart wrote:
Without the constraints imposed by the language, I could just write it as: >> if a == b:
s1
RETURN
s2
s3
NOW it stands out!
In Ada I use indentation for the purpose:
if A = B then -- This I will remove later
s1;
end if;
s2;
s3;
I remember FORTRAN in its glory days had D-comments. In the first column
the letter D meant a conditional, compiled in the debug mode, ignored otherwise.
Don't you ever just accept that a language is the way it is, and it
is perfectly useable that way? Or think that perhaps other people in
the world know better than you do about how they want their language
to work? Has it never occurred to you that the people behind a given language - such as Python - considered various alternatives and
decided that making it the way they did was the best choice overall
for the language they wanted?
Presumably you are /not/ trying to claim that - you are just trolling.
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
[...]
Then don't use vim - use an editor that suits your needs.
If you are trying to claim that you do software development, and that
the editor(s) you use regularly do not have easily available functions
for indenting and un-indenting sections of code, then you are either
lying, or you /are/ an aforementioned special kind of genius.
On Thu, 29 Aug 2024 14:24:01 +0200
David Brown <david.brown@hesbynett.no> wrote:
Don't you ever just accept that a language is the way it is, and it
is perfectly useable that way? Or think that perhaps other people in
the world know better than you do about how they want their language
to work? Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and
decided that making it the way they did was the best choice overall
for the language they wanted?
They probably did - but did they do that *because* of the point in
question, in spite of it, or without any meaningful inclination toward
or against it? There are plenty of other aspects about Python that may
tip the balance in spite of its annoyances.
F'rinstance, the *very* comprehensive set of libraries make bashing out
quick utilities to do A Complex Thing often very simple. (That was the
reason I first used it - needed a quick-'n-easy way to programmatically deliver data in a POST request from a Windows box in production, and it
beat the hell out of trying to wrap my head around Win32 network programming.) But if the language "wins" on that score, that doesn't
mean its annoyances or flaws are any less real or worthy of complaint.
Like, obviously it's way too late in the game for Python to change this
now. But we can still say it's stupid for them to have done it that way
in the first place. Is that a matter of opinion? Sure, but that's never stopped anybody from expressing themselves re: any other language. (How
many people are still bitching about C being "insecure," 50+ years down
the line?)
On Thu, 29 Aug 2024 14:30:27 +0200
David Brown <david.brown@hesbynett.no> wrote:
Presumably you are /not/ trying to claim that - you are just trolling.
Ah ok, you're the type who thinks anyone who disagrees with you is a troll.
You're not worth the effort mate.
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
[...]
Then don't use vim - use an editor that suits your needs.
LOL. (You appear to be joking. - If not, continue reading...)
But what makes you think that his needs are not covered by Vim?
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
That looks unfinished to me. So I will add a "return" at the end (with
a single tab indent, in this case).
Don't you ever just accept that a language is the way it is, and it is perfectly useable that way?
Or think that perhaps other people in the world know better than you do
about how they want their language to work?
Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?
On 29/08/2024 02:23, Keith Thompson wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:
But ok, I found your post and removed all the #end comments. I found
it just as readable without them as with them.
You know what? You are right. That example was just too
well-structured.
So why not try to write /all/ your code in a well-structured manner, so
that you don't feel the need to add these "#end" comments?
def register_additional_standard(self, managed_objects) :
"""
registers additional standard interfaces that are not
automatically installed at Connection creation time. Currently
the only one is the object-manager interface, registered with
«conn».register_additional_standard(managed_objects = True)
"""
Line continuation characters in Python are usually an indicator of poor formatting, or an unhealthy obsession with line length limits.
I don't know if I am more experienced than you in Python (I may have
been using Python for longer, but you may have worked with it more), but
I would say that the "#end" comments directly detract from readability.
On 28/08/2024 21:27, Bart wrote:
On 28/08/2024 19:48, David Brown wrote:
On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:Writing editor editor macros in order to work around fundamentally bad >>>> language design is not something a programmer should have to waste
(2) You want to temporarily comment out an 'if' line so that the
following block is unconditional. You can't do that with also
unindenting the block.
In Emacs, I have commands defined to adjust the indentation of the
selected region. Surely any other decent editor would offer the same. >>>>
time on.
I don't know about Emacs, but in most editors the way you indent a
block of code is to select the lines, then press "Tab". Unindenting
is "shift-Tab". Changing tabs to spaces or spaces to tabs is done by
selecting "Tabs to spaces" from the Edit menu, or something equally
simple and obvious. Many editor can be set to convert tabs to spaces
(or vice versa) when saving files, perhaps specific to the file type
(so you don't muck up your makefiles).
It takes a special kind of genius to be able to program, and yet
still have trouble with this kind of thing.
The main problem isn't in changing the indentation of a block of code;
it is in HAVING to do so because of poor language design.
If I am adding or removing blocks (such as surrounding existing code in
a new conditional), then I /have/ to change the indentation - in /any/ language. (I use indents in my assembly programming too.) Call it OCD
or compulsive behaviour if you like, but I cannot consider code to be finished - even to the level of a quick compile or test - if the
indentation is not correct.
I simply cannot see the problem with Python here, because I would not
indent things in any other way in any language.
The only thing I see as annoying in Python is when you have two or three indentations left hanging :
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
That looks unfinished to me.
So I will add a "return" at the end (with
a single tab indent, in this case). If it is not the end of the
function, I will sometimes use a "pass" to pull back the indent level.
Of course, being a sane software developer, I do most of my programming using editors that are suitable for software development. Most professional carpenters use hammers for their nails, rather than bashing them in with stones - it's the same thing, really.
And yet another, of more significance, if that after you've indented a
block, it may now merge into an adjacent block that was already at
that new indent. If you later need to revert that first block back to
it's original position, you'd better make sure you mark that boundary.
So mark the boundary. Add a blank line. Put a comment line describing the steps of the function. You are making up problems for which you already have good solutions that you would be using in any programming language.
Having made your own language(s) gives you no more and no less right to comment about features of other languages that you like or dislike.
Your problem here is that you are obsessed with finding things that you
want to see as misfeatures, design flaws, or problems in other languages
- and then obsess about how you can find new ways to make it more
difficult to "work around" them.
Don't you ever just accept that a language is the way it is, and it is perfectly useable that way?
Or think that perhaps other people in the
world know better than you do about how they want their language to
work? Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?
As Bjarne Stustroup said, there are two kinds of programming languages - those that people complain about, and those that no one uses.
Think about why you bother to indent code in languages where the compiler ignores such indentation anyway: it means you are expressing the structure of code in two different ways, one via statement brackets, and the other
via indentation. This redundancy aids in understanding that the code does what you think it does.
Python gets rid of this redundancy, by having the compiler take notice of the whitespace and removing the statement bracketing symbols. So I put it back, by adding statement bracketing symbols that the compiler ignores.
Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen. (Not mentioning its equally powerful other editing facilities.)
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
[...]
Think about why you bother to indent code in languages where the
compiler ignores such indentation anyway: it means you are expressing
the structure of code in two different ways, one via statement
brackets, and the other via indentation. This redundancy aids in
understanding that the code does what you think it does.
Python gets rid of this redundancy, by having the compiler take notice
of the whitespace and removing the statement bracketing symbols. So I
put it back, by adding statement bracketing symbols that the compiler
ignores.
On Thu, 29 Aug 2024 14:01:05 +0200, David Brown wrote:
On 29/08/2024 02:23, Keith Thompson wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:
But ok, I found your post and removed all the #end comments. I found >>>>> it just as readable without them as with them.
You know what? You are right. That example was just too
well-structured.
So why not try to write /all/ your code in a well-structured manner, so
that you don't feel the need to add these "#end" comments?
Because not all examples can be made that neat, as I demonstrated.
def register_additional_standard(self, managed_objects) :
"""
registers additional standard interfaces that are not
automatically installed at Connection creation time. Currently
the only one is the object-manager interface, registered with
«conn».register_additional_standard(managed_objects = True)
"""
Note that Python’s indentation rules don’t apply to multiline string literals -- don’t you wish they did? So you end up with all that extra space within the literal. Do you see why I prefer to avoid that?
Line continuation characters in Python are usually an indicator of poor
formatting, or an unhealthy obsession with line length limits.
I like to keep within a line length limit of about 100 characters.
I don't know if I am more experienced than you in Python (I may have
been using Python for longer, but you may have worked with it more), but
I would say that the "#end" comments directly detract from readability.
Think about why you bother to indent code in languages where the compiler ignores such indentation anyway: it means you are expressing the structure
of code in two different ways, one via statement brackets, and the other
via indentation. This redundancy aids in understanding that the code does what you think it does.
Python gets rid of this redundancy, by having the compiler take notice of
the whitespace and removing the statement bracketing symbols. So I put it back, by adding statement bracketing symbols that the compiler ignores.
On Thu, 29 Aug 2024 14:24:01 +0200, David Brown wrote:
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
That looks unfinished to me. So I will add a "return" at the end (with
a single tab indent, in this case).
A redundant “return” ... kind of like my redundant “#end” comments, except
yours work in a more restricted set of places ...
Don't you ever just accept that a language is the way it is, and it is
perfectly useable that way?
Of course not.
Or think that perhaps other people in the world know better than you do
about how they want their language to work?
And vice versa.
Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?
Barring a few obvious stupidities, yes of course they were, and are, smart people.
On 29/08/2024 13:24, David Brown wrote:
On 28/08/2024 21:27, Bart wrote:
On 28/08/2024 19:48, David Brown wrote:
It's just too 'open'. The contents of foo look like they're leaking into
the rest of the program. As it is, someone looking at this in the future wanting to a a new statement to 'if a:' might think it ends before the comments since that 'anewstmt' is too far from the main body.
It needs delimiters:
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
end
bnewstmt
end
# comment
# comment
anewstmt
end
end
Now you know that 'if a' doesn't end at that blank line, because no
'end' has been seen for it.
So I will add a "return" at the end (with a single tab indent, in this
case). If it is not the end of the function, I will sometimes use a
"pass" to pull back the indent level.
So you have problems too. Would you have needed 'return' if 'end's had
been used in the original?
Of course, being a sane software developer, I do most of my
programming using editors that are suitable for software development.
Most professional carpenters use hammers for their nails, rather than
bashing them in with stones - it's the same thing, really.
And yet another, of more significance, if that after you've indented
a block, it may now merge into an adjacent block that was already at
that new indent. If you later need to revert that first block back to
it's original position, you'd better make sure you mark that boundary.
So mark the boundary. Add a blank line. Put a comment line
describing the steps of the function. You are making up problems for
which you already have good solutions that you would be using in any
programming language.
How about just fixing the ******* language? That must be better than a million programmers wasting time creating their own fixes.
Having made your own language(s) gives you no more and no less right
to comment about features of other languages that you like or dislike.
I had my opinions even before I used my own stuff.
One thing I despised was the begin-end business in Algol60 and Pascal,
which has the same nuisance as braces in C-like languages.
I didn't like writing 'end else begin' any more than '} else {'. My
stuff (and a few languages have picked up on it), uses just 'else',
which also limits the placement possibilities when you have one token
rather than three.
Your problem here is that you are obsessed with finding things that
you want to see as misfeatures, design flaws, or problems in other
languages
Yes. I'm into language design. But I'm also interested in aspects of it
that many disregard, such as microfeatures, or ease of deployment.
- and then obsess about how you can find new ways to make it more
difficult to "work around" them.
Fortunately I don't need to work with them much. If I did, I would find
the means to make them tolerable.
Don't you ever just accept that a language is the way it is, and it is
perfectly useable that way?
Well, I used Fortran IV for a year. But presumably lots of people
weren't that happy with it as we've since had Fortran 77, 90, 95, 2008,
2018 and 2023.
It's not just me!
Or think that perhaps other people in the world know better than you
do about how they want their language to work? Has it never occurred
to you that the people behind a given language - such as Python -
considered various alternatives and decided that making it the way
they did was the best choice overall for the language they wanted?
Python is full of ill-advised choices. And it's become almost as much of
a monster as C++, with a million incompatible features bolted on.
I'm not surprised that mere matters of syntax have low priority.
As Bjarne Stustroup said, there are two kinds of programming languages
- those that people complain about, and those that no one uses.
Funny, I can complain about lots of languages that I never use!
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
[...]
Think about why you bother to indent code in languages where the
compiler ignores such indentation anyway: it means you are expressing
the structure of code in two different ways, one via statement
brackets, and the other via indentation. This redundancy aids in
understanding that the code does what you think it does.
Python gets rid of this redundancy, by having the compiler take notice
of the whitespace and removing the statement bracketing symbols. So I
put it back, by adding statement bracketing symbols that the compiler
ignores.
You might find Bython useful.
https://github.com/mathialo/bython
(I don't, but you might.)
On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen. (Not
mentioning its equally powerful other editing facilities.)
Vim is only good for text-editing, though
On 30/08/2024 01:49, Bart wrote:
On 29/08/2024 13:24, David Brown wrote:
On 28/08/2024 21:27, Bart wrote:
On 28/08/2024 19:48, David Brown wrote:
<snipping for brevity>
It's just too 'open'. The contents of foo look like they're leaking
into the rest of the program. As it is, someone looking at this in the
future wanting to a a new statement to 'if a:' might think it ends
before the comments since that 'anewstmt' is too far from the main body.
It needs delimiters:
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
end
bnewstmt
end
# comment
# comment
anewstmt
end
end
It does not /need/ delimiters.
It does, sometimes, need a bit more care, especially if you have lots of nesting.
(And again let me repeat - I prefer languages to have explicit
delimiters. But that does not stop me being able to write Python code,
or being happy with the language overall. There are a dozen things I dislike about Python, of which whitespace blocking is a very minor one,
but there are many dozens more things I do like about it for the tasks
for which I use the language.)
How about just fixing the ******* language? That must be better than a
million programmers wasting time creating their own fixes.
Ah, so it is better to invalidate all the work done by these million programmers so far, along with all the tools, books, courses,
documentation, etc., than to say that people writing big functions might want to add an occasional comment? Yes, I can see how that makes
perfect sense.
Having made your own language(s) gives you no more and no less right
to comment about features of other languages that you like or dislike.
I had my opinions even before I used my own stuff.
Sure. We all have opinions about all sorts of things. Some people even have /informed/ opinions, that might be relevant to other people.
One thing I despised was the begin-end business in Algol60 and Pascal,
which has the same nuisance as braces in C-like languages.
You don't like whitespace based blocks, and you don't like explicit delimiters for blocks. Maybe you just don't like structured
programming? (Not all programming languages are structured.)
I didn't like writing 'end else begin' any more than '} else {'. My
stuff (and a few languages have picked up on it), uses just 'else',
which also limits the placement possibilities when you have one token
rather than three.
Ah, it is the need to press a couple of extra keys that you despise so
much?
Yes. I'm into language design. But I'm also interested in aspects of
it that many disregard, such as microfeatures, or ease of deployment.
That's great. But being interested in languages, their design, and
their features does not mean having an obsession about calling their features "flaws".
It's not just me!
For every programmer involved in changing and developing the Fortran language, there are a thousand programmers who use it - whichever
version of it they find best for their job. Now, it is important that these one-in-a-thousand programmers are there, improving the language.
But most of us are in the 999-in-a-thousand group that /use/ the
language. (In that one-in-a-thousand I am including the people who actively take part in discussions or proposals for changing the
language, but not people who just moan about stuff in discussion groups.)
Clearly you can take your own complaints seriously for your own
languages, and they are very important to you personally. But in the
grand scheme of things, they are utterly irrelevant to everyone else. So
you are also in the 999-in-a-thousand group, just like everyone else here.
Complaining about languages (or any kind of tool) doesn't change them -
it doesn't do anything except make you less happy about using them. It's fine to discuss alternative ways to handle aspects of a language that
you don't like, and to see if you can make it work better for your needs
and preferences. It's fine to compare it to other languages, and see if there are alternatives that would suit you better. And sometimes having
a rant is fun - after all, complaining (especially about the weather) is
the national pastime for Brits. But mostly it is counter-productive.
Python is full of ill-advised choices. And it's become almost as much
of a monster as C++, with a million incompatible features bolted on.
So don't use it if you don't like it. Mushy peas are an ill-advised
choice - I choose not to eat them, rather than to go to cookery groups
and tell everyone how horrible they are.
Funny, I can complain about lots of languages that I never use!
Yes, and no one takes your opinions seriously. Do you think there might
be some reason for that?
/All/ languages, except perhaps Bart's private language that is only
used by him, have their annoyances. I have worked at least a little
with a fair number of languages, and I've never seen one that I
thought was "perfect". But different people have different things
that the like and dislike about any given language.
So if you have the choice of which language to use (many programmers
do not), you pick one that has more things you like for the task in
question in comparison to the things you don't like.
But it's important to understand that these are opinions - the
designers of Python were /not/ stupid to have made the language that
way. They just had different opinions from you, and the had a much
better basis for forming those opinions than you or I.
Getting worked up about the way Python blocking works is about as
productive as getting worked up about the way English language
spelling works. There are countless other more useful ways to spend
your time - and certainly many more enjoyable ways.
When there are a number of smart, experienced and educated people
involved in the decisions, "obvious stupidities" are extremely
unlikely. That's the point of involving multiple people and gathering opinions from many in the field.
On Thu, 29 Aug 2024 21:27:36 +0200
David Brown <david.brown@hesbynett.no> wrote:
/All/ languages, except perhaps Bart's private language that is only
used by him, have their annoyances. I have worked at least a little
with a fair number of languages, and I've never seen one that I
thought was "perfect". But different people have different things
that the like and dislike about any given language.
So if you have the choice of which language to use (many programmers
do not), you pick one that has more things you like for the task in
question in comparison to the things you don't like.
Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just weird.
But it's important to understand that these are opinions - the
designers of Python were /not/ stupid to have made the language that
way. They just had different opinions from you, and the had a much
better basis for forming those opinions than you or I.
Yeah, well, your opinion that my opinion is just, like, my opinion is
just, like, your opinion, man.
On Fri, 30 Aug 2024 11:38:05 +0200
David Brown <david.brown@hesbynett.no> wrote:
Getting worked up about the way Python blocking works is about as
productive as getting worked up about the way English language
spelling works. There are countless other more useful ways to spend
your time - and certainly many more enjoyable ways.
Some people actually enjoy arguing on the Internet, y'know.
When there are a number of smart, experienced and educated people
involved in the decisions, "obvious stupidities" are extremely
unlikely. That's the point of involving multiple people and gathering
opinions from many in the field.
You may consider it as "unlikely" as you wish, but the fact is that
literal whitespace has been considered Obviously Stupid in the computer- programming world for so long that it was the subject of a joke re: JCL
in "Real Programmers Don't Use Pascal," published in 1983.
That's not to say that "considered Obviously Stupid" is the same thing
as "objectively wrong" - but if your argument is that all of this is on
equal footing as Just Opinions, discounting decades of established
opinion across the industry in preference to the opinions of the subset
of Python developers & advocates who believe in literal whitespace as Unambiguously Good rather gives the lie to that.
On 29/08/2024 18:44, Janis Papanagnou wrote:
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:
[...]
Then don't use vim - use an editor that suits your needs.
LOL. (You appear to be joking. - If not, continue reading...)
I was not joking.
But what makes you think that his needs are not covered by Vim?
You seem to have missed the point - sorry if I was not clear.
On Thu, 29 Aug 2024 21:27:36 +0200
David Brown <david.brown@hesbynett.no> wrote:
/All/ languages, except perhaps Bart's private language that is only
used by him, have their annoyances. I have worked at least a little
with a fair number of languages, and I've never seen one that I
thought was "perfect". But different people have different things
that the like and dislike about any given language.
So if you have the choice of which language to use (many programmers
do not), you pick one that has more things you like for the task in
question in comparison to the things you don't like.
Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just >weird.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen. (Not
mentioning its equally powerful other editing facilities.)
Vim is only good for text-editing, though
Again, L'D'O' is wrong.
You should work to improve the things you can, instead of
wasting effort arguing with brick walls.
It's not your language, so there is no "vice versa".
Barring a few obvious stupidities, yes of course they were, and are,
smart people.
When there are a number of smart, experienced and educated people
involved in the decisions, "obvious stupidities" are extremely unlikely.
... put in so much extra
crap and silliness that readers get caught up in that instead of
noticing that most of the function is meaningless.
My impression is that your unconventional style indicates a relative
lack of experience in Python.
There's lot of things that language syntax might not need. For example,
I could dispense with the closing parentheses here:
x = (a + (b + (c + d
as they can supplied as needed at end-of-line.
On Wed, 28 Aug 2024 19:19:38 -0700, Keith Thompson wrote:
My impression is that your unconventional style indicates a relative
lack of experience in Python.
You think maybe I should practise by writing more Python code?
OK, how about your thoughts on comparing this
for attrname in obj.tag_attrs :
attr = getattr(obj, attrname)
if attr != None :
if isinstance(attr, enum.Enum) :
attr = attr.value
elif isinstance(attr, Type) :
attr = unparse_signature(attr)
elif not isinstance(attr, str) :
raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
out.write(" " * indent + "<" + tag_name)
with this
for attrname in obj.tag_attrs :
attr = getattr(obj, attrname)
if attr != None :
if isinstance(attr, enum.Enum) :
attr = attr.value
elif isinstance(attr, Type) :
attr = unparse_signature(attr)
elif not isinstance(attr, str) :
raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
out.write(" " * indent + "<" + tag_name)
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 19:19:38 -0700, Keith Thompson wrote:
My impression is that your unconventional style indicates a relative
lack of experience in Python.
You think maybe I should practise by writing more Python code?
And you snipped the part where I acknowledged that might be an invalid conclusion. I have no opinion on what you should do.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 28 Aug 2024 19:19:38 -0700, Keith Thompson wrote:
My impression is that your unconventional style indicates a relative
lack of experience in Python.
You think maybe I should practise by writing more Python code?
And you snipped the part where I acknowledged that might be an invalid conclusion. I have no opinion on what you should do.
OK, how about your thoughts on comparing this
for attrname in obj.tag_attrs :
attr = getattr(obj, attrname)
if attr != None :
if isinstance(attr, enum.Enum) :
attr = attr.value
elif isinstance(attr, Type) :
attr = unparse_signature(attr)
elif not isinstance(attr, str) :
raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
out.write(" " * indent + "<" + tag_name)
with this
for attrname in obj.tag_attrs :
attr = getattr(obj, attrname)
if attr != None :
if isinstance(attr, enum.Enum) :
attr = attr.value
elif isinstance(attr, Type) :
attr = unparse_signature(attr)
elif not isinstance(attr, str) :
raise TypeError("unexpected attribute type %s for %s" % (type(attr).__name__, repr(attr)))
attrs.append("%s=%s" % (attrname, quote_xml_attr(attr)))
out.write(" " * indent + "<" + tag_name)
The difference is obvious: the second calls attrs.append() even if attr
is None. I don't know what point you're trying to make.
On Thu, 29 Aug 2024 14:05:41 +0200, David Brown wrote:
... put in so much extra
crap and silliness that readers get caught up in that instead of
noticing that most of the function is meaningless.
Interesting. Now you are trying to claim that, because you don’t
understand what the code does, that makes it somehow “meaningless”?
On 31/08/2024 01:49, Lawrence D'Oliveiro wrote:
Interesting. Now you are trying to claim that, because you don’t
understand what the code does, that makes it somehow “meaningless”?
I covered that in an earlier post.
On Sat, 31 Aug 2024 17:06:05 +0200, David Brown wrote:
On 31/08/2024 01:49, Lawrence D'Oliveiro wrote:
Interesting. Now you are trying to claim that, because you don’t
understand what the code does, that makes it somehow “meaningless”?
I covered that in an earlier post.
Maybe in your mind you thought you did. Nowhere in your comments on this
code did you say so, that I can find.
I changed it in a re-write to:
def register_additional_standard(self, managed_objects) :
if managed_objects :
# ....
On Tue, 3 Sep 2024 10:46:55 +0200, David Brown wrote:
I changed it in a re-write to:
def register_additional_standard(self, managed_objects) :
if managed_objects :
# ....
My original was meant with future extensibility in mind. That was made
clear in the docstring. You *did* read the docstring, didn’t you?
On Thu, 29 Aug 2024 14:24:01 +0200, David Brown wrote:
def foo(a, b, c) :
if a :
if b :
if c :
doThis()
That looks unfinished to me. So I will add a "return" at the end (with
a single tab indent, in this case).
A redundant “return” ... kind of like my redundant “#end” comments, except
yours work in a more restricted set of places ...
Don't you ever just accept that a language is the way it is, and it is
perfectly useable that way?
Of course not.
Or think that perhaps other people in the world know better than you do
about how they want their language to work?
And vice versa.
Has it never occurred to you that the people behind a given
language - such as Python - considered various alternatives and decided
that making it the way they did was the best choice overall for the
language they wanted?
Barring a few obvious stupidities, yes of course they were, and are, smart people.
Subjectively, I prefer early returns over nested ifs:
On 29/08/2024 18:44, Janis Papanagnou wrote:
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:[...]
[...]
Then don't use vim - use an editor that suits your needs.
But what makes you think that his needs are not covered by Vim?
You seem to have missed the point - sorry if I was not clear.
He complained that he didn't want to learn complicated macros in Vim
just to be able to indent or un-indent lines of code. The solution is obvious - he should use an editor other than Vim.
He could, of course, learn how to use Vim. It's a perfectly good editor
with a lot of features. [...]
There are more than enough decent editors to choose from, that cover the basic needs of programmers. Some people use one editor for everything, others use a range for different purposes - whatever suits you. But it
is pretty absurd to complain that it is difficult to indent code just
because you (i.e., Muttley) think it is hard to do in one particular
editor.
On Thu, 29 Aug 2024 18:44:35 +0200, Janis Papanagnou wrote:
Vim is an editor that has the most simple and also very powerful
indenting for well structured data and programs I've yet seen. (Not
mentioning its equally powerful other editing facilities.)
Vim is only good for text-editing, though.
It assumes a file is split into
lines. Emacs makes no such assumption, and can also edit non-text files.
On Fri, 30 Aug 2024 08:14:21 -0700
John Ames <commodorejohn@gmail.com> gabbled:
[...]Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just
weird.
Some insecure people feel an attack on their favourite language is some kind of attack or slight against them personally. Its a pathetic and juvenile trait
that unfortunately is found a lot amongst IT types.
On 30.08.2024 21:20, Muttley@dastardlyhq.com wrote:
On Fri, 30 Aug 2024 08:14:21 -0700
John Ames <commodorejohn@gmail.com> gabbled:
[...]Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just
weird.
Some insecure people feel an attack on their favourite language is some kind >> of attack or slight against them personally. Its a pathetic and juvenile >trait
that unfortunately is found a lot amongst IT types.
It's not restricted to languages or IT-stuff; you can see it with
books or films or music or political or religious preferences...
On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
Emacs makes no such assumption, and can also edit non-text files.
You have obviously no clue.
On Sat, 14 Sep 2024 10:06:12 +0200, Janis Papanagnou wrote:
On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
Emacs makes no such assumption, and can also edit non-text files.
You have obviously no clue.
I have actually used it for that. That’s my “clue” to you.
LDO: >> Vim is only good for text-editing, though.On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it
possible to edit a binary or executable file.
On Sat, 14 Sep 2024 19:10:06 GMT, Scott Lurndal wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it
possible to edit a binary or executable file.
Wow, a special mode just to edit binary files, when Emacs can do it in
its regular mode.
It just sets a bunch of options to minimize the chance of screwing up
the file in ways you don’t want. Apart from that, it’s still editing
it as a text file.
On Sat, 14 Sep 2024 19:10:06 GMT, Scott Lurndal wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it
possible to edit a binary or executable file.
Wow, a special mode just to edit binary files
LDO: >> Vim is only good for text-editing, though.
Janis:> You have obviously no clue.
Janis is correct, you have no clue
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it possible to edit a binary or executable file.
On 30.08.2024 21:20, Muttley@dastardlyhq.com wrote:
On Fri, 30 Aug 2024 08:14:21 -0700
John Ames <commodorejohn@gmail.com> gabbled:
[...]Sure - but picking one that best suits your needs doesn't mean you
can't critique its annoyances/flaws. This team-sports mentality is just
weird.
Some insecure people feel an attack on their favourite language is some kind >> of attack or slight against them personally. Its a pathetic and juvenile trait
that unfortunately is found a lot amongst IT types.
It's not restricted to languages or IT-stuff; you can see it with
books or films or music or political or religious preferences...
In IT we had as well various "wars" in the past. More considerate
folks avoid such wars (and respect diversity of thoughts/opinions
and preferences) by focusing on the facts alone. Other folks feel
an urge to (unnecessarily) ignite them.
On 29.08.2024 21:36, David Brown wrote:
On 29/08/2024 18:44, Janis Papanagnou wrote:
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:[...]
[...]
Then don't use vim - use an editor that suits your needs.
But what makes you think that his needs are not covered by Vim?
You seem to have missed the point - sorry if I was not clear.
He complained that he didn't want to learn complicated macros in Vim
just to be able to indent or un-indent lines of code. The solution is
obvious - he should use an editor other than Vim.
This is not what I'd call a solution. I'd call it elusion; and in both
senses - if he didn't use his editor for that space-indenting because
he doesn't know how to do it he could look that up, but it is not any
issue to do that, only more laborious than indenting brace structures,
and the suggestion to switch to another tool is also elusive because
it doesn't address the issue (he would still have to learn how to do
it in any other tool). - But that was not the point.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Sat, 14 Sep 2024 19:10:06 GMT, Scott Lurndal wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it >>> possible to edit a binary or executable file.
Wow, a special mode just to edit binary files
So, you admit you were wrong. You again elided the con-text that showed
you were incorrect. Dishonest of you, to be sure, yet typical of your
posts.
You again elided the con-text that showed you were incorrect.
On 14/09/2024 09:59, Janis Papanagnou wrote:
On 29.08.2024 21:36, David Brown wrote:
On 29/08/2024 18:44, Janis Papanagnou wrote:
On 29.08.2024 14:30, David Brown wrote:
On 29/08/2024 09:28, Muttley@dastardlyhq.com wrote:[...]
[...]
Then don't use vim - use an editor that suits your needs.
But what makes you think that his needs are not covered by Vim?
You seem to have missed the point - sorry if I was not clear.
He complained that he didn't want to learn complicated macros in Vim
just to be able to indent or un-indent lines of code. The solution is
obvious - he should use an editor other than Vim.
This is not what I'd call a solution. I'd call it elusion; and in both
senses - if he didn't use his editor for that space-indenting because
he doesn't know how to do it he could look that up, but it is not any
issue to do that, only more laborious than indenting brace structures,
and the suggestion to switch to another tool is also elusive because
it doesn't address the issue (he would still have to learn how to do
it in any other tool). - But that was not the point.
This thread died out two weeks ago, and should have been left there.
On Sat, 14 Sep 2024 22:25:53 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boringly babbled:
[...]
Any sane person uses a dedicated hex editor to edit binary files, not vim
or emacs.
On Sat, 14 Sep 2024 10:06:12 +0200, Janis Papanagnou wrote:
On 30.08.2024 04:53, Lawrence D'Oliveiro wrote:
Emacs makes no such assumption, and can also edit non-text files.
You have obviously no clue.
I have actually used it for that. That’s my “clue” to you.
On Sat, 7 Sep 2024 18:30:03 -0000 (UTC), candycanearter07 wrote:
Subjectively, I prefer early returns over nested ifs:
Nested ifs nest, early returns don’t.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:48 this Saturday (GMT):
On Sat, 7 Sep 2024 18:30:03 -0000 (UTC), candycanearter07 wrote:
Subjectively, I prefer early returns over nested ifs:
Nested ifs nest, early returns don’t.
Right, they remove some nesting which makes it easier to read.
On Thu, 26 Sep 2024 18:00:09 -0000 (UTC), candycanearter07 wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 22:48 this Saturday (GMT):
On Sat, 7 Sep 2024 18:30:03 -0000 (UTC), candycanearter07 wrote:
Subjectively, I prefer early returns over nested ifs:
Nested ifs nest, early returns don’t.
Right, they remove some nesting which makes it easier to read.
Nestability helps with refactorability.
On Sat, 14 Sep 2024 22:25:53 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boringly babbled:
On Sat, 14 Sep 2024 19:10:06 GMT, Scott Lurndal wrote:
$ man vim | grep -i binary
-b Binary mode. A few options will be set that makes it >>> possible to edit a binary or executable file.
Wow, a special mode just to edit binary files, when Emacs can do it in
its regular mode.
The 1980s phoned, they want their editor wars back.
It just sets a bunch of options to minimize the chance of screwing up
the file in ways you don’t want. Apart from that, it’s still editing
it as a text file.
Any sane person uses a dedicated hex editor to edit binary files, not vim
or emacs.
On 2024-08-19 16:59, Muttley@dastardlyhq.com wrote:
On Mon, 19 Aug 2024 12:39:33 +0200
Initially an ability to trim the system and sometimes to patch a driver
was a huge advantage Linux had over Windows NT.
Linux can also load and unload drivers on the fly unlike Windows which AFAIK >> still requires a reboot each time.
I was talking about monolithic kernel Linux had in 90's. Plug and play, kernel modules came much later with much bigger machines. I ran Linux on i386 25MHz 4Mb. Try it now.
On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
And you don't need to know anything about Linux, UNIX or POSIX to
program in C.
I think the point has been made on comp.lang.c more than once, that C without POSIX can be a very dull language indeed ...
Any sane person uses a dedicated hex editor to edit binary files, notEmacs has the hexl-mode. Emacs isn't just an editor, it's an Elisp
vim or emacs.
platform.
On 2024-08-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 21 Aug 2024 09:26:41 +0200, David Brown wrote:
And you don't need to know anything about Linux, UNIX or POSIX to
program in C.
I think the point has been made on comp.lang.c more than once, that C
without POSIX can be a very dull language indeed ...
... you can do a lot with C99.
Albeit I prefer Elisp and Common Lisp.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,070 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 161:07:08 |
| Calls: | 13,734 |
| Calls today: | 2 |
| Files: | 186,966 |
| D/L today: |
843 files (303M bytes) |
| Messages: | 2,418,725 |