Axy 在 2022年10月8日 星期六上午11:39:44 [UTC+8] 的信中寫道：

Hi there,

this is rather a philosophical question, but I assume I miss something.
I don't remember I ever used else clause for years I was with python and
my expectation was it executed only if the the main body was never run. Ha-ha! I was caught by this mental trap.

So, seriously, why they needed else if the following pieces produce same result? Does anyone know or remember their motivation?

Just curious.

Axy.

print('--- with else')

for i in [1,2,3]:
print(i)
else:
print(4)

for i in []:
print(i)
else:
print(5)

print('--- without else')

for i in [1,2,3]:
print(i)
print(4)

for i in []:
print(i)
print(5)

The else is always coming with the break, not the for. There are [for ...], [for...break...], and[for...break...else], but the [for...else] is insane.

--Jach

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Got it, thanks!

Actually the reason I never used "else" was the violation of the rule of
beauty "shortest block first". With if--else you can easily follow this
rule by inverting "if" expression, but with for--else you can't. The
loop body of the simplest example is already three lines, in real life
things are much worse.

So it was probably the first time I used "else" because I had only one
line in my loop which appended data packets to the buffer and if "else"
behaved as I thought it would meant I have no more data and could just
return early, terminating outer loop with no other boolean logic.

I have no idea why I thought so, some language might had such a
semantic. Maybe my own I developed 20 years ago, but I could not invent
that by myself, I definitely had some source of inspiration.

Python is awesome because it's semantic is clear for the majority, but
there are places that look odd. In case of "for", "else" looks logically
tied with "for" clause, but actually it is not. It's tied with "break" statement and I overlooked that even after re-reading the language
reference. If "else" was named like "never_broken_loop" or "nobreak",
the semantic would be perfectly clear. But, what's done is done.

I guess the real motivation was avoiding moving such patterns to a
separate functions, say, "find_banana" where early returns make "else" absolutely unnecessary.

Cheers.

Axy.


On 08/10/2022 06:49, rbowman wrote:

On 10/7/22 21:32, Axy wrote:

So, seriously, why they needed else if the following pieces produce
same result? Does anyone know or remember their motivation?

In real scenarios there would be more logic in the for block that
would meet a condition and break out of the loop. If the condition is
never met, the else block runs. To steal from w3schools:

fruits = ["apple", "peach", "cherry"]
for x in fruits:
  print(x)
  if x == "banana":
    break
else:
  print("Yes we got no bananas")

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list <python-list@python.org> wrote:

Got it, thanks!

Actually the reason I never used "else" was the violation of the rule of beauty "shortest block first". With if--else you can easily follow this
rule by inverting "if" expression, but with for--else you can't. The
loop body of the simplest example is already three lines, in real life
things are much worse.

That's not a rule I've ever been taught; how important is it?

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/10/2022 05:47, Chris Angelico wrote:

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list <python-list@python.org> wrote:

Got it, thanks!

Actually the reason I never used "else" was the violation of the rule of
beauty "shortest block first". With if--else you can easily follow this
rule by inverting "if" expression, but with for--else you can't. The
loop body of the simplest example is already three lines, in real life
things are much worse.

That's not a rule I've ever been taught; how important is it?

ChrisA

It gets important if the lifetime of your project is more than three
months and is extremely important if more than 10 years. But, it depends.

I also might be wrong in terminology, anyway, there are many rules that
make programmer's life easier, described in the literature from the old
good "How to write unmaintainable code" to "The Art of Readable Code".
And I hope there are a lot of recent books on this subject I did not
track and read yet.

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 9 Oct 2022 at 16:05, Axy via Python-list <python-list@python.org> wrote:

On 09/10/2022 05:47, Chris Angelico wrote:

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list <python-list@python.org> wrote:

Got it, thanks!

Actually the reason I never used "else" was the violation of the rule of >> beauty "shortest block first". With if--else you can easily follow this
rule by inverting "if" expression, but with for--else you can't. The
loop body of the simplest example is already three lines, in real life
things are much worse.

That's not a rule I've ever been taught; how important is it?

ChrisA

It gets important if the lifetime of your project is more than three
months and is extremely important if more than 10 years. But, it depends.

Yes, I'm aware that code readability becomes irrelevant for
short-duration projects. Beside the point. I'm wondering how important
it really is to have the shortest block first.

I also might be wrong in terminology, anyway, there are many rules that
make programmer's life easier, described in the literature from the old
good "How to write unmaintainable code" to "The Art of Readable Code".
And I hope there are a lot of recent books on this subject I did not
track and read yet.

Also not really a justification for "shortest block first". Wanting
some elaboration on that. What's the value in it?

Given that for-else is an excellent, if rarely-used, construct, I
would say that, *at least*, it is worth setting aside this rule for
that particular situation. It is also generally worth using fewer
commas than I just did. Take my advice with a grain of salt.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/8/22 22:37, Axy wrote:

Python is awesome because it's semantic is clear for the majority, but
there are places that look odd. In case of "for", "else" looks logically
tied with "for" clause, but actually it is not. It's tied with "break" statement and I overlooked that even after re-reading the language
reference. If "else" was named like "never_broken_loop" or "nobreak",
the semantic would be perfectly clear. But, what's done is done.

It is sort of an overload for else. It does save an explicit test. For
example, in C

for (i-0; i<length; i++)
{
....
}

if (i == length)
{
what ever you though might happen didn't
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Yes, I'm aware that code readability becomes irrelevant for
short-duration projects. Beside the point. I'm wondering how important
it really is to have the shortest block first.

I also might be wrong in terminology, anyway, there are many rules that
make programmer's life easier, described in the literature from the old
good "How to write unmaintainable code" to "The Art of Readable Code".
And I hope there are a lot of recent books on this subject I did not
track and read yet.

Also not really a justification for "shortest block first". Wanting
some elaboration on that. What's the value in it?

Well, the value is productivity. No need to save puzzles "what this
hanging else belongs to?" regardless of semantic, which ideally should
not be a puzzle as well. Code small things first and return early, same
as taking a test: do easy and quick things first and boring and
difficult ones later.

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-09 05:37:59 +0100, Axy via Python-list wrote:

Actually the reason I never used "else" was the violation of the rule
of beauty "shortest block first".

That's a weird rule.

I can see justifications for "most common case first" and "most special
case first", but ordering the cases in an if/elif/else statement by
length seems like ordering books by color: It may be pretty, but it
doesn't make them easy to find.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNCgmYACgkQ8g5IURL+ KF13bQ//cu0XgETVC0mbiLPjDeVAOmCUKTsbZtn9JF30RPRf5p62OcuaR7RDfatR /0zLdMXSUyLj8DtUvTWUXssE9qYVzX/Wgf56J0XaB5N+wp7iVjtYTVcV+/6yDqCC D/qqw6XNyJQF002LoYlQbU+Xf3D4R6beCYF9q3g2Wa1OmtlZkp9xF6o42EyNm3It 7gz3cIyYgUbNY5X8Cfs5Qoneg+sLRA8dSUQ1tc1XIsr3N6mxKxWJq9tUeq1AiCO+ Aw40l0UCWh6XWdYZxRm6Fbm6X3shmQRHUwGqq2VjQVD1aCI5RTFFqY9ZbXxDTx3T 6ZCIWycdzcea4SH8HTk9sRebuPwZxyUrrUzPn3GQjRrSbGsRHAMtTeC6D6y10PUn IMJ3Eqeue5ufsqCVFBSOKNSRHHsvu5fuuGFwEaRpbvQv4oOHgwgA1v+EnUEqGmDQ OXpxvpdBSKTXlfLmuxiYxw7wOKYXsZXGJYOlWWqpVVlL5L7BBPlGhDzj2Rq2Lq41 z/gW57HJfv3yaBVUQ9vd+KOkCZkSGAP7j+MSvo5vpo6j4oVoW3/uAafiUobNuKiH HkfC07O4Hw14kpoUwAZtTgjvVjluY0Hq5TEDotEvdRvQNBsnt6BNZr82YDnn8Sa9 42G25iF7L9zx2QG2xZ+WC7N4Ul7QU5dj0UC4iiM

Axy <axy@declassed.art> writes:
[I can't find an attribution line in Axy's post here]
...

Also not really a justification for "shortest block first".

Well, the value is productivity. No need to save puzzles "what this
hanging else belongs to?" regardless of semantic, which ideally should
not be a puzzle as well.

I often follow this rule. For me, it's about readability. Compare:

if not open( disk ):
error( "Can't open disk" )
else:
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )

with

if open( disk ):
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
printf( "now imagine there's some larger block here" )
else:
error( "Can't open disk" )

.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Well, the value is productivity. No need to save puzzles "what this
hanging else belongs to?"

if you get to the point where it's hard to tell which else lines up with
which if or for statement, I would suggest breaking things out into
well-named helper functions rather than worrying over ordering by block size


On Sun, Oct 9, 2022 at 2:26 AM Axy via Python-list <python-list@python.org> wrote:

Yes, I'm aware that code readability becomes irrelevant for
short-duration projects. Beside the point. I'm wondering how important
it really is to have the shortest block first.

I also might be wrong in terminology, anyway, there are many rules that
make programmer's life easier, described in the literature from the old
good "How to write unmaintainable code" to "The Art of Readable Code".
And I hope there are a lot of recent books on this subject I did not
track and read yet.

Also not really a justification for "shortest block first". Wanting
some elaboration on that. What's the value in it?

Well, the value is productivity. No need to save puzzles "what this
hanging else belongs to?" regardless of semantic, which ideally should
not be a puzzle as well. Code small things first and return early, same
as taking a test: do easy and quick things first and boring and
difficult ones later.

Axy.
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Smallest code blocks first may be a more modern invention.

Some would argue for a rule related to efficiency of execution. When you
have multiple blocks as in an if-else or case statement with multiple
choices, that you order the most common cases first. Those shorten
execution more often than the rarer cases especially the ones that should
never happen.

There are obvious exceptions like the default having to be last, albeit
some languages allow the default to be inserted anywhere visually even if
the code sort of runs last.

But negating a condition so smaller code appears first may have some cost.
I mean if !function() may be slower as the negating is an extra step. But
it may be even slower if the inversion is done using a wrapper function
that simply inverts the return value from the other function.

I think sometimes a comment placed carefully that explains the code and
logic in concise form is a simpler approach that can be followed by a big
chunk then little chunk without loss of readability.

In the original example the else part can be mentioned before the loop as a sort of reminder.

In my experience, the size of code often varies within a project so a
smaller chunk may grow as requirements change, such as adding debug or
logging, and large chunks can shrink as common parts of the code get
extracted into functions.

So not a rule but realistically not always a bad idea to write code in a
way that draws the attention of readers along the main path of execution
and perhaps not showing all the checking for odd cases first. I mean as an example if the argument is of type text then do stuff, else if a number
else if a symbol else if empty ...

On Sun, Oct 9, 2022, 1:18 AM Chris Angelico <rosuav@gmail.com> wrote:

On Sun, 9 Oct 2022 at 16:05, Axy via Python-list <python-list@python.org> wrote:

On 09/10/2022 05:47, Chris Angelico wrote:

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list <

python-list@python.org> wrote:

Got it, thanks!

Actually the reason I never used "else" was the violation of the rule

of

beauty "shortest block first". With if--else you can easily follow

this

rule by inverting "if" expression, but with for--else you can't. The
loop body of the simplest example is already three lines, in real life >> things are much worse.

That's not a rule I've ever been taught; how important is it?

ChrisA

It gets important if the lifetime of your project is more than three
months and is extremely important if more than 10 years. But, it depends.

Yes, I'm aware that code readability becomes irrelevant for
short-duration projects. Beside the point. I'm wondering how important
it really is to have the shortest block first.

I also might be wrong in terminology, anyway, there are many rules that make programmer's life easier, described in the literature from the old good "How to write unmaintainable code" to "The Art of Readable Code".
And I hope there are a lot of recent books on this subject I did not
track and read yet.

Also not really a justification for "shortest block first". Wanting
some elaboration on that. What's the value in it?

Given that for-else is an excellent, if rarely-used, construct, I
would say that, *at least*, it is worth setting aside this rule for
that particular situation. It is also generally worth using fewer
commas than I just did. Take my advice with a grain of salt.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, Oct 09, 2022 at 05:37:59AM +0100 schrieb Axy via Python-list:

Python is awesome because it's semantic is clear for the majority, but there are places
that look odd. In case of "for", "else" looks logically tied with "for" clause, but
actually it is not. It's tied with "break" statement and I overlooked that even after
re-reading the language reference. If "else" was named like "never_broken_loop" or
"nobreak", the semantic would be perfectly clear. But, what's done is done.

Or, "eventually". Sadly, "finally" is already taken, and with
slightly different semantics...

Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Oct 2022 at 03:22, Avi Gross <avi.e.gross@gmail.com> wrote:

Smallest code blocks first may be a more modern invention.

Some would argue for a rule related to efficiency of execution. When you
have multiple blocks as in an if-else or case statement with multiple choices, that you order the most common cases first. Those shorten
execution more often than the rarer cases especially the ones that should never happen.

Seems fairly dubious and full of special-cases. If you want to follow
that rule, it should be easy enough to still permit for-else clauses.
It's an extremely weak argument against for-else.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Since many languages allow placing multiple statements on one line or
spreading one over many lines, it seems that the number of lines in code
can be adjusted.

If I have a line like:

Alpha, beta, gamma, delta = 1, 2, 3, 4

Could that be rewritten as 4 or more lines?

I have seen programmers who have taken an elegant pipeline I have built
apart and made it into many lines of code reassignment the value of each
step to the same or different variables and other ways of lengthening or obscuring my intent.

So although size may matter, so can sighs.

On Sun, Oct 9, 2022, 4:24 AM Peter J. Holzer <hjp-python@hjp.at> wrote:

On 2022-10-09 05:37:59 +0100, Axy via Python-list wrote:

Actually the reason I never used "else" was the violation of the rule
of beauty "shortest block first".

That's a weird rule.

I can see justifications for "most common case first" and "most special
case first", but ordering the cases in an if/elif/else statement by
length seems like ordering books by color: It may be pretty, but it
doesn't make them easy to find.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris, I was not arguing that at all.

I was saying some rationales about how to order choices exist based on
ideas like efficiency or other considerations. Sometimes people are
mistaken as something may take constant time as implemented. And yes, many rules have countless exceptions. For example, if something is expected to rarely or never happen, code within that branch may not be needed to be optimized in any way as long as it works in the remote chance it is called.

I think what was suggested here is more about code readability
considerations and for some of us, making us stand on our heads to puzzle things out is harder than ordering longer items ...

On Sun, Oct 9, 2022, 12:30 PM Chris Angelico <rosuav@gmail.com> wrote:

On Mon, 10 Oct 2022 at 03:22, Avi Gross <avi.e.gross@gmail.com> wrote:

Smallest code blocks first may be a more modern invention.

Some would argue for a rule related to efficiency of execution. When you have multiple blocks as in an if-else or case statement with multiple choices, that you order the most common cases first. Those shorten execution more often than the rarer cases especially the ones that should never happen.

Seems fairly dubious and full of special-cases. If you want to follow
that rule, it should be easy enough to still permit for-else clauses.
It's an extremely weak argument against for-else.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Oct 2022 at 03:46, Avi Gross <avi.e.gross@gmail.com> wrote:

Chris, I was not arguing that at all.

Maybe not intentionally, but you did lend a lot of weight to that argument :)

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Since many languages allow placing multiple statements on one line or spreading one over many lines, it seems that the number of lines in code
can be adjusted.

If I have a line like:

Alpha, beta, gamma, delta = 1, 2, 3, 4

Could that be rewritten as 4 or more lines?

Surely! Especially if you're paid for SLOC :-)))

By the way, does "else" clause after affect cyclomatic complexity
metric? I mean "for" loops.

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-09 12:18:09 -0400, Avi Gross wrote:

Smallest code blocks first may be a more modern invention.

Some would argue for a rule related to efficiency of execution. When you
have multiple blocks as in an if-else or case statement with multiple choices, that you order the most common cases first. Those shorten
execution more often than the rarer cases especially the ones that should never happen.

Those of us who started programming on 8 bit homecomputers of course
have efficiency always at the back of their heads, but I find this

So not a rule but realistically not always a bad idea to write code in a
way that draws the attention of readers along the main path of execution
and perhaps not showing all the checking for odd cases first.

much more important. Putting the main path first makes it easier to
understand what the code is supposed to do normally. All those pesky
exceptions are in the "small print" below.

There is of course the opposite view that you should just get all of the confounding factors out of the way first, so that the default is also
the common case. I also do that sometimes, but then I don't hide this in
in an else: clause but do something like this:

for item in whatever:
if not_this_one(item):
continue
if neither_this_one(item):
continue
if cant_continue(item):
break
if oopsie():
raise SomeError()

do_something_with(item)
and_some_more(item)
we_are_done(item)

which shows visually what the main purpose of the loop (or function or
other block) is.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNC/TkACgkQ8g5IURL+ KF3dgw//Q6zXk6gMhVWsLIjO3eONKhAKejjVo0nJg6H1EKEy6OuCf+5HmlzH3dal x9wtwIt/g/esmU4MVsOeZcayHK8JfztzLj5FrDxswYGnVH/KFXE+1GYar+Z8pRaA VA2u0lxGscLJgcLVcaRTqRNX3LHpCbfb4VbN51sS3Gr0eHvqi0DYgFRd6nqs+bA7 3pCF+vZM8TtiWr2Nzj8yOYgR5HafWEnmQJ30X9vPg4zArsD242GfpKPtAxoAknum jCIMqrDfR19GkW5Nr9y5jhObwlvGbQflhT9P7yJbMIBgIaWsl9TDjZ8GLY8Ib8D8 FufwA91F6Ta+sbfO0JO/sJGGUJbdoXP3r6/P+M6fCLFqkIox9eZShTfYEZP5MAsg kzgj2fBeg+b9NW8Q5vWHIWgvzgQx8jRKdbrVFE07KRMmpTFkTcXjPm/IfNIecDFA Tdqw9CI1k3wY1p8pQefVICnpsdvzmE9zqHJI5gNwSB2EKeqX6T120qlxMQLc/N/m G/kMserAfgM6N3qTV/Au06zDr0vdLtJzxgKgvSqmbf9FKdMFGQfqxtTPr4RnE8Ie 1iDA/1j5Nxu23iPthJFweUU38P3C4yayKfNeCfv0AdXokxXsj5LBZCWaQVtuvvRq ZbWFWHOl0LldVokLKtAIwTJPrw3FOzJ0Ant07Ky

On 2022-10-09 12:34:22 -0400, Avi Gross wrote:

I have seen programmers who have taken an elegant pipeline I have built
apart and made it into many lines of code reassignment the value of each
step to the same or different variables and other ways of lengthening or obscuring my intent.

I have certainly done that (not with your code, AFAIK). The problem with
those beautiful one-liners is that they are really hard to debug. So if
I can't convince myself that they are correct just by reading them I
have to split them over multiple lines so I can add breakpoints or log messages. Of course I could put it together again afterwards, but I
would argue that if I didn't understand it the first time it's probably
better to leave it in its more verbose and debuggable state.

Of course I have also done the opposite: Taken some messy and
complicated code and simplified it into a simple generator expression.
In fact I would say that I code tends to be shorter after I fixed a bug
than before.

So although size may matter, so can sighs.

:-)

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNDAWEACgkQ8g5IURL+ KF0IkBAAhFsl0npKHblrQ0mQ+LQdQlQoqcTNbY7FX9QtURhEOO7LPkzfs0sELd/Y D6PPn+Kovu5xdO4CYXATvA71YeFfJcKL0MOkoMcVTZ6vKoi3tjw/G+v5QgCIA8Jj hci6rL+3Qbo0G8uep3XENxB1tydsCGqt4PPJ4grge8vbvAunhvRuY8XsfR2tTzwY 99Yz+Cu6VqEk+ZmBD4B6JoAy2S90x8azx0YhDmD169cA3CbRr6pblYNTGUzpgmp+ eHh/1lmAZYeWYMu/dcBwaNrKe1kT0hEIxFUonAx1skB9bPLV3ax2OmA5If5AZSaI tQpTwoOKPjjbiJ+nzN5xT+dijmhfPUQETy7pRuKIIHDSTHRKUQJK410XzjT5kMK0 Er0iY/MnH+ZDrpIsqA01128/Opaczq5SVXIZheoTKgWiY1IpaGgHAceByHSOwufL ZJ46noqdC38dLQpaO+ps3/skyu1HrW9n3Cbi+FjI6RJ+WRZr8Q9BzkOOGdMnrdkG 68uiYOny7NEGmAAYuKjzKe3++lM5emP2RB4e8XvNUyU/Iv8K9iueGtZSiYp9gx3m xL5iuurzQkky1Sgr7+hRnk7UXIR74wVllulEV26dJJyZQTU/pa8thJhK4H7UjlER 35I3k3MtGPWOolchNuda/J6G2FGhRZ2ncvT/Ekf

Fair enough, Chris. There may be some overlap with the size of code for the most common cases but sometimes the opposite as those may be more complex
to deal with.

A reality for many programmers today is to not micromanage too early as
things are often fast enough and any tweaking is best done only in critical areas. The emphasis may be on the programmer experience in writing fast
code with fewer errors. Perhaps secondary but often important is making the code maintainable and in my experience that can often be best done by
choosing meaningful names and brief selective comments than by worrying
about the size of blocks of code.

But others obviously preach what they think works for them even when it may constrain others more than it helps.

I have seen people suggest that all variables have short names like a3 but
that does not mean it improves anything other than the size of the code and parsing it. The loss in readability and so on probably is worse.


On Sun, Oct 9, 2022, 12:53 PM Chris Angelico <rosuav@gmail.com> wrote:

On Mon, 10 Oct 2022 at 03:46, Avi Gross <avi.e.gross@gmail.com> wrote:

Chris, I was not arguing that at all.

Maybe not intentionally, but you did lend a lot of weight to that argument
:)

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Peter,

There can be excellent reasons to undo a pipeline like I described. I often write it carefully in smaller chunks while debugging and make it more
elegant later ...

But someone amused me by explaining they were going to let people believe
the code was written by them so it had to fit their style and abilities.
That meant removing most of my comments, renaming some variables, taking
out code that checked things like whether a file existed before opening it
and of course no pipelines. It had to be downgraded and had I known, I
could have easily given them code written as if it was in some poorer
language.

Python has idioms often used in making pipes of a sort but in languages
with other forms, such as R, debugging is not that difficult as you can
insert functions in middle of a pipeline that print what you want but
return the data structure they were fed for the next step in the pipeline.
When done, remove the lines with such entries or change the function
definition or something like that.

Objects used as pipelines do not do this as easily as you may need to add methods ...


On Sun, Oct 9, 2022, 1:17 PM Peter J. Holzer <hjp-python@hjp.at> wrote:

On 2022-10-09 12:34:22 -0400, Avi Gross wrote:

I have seen programmers who have taken an elegant pipeline I have built apart and made it into many lines of code reassignment the value of each step to the same or different variables and other ways of lengthening or obscuring my intent.

I have certainly done that (not with your code, AFAIK). The problem with those beautiful one-liners is that they are really hard to debug. So if
I can't convince myself that they are correct just by reading them I
have to split them over multiple lines so I can add breakpoints or log messages. Of course I could put it together again afterwards, but I
would argue that if I didn't understand it the first time it's probably better to leave it in its more verbose and debuggable state.

Of course I have also done the opposite: Taken some messy and
complicated code and simplified it into a simple generator expression.
In fact I would say that I code tends to be shorter after I fixed a bug
than before.

So although size may matter, so can sighs.

:-)

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-09 15:32:13 -0400, Avi Gross wrote:

and of course no pipelines.

Since you've now used that term repeatedly: What is a pipeline in
Python?

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNDKM8ACgkQ8g5IURL+ KF1GTBAAjuAKhSNLc/aLTmzwT8r7Jqt7mEzt0LyIue4PoMUl4FFgEclOtrPWLguB BITsmuhjK/a3eD5JiUlby0nJiHTWAvmjZllLCGGX0A2F/9wId+7JKozsxOKQWSI5 mgWK3hTx7cyMqy8zpovJBUuXwVlrdFMsMzG4yOnv3XmA2U7rL8LZX/rs7fMwg3OV fNJOYYHFVWWsGyBJNuw/I2xUJ5LW7OP2qBz257VvSyrEaAdz2svJbOChzZVBwx1+ GD9WhCbCgRoAHsNNZtILjVZt9PhcNcE9u/J5ueLx0iGbN5fF0HgYOqa24b+4wudt gBZR+HgDv0PRIfOTvyL/U+0f/sye7m1+GxbCA0PvANPV47nVevdCJ0+Ly4/dh1n7 mYyPH7sR62tuzae72X04WnkodQ/lob5JHTFrYdhxWr6KdkkeZ4YffCEyTxfLf8Cs 3ZkuBm6BqbbDR+T278b5e3FswVq/PtzZqZUVpF3RZLWCSIo/IcNgtskSwz81QQw+ f3CAVKCB/ajNkVv/PJEmmI4Li4/eHsHPOj99u/crTeNhmWnNETuFdcF3YBqrZBF0 ERX7aOqZg34RnCfi1RVJ4ouLbg6iCNJ0vXQoqlvU3jzw+K+ZQjFuvTvEl+WR1ns5 pTEWTydOfKRFAM5NEp/tCh9TWd0THLunb2EZ/jm

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
<python-list@python.org> wrote:

"shortest block first"

Have never heard this advice before. Kind-of rankled with me, as it did
for others.

Enquiring minds want to know... Played Duck, duck, go on this: zero hits amongst a pile of similar phrases - turns-out there's an algorithm with
a similar name, but not related, and an electronics approach (way too
'low' a level for translation to us though).

Tried prefixing with "program" but no such advice to programmers or
program[me] designers.

Tried prefixing with "python", but equal lack of joy.

Would OP please quote source?


On 10/10/2022 05.56, Peter J. Holzer wrote:

On 2022-10-09 12:18:09 -0400, Avi Gross wrote:

Smallest code blocks first may be a more modern invention.

None of the recent-grads or new-hires I've asked this morning (it's
already Monday over-here!) have used or heard the term.

Some would argue for a rule related to efficiency of execution. When you
have multiple blocks as in an if-else or case statement with multiple
choices, that you order the most common cases first. Those shorten
execution more often than the rarer cases especially the ones that should
never happen.

Those of us who started programming on 8 bit homecomputers of course
have efficiency always at the back of their heads, but I find this

... for mainframes just as much as micro-computers!

Regarding execution-efficiencies, I'm sure @Avi knows better than I: It
seems likely that Python, as an interpreted language, will create
'blocks' of its virtual-machine code in the same order as they appear in
the Python-source. However, aren't there optimising compilers which do something intelligent with the equivalent clauses/suites in other languages?

Regardless, is a Jump-instruction which transfers else-control to a
block five machine-instructions 'down', any less efficient than a jump
which spans 50-instructions?

So not a rule but realistically not always a bad idea to write code in a
way that draws the attention of readers along the main path of execution
and perhaps not showing all the checking for odd cases first.

much more important. Putting the main path first makes it easier to understand what the code is supposed to do normally. All those pesky exceptions are in the "small print" below.

Absolutely! Has the term "readability" been used 'here'?

Human nature (or is it that of computer programmers in-particular) is to
be optimistic: it will work [this time*]. Accordingly, a colleague talks
of always coding 'the happy line' first (meaning line of logic, cf source-code).

Contrarily, for while-True (infinite) loops, and particularly recursive algorithms, the [wise] counsel is to code the end-condition first.
(always know your closest exit! "The nearest exit may be behind you"...)


Indeed, dare I say, this optimistic-approach is pythonic. Taking an over-simple, two-value division example, the approach is:

try:
a = b / c
except ZeroDivisionError:
... clean-up the mess ...

which contrasts the EAFP philosophy of Python versus the LBYL
expectation of (many) other languages:

assert c != 0
a = b / c

That said, as "Data Science" use of Python expands, it is bringing more
and more needs for an LBYL attitude, eg "data cleaning".

(EAFP, LBYL? https://docs.python.org/3.9/glossary.html)

There is of course the opposite view that you should just get all of the confounding factors out of the way first, so that the default is also
the common case. I also do that sometimes, but then I don't hide this in
in an else: clause but do something like this:

for item in whatever:
if not_this_one(item):
continue
if neither_this_one(item):
continue
if cant_continue(item):
break
if oopsie():
raise SomeError()

do_something_with(item)
and_some_more(item)
we_are_done(item)

which shows visually what the main purpose of the loop (or function or
other block) is.

Nicely stated!

NB I've seen sufficient of @Peter's posts to know that this was never
(even implied to be) intended as a snippet for all occasions!


It also illustrates why such is less readable: because we have to scan
four if-statements before we can 'see' the purpose of the loop. My
'itch' would be to extract this code 'out' to a function - that way the
name will convey the somewhat-obscured purpose of the loop.


Alternately, reduce the 'distractions':-

try:
for item in whatever:
inspect_the_data( item )
do_something_with(item)
and_some_more(item)
we_are_done(item)
except SomeError:
...
except CustomBreakException:
... ?pass? # same effect as break

by 'hiding' in:

def inspect_the_data( item ):
if not_this_one(item):
continue
if neither_this_one(item):
continue
if cant_continue(item):
raise CustomBreakException # was break
if oopsie():
raise SomeError()


It is now easier to understand 'the happy line', ie the thinking of the original-coder, and the 'small print' has been relegated to such and can
be cheerfully disregarded.

Whereas, if 'exceptional circumstances' is the reason one is inspecting
the code in the first-place, then it also helps to have separated-out
the ifs-buts-and-maybes, and into a structure which can be as closely
(and exhaustively) tested, as may be required.


In some ways, (IMHO) there are reasons to feel disquiet over this style
of coding. Learning "Modular Programming", and slightly-later
"Structured Programming", when they were still new (?fresh, ?exciting),
we were inculcated with the 'one way in, one way out' philosophy-of-correctness. This applied to "blocks" of code (per
"module"), as well as formal units, eg functions.

Accordingly, am slightly unnerved by seeing Exceptions being used to
'jump out' of interior/nested blocks, rather than using the
return-mechanism (taking their turn like all the good little boys and
girls). That said, it makes for tidier code - so I'll stop muttering
into my (grey) beard ...


The alternative, assuming the 'errors and omissions' function is a
possible tactic(!), would be to return a boolean, eg

def is_clean_data( item )->bool:
is_verified = False
if ...
...
return is_verified

- thus the do-stuff calls will become a 'successful' if-then 'suite'.


There is more code to write/read - and the toy-example lends itself to
such a tactic. In other situations, perhaps some refactoring or
pre-processing, even a decorator, might remove (or reduce) the need for
so much checking within the loop/block.


When to use one or the other approach?

We could hide behind some 'mystery', and say "I just know from
experience", but that smacks of a secret coin-toss (human 'gut feelings'
not being particularly indicative of success). So, here's a stab at it
which harks back to the learn/use 'COBOL or FORTRAN' [argument] days:

If the purpose/considerations of the for-loop (block), are:-
- data-related: check-first
(and thus consider extract and/or invert to promote readability)
- logic/algorithmic implementation, take 'the happy line' first
(and deal with the exceptions ("small print") later)


Worthy of consideration, is that Python is (still) fast-developing. The switch-case construct of v3.10, and protocols and beefed-up descriptors (?interfaces?) could have quite an impact on such thinking, and in the relatively near-future...


* back in the ?bad old days when testing was something that was (only)
done AFTER coding was complete, ie ego-driven development. The
traditional response to the question: "are you coming to lunch/dinner/supper/break/the party/bed/...?" was "in a moment -
[surely?] there's only one more bug"!


I've been 'dipping into' Martin Fowler's "Refactoring", 2e, Pearson,
2019; but don't have it with me to point to useful references. What I do
have to-hand, because it has just arrived, is Mariano Anaya's "Clean
Code in Python", (also 2e), Packt, 2020* - although I didn't see its
previous edition, and have read nothing beyond the Contents(!) to-date;
it talks of "Design by Contract", "Defensive Programming", "Separation
of Concerns" indicating it may have thinking to offer.

* the reviewer was Tarek Ziadé, author of "Expert Python", which is
worth reading - as are his other works (in English and in French)
--
Regards,
=dn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-10 00:40, dn wrote:

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
<python-list@python.org> wrote:

"shortest block first"

Have never heard this advice before. Kind-of rankled with me, as it did
for others.

Enquiring minds want to know... Played Duck, duck, go on this: zero hits amongst a pile of similar phrases - turns-out there's an algorithm with
a similar name, but not related, and an electronics approach (way too
'low' a level for translation to us though).

Tried prefixing with "program" but no such advice to programmers or program[me] designers.

Tried prefixing with "python", but equal lack of joy.

Would OP please quote source?

[snip]
After a few minutes searching I found this:

https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/CodingGuidelines/CglPhp/PhpFileFormatting/PhpSyntaxFormatting.html

"""It is recommended to create conditions so that the shortest block of
code goes first."""

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Oct 2022 at 11:52, MRAB <python@mrabarnett.plus.com> wrote:

On 2022-10-10 00:40, dn wrote:

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
<python-list@python.org> wrote:

"shortest block first"

Have never heard this advice before. Kind-of rankled with me, as it did
for others.

Enquiring minds want to know... Played Duck, duck, go on this: zero hits amongst a pile of similar phrases - turns-out there's an algorithm with
a similar name, but not related, and an electronics approach (way too
'low' a level for translation to us though).

Tried prefixing with "program" but no such advice to programmers or program[me] designers.

Tried prefixing with "python", but equal lack of joy.

Would OP please quote source?

[snip]
After a few minutes searching I found this:

https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/CodingGuidelines/CglPhp/PhpFileFormatting/PhpSyntaxFormatting.html

"""It is recommended to create conditions so that the shortest block of
code goes first."""

Which is more disparaging: "I couldn't find anyone suggesting this" or
"The only place I could find it was a PHP style guide"?

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/10/2022 13.47, MRAB wrote:

On 2022-10-10 00:40, dn wrote:

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
<python-list@python.org> wrote:

"shortest block first"

Have never heard this advice before. Kind-of rankled with me, as it did
for others.

Enquiring minds want to know... Played Duck, duck, go on this: zero hits
amongst a pile of similar phrases - turns-out there's an algorithm with
a similar name, but not related, and an electronics approach (way too
'low' a level for translation to us though).

Tried prefixing with "program" but no such advice to programmers or
program[me] designers.

Tried prefixing with "python", but equal lack of joy.

Would OP please quote source?

[snip]
After a few minutes searching I found this:

https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/CodingGuidelines/CglPhp/PhpFileFormatting/PhpSyntaxFormatting.html

"""It is recommended to create conditions so that the shortest block of
code goes first."""

Thanks for this!

So, a Domain-Specific Language for a CMS.

If this is only reference, then hardly a tenet of ComSc thinking or programming-languages!


For fun: Typo3 is based on PHP. Advice (apparently) not replicated in
PHP-docs (if, else, etc).
--
Regards,
=dn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[This is an answer for Peter and can easily be skipped by those who know or have no wish to.]

Strictly speaking Peter, the word "pipe" may not mean quite something in
Python but other concepts like chaining may be better.

The original use of the word I am used to was at the UNIX shell level where
an in-core data structure called a pipe was used to connect the output of
one process to the inputr of another, sometimes in long chains like:

cat file1 file2 file3 | grep pattern | ... | lp

Various utilities were thus linked to dynamically create all kinds of solutions. Note the programs ran in parallel and if a program wrote too much into a pipe, it was frozen till the program reading from the pipe caught up
a bit and vice versa. So it often ran a lot faster than earlier programs
that ran sequentially and each one wrote output (unbuffered) into a file and the next program would read from the file. And, of course, there were no
files to clean up and it skipped expensive I/O to and from slow hard disks.

Languages like R had extensions added in various ways within a process that were very different. The parts ran sequentially but instead of writing:

Name1 <- func1(args)
Name2 <- func2(Name1, args)
rm(Name1)
Name3 <- func3(Name2, args)
rm(Name2)
...

You could use an add-on library called dplyr (or others) to do something
like this where to some extent it is syntactic sugar:

Result <- Mydata %>% func1(remaining_args) %>% func2(remaining-args) %>% func3(remaining-args)

A practical example would often be written like this using a dta.frame
called Mydata that has rows and columns:

Mydata <-
Mydata %>%
select(columns-to-keep) %>%
rename(columns-to-change) %>%
filter(conditions-on-which-rows-to-keep) %>%
mutate(newcol=calculation, newcol=calculation, ...) %>%
group_by(column, column, ...) %>%
summarize(...) %>%
arrange(col, desc(col), ...) %>%
ggplot(...) + ...

There are many verbs that take your data one step at a time and keep transforming it. The output of each step becomes the hidden first argument
of the next step. Not the same kind of pipeline. R recently added a native
pipe character so you might use the |> symbol now. It is not quite the same
but often faster.

So finally getting to how Python (and JavaScript and many others) do
something vaguely similar in the sense of chaining.

If you have an object with some method you can call on it (or in some cases
a normal function call) that returns another (or the same) object, then you can write code like:

This.that.other


One obvious example that is trivial is an object that contains another
object which contains yet another object with attributes. Saying a.b.c.attribute is not really a pipeline but simply multiple lines of code collapsed into one fairly logical bundle. Similarly you can do a.method().method().method() where each method is called on whatever object
the preceding method returned which is something "this" in whatever
language.

The pandas module is designed to make such pipelines doable as many methods return the object being worked on.

But consider an example in base Python like a text object that has a
method to format as in :

"My name is {fname}, I'm {age}".format(fname = "John", age = 36)

The result is another string which can then be trimmed or split into parts placed in a list and the list can be asked to do something like throw away
the 4th item or remove duplicates or be sorted and several more steps like
that using a period to apply some functionality to the current state of the current object.

For those who use the python sklearn module, it has a vaguely different idea
of a pipeline as in specifying a set of transformations to be done so the result of each step is passed as the input of the next step. You don't do
the steps yourself, as much as pass a set of functions to an object that
stores them until you ask it to perform an evaluation and then it processed your data using those chained functions which can dynamically change. Lots
of machine learning algorithms use similar ideas such as neural networks
that propagate data/impulses along a chain of filters and so on.

For anyone still reading, the original point must be restated. My point was some people like to program in small byte-size units as if still writing
their first BASIC program. When I use a pythonic idiom (or in R or other languages whatever they consider a good way to use the language) they want
it dumbed down into simple single lines even in code like:

a, b = b, a

They would rather use:

temp = a
a = b
b = temp

You get the idea. So I have had some nice compact code re-arranged to be
much larger and sometimes harder to read and follow. So advice on a goal to make the early blocks of code smaller than later ones may not work when
someone changes your code to their wishes!

End of digression. Again, not all meanings of pipeline are even close to
being the same.


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Peter J. Holzer
Sent: Sunday, October 9, 2022 4:02 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?

On 2022-10-09 15:32:13 -0400, Avi Gross wrote:

and of course no pipelines.

Since you've now used that term repeatedly: What is a pipeline in Python?

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Which is more disparaging: "I couldn't find anyone suggesting this" or

"The only place I could find it was a PHP style guide"?

ChrisA

Chris,

If someone says they heard something from their own personal guru, people
often do not feel threatened or argue. I often am told nutrition or medical
or other advice that I simply ignore especially if it is about exotic herbs
to use or weird ideas like homeopathy or that I should use language X
because it is the only way to a haven or heaven or whatever.

What we had here was someone suggesting their advice was WELL-KNOWN followed
by lots of people sputtering about not having heard of it. I actually think
the advice would be reasonable in many circumstances as long as it did not conflict with dozens of goals I find more compelling but which vary on a
case by case basis such as whether I am prototyping something I will use
once, ...

I have studied PHP but have never felt a need to use it and arguably the
roles it has played are often done commonly by other programs or methods.
Some people might say the same for many languages that are going extinct or that have had to change and adapt to keep being relevant. Had the user
mention this was advice given regarding programs in the original BASIC or in COBOL or PASCAL or lots of other languages I may have once used but rarely
see much point in caring about, it would be no different.

But having ONE source is troublesome. I mean most languages used will
suggest some form of making some kinds of variable names meaningful within various constraints. The constraints may be that the maximum length is
bounded or that it cannot start with a number (or perhaps underscore) or contain some characters. But other advice varies enough that there is no
RIGHT or WRONG across languages. I have seen suggestion to use camelCase or
use periods or underscores between parts of a variable name. I have seen suggestions to use a unique prefix or suffix to mark all your own variables
as a way to minimize the chance of namespace collisions. Some languages
suggest or even enforce that some names be all upper case or have an initial uppercase letter while others should be completely lower case. I mean things like function names versus method names versus class names and so on.

The more global advice is ADVICE that suggests whatever method you choose,
be consistent. If you make class names a certain way, do it as much as
possible for all class names and avoid doing the same thing for non-class names. I think quite a few suggestions fall into the category that they are similar or abstractly enough suggested in many programming languages and by many people. There may be a big enough consensus, perhaps with some
outliers, that it may be accepted as reasonable advice to not be ignored without good reasons.

So in my view, the objection is not about PHP but about uniqueness. If the author of one Python textbook and no others, suggest that your code should declare all imports in alphabetical order then declare all functions in alphabetical order, they can not only safely be ignored, but perhaps not
taken seriously as imports sometimes need to be done carefully if something needs something else and if a language needs functions to be defined before another function body calls them, ...

I was not questioning that someone had heard this advice somewhere and did
not just make it up. Others searching had trouble finding it but that does
not prove anything. Someone finally found one example, which is fine and I suspect there may be other examples found if the search was broader. I
suspect there are plenty of places that advise that you should write such
code so the main things is visible on the current screen and not buried
deeply.

But some people seem to miss a point we have discussed. The odd clauses like ELSE after a loop (and quite a few variants in similar and different cases) often provide guarantees such as making sure a file opened is closed. If you look at a Python protocol such as WITH, then things implementing it arrange
it so under most circumstances other than pulling a power line out of the
wall, the darn file gets closed no matter how you exit the area, and other scenarios try to clean things up even as exceptions are being handled. Sometimes not using these constructs and using something you think is
identical but looks better to you, can result in unanticipated behavior. Putting items in a finally or other such clause can be meaningful and
sometimes makes some things quite explicit and reliable.

Are these things out of the way? Yes, but so what? I see things as a whole
not as just a single screen shot. If a loop has several optional clauses lie
we are discussing and you know they are normally near the end, then look for them where they are.

I know some languages, JavaScript being an example, may have things you
might consider odd such as promoting some things like function definitions found further in your code to near the top so you can use a function that is not defined till later even without something like a forward declaration
used in other languages. A similar feature allows a default to a case-like statement to be placed anywhere but then be effectively moved to the bottom. This means you can make it very visible at or near the top if you want. As I say, languages and idioms vary. What may be easy to make visible in some is hard or not possible to do easily in another. Thus I keep suggesting you consider using things like comments that help spell out the logic up front
and perhaps some that comment on which IF or ELSE the current close bracket
(or change in indentation) is connected to or say up front that hundreds of lines later at the end of this loop, look for several clauses that are part
of the same logic but have to be placed there, and later on comment at that site what these are there for to modify the above loop.

Not perfect but sometimes you work with what you have.

I am now going to stop replying on this topic as I have said way too much
and am not in particular disagreement if we are discussing preferences and ideas. I see TOOLS here, not religion. Use what works or that has to be used for a task but don't take any one thing too seriously.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I won't reply to everything Dave says and especially not the parts I fully agree with.

I think in many situations in life there is no ONE way to do things so most advice is heuristic at best and many exceptions may exist depending on your chosen approach. As such, I do not really think in PYTHON when writing code but an amalgam of many
languages with all kinds of ways of doing things and then zoom in on how to do it in the current language be it Python or R or JavaScript and so on. Yes, I am in some sense focused but also open, just as in Human languages I may mostly be thinking in
English but also sometimes see words and phrases pop into my mind from other languages that mean about the same thing and then filter it out to focus on whichever language I am supposed to be using at the time.

So back to the topic we are wandering in of what kinds of advice might apply in some complex nested IF-THEN-ELSE structures or CASE statements and so on such as comprehensions as to what ways produce better results much of the time and when another
method is better.

Someone suggested a method they use that others wondered about. But they have a point. If you make code with large blocks that do not fit on your screen, and indentation is your guide, you can easily lose sight of things.

But my advice given glibly is also not serious. Sometimes you may think you are being efficient and as DN pointed out, you are not. The compiler or other software may internally rearrange and optimize your code and make your method not necessary or even
prevent the optimization. Your tradeoff may make a program run faster but use more memory or other resources or make it hard for anyone else (or yourself next week) to understand your code or be able to modify it.

So, yes, sometimes it is more natural to write code like if score greater than 90, give an A else if greater than 80 give a B, ... else if less than 65, give an F. Perhaps in Harvard your choice of grades is limited to mostly an A and a few B, no C/D as
anything lower is an F. Some other school may have few A and mainly C. It may be optimal to start with if between 70 and 80, give a C, then deal with lesser cases. Sometimes the data drives what is more common and hence more efficient.

But a big exception is cases where the program blows up if you are not careful. You cannot do certain thinks if a value is empty or NULL or an index above the length of something indexable or trying to write to something read-only and many more.

So much code may look like, in pseudocode:

Case
is.na(var) do this
var > length do that
value[var] of type integer do whatever
...

It may take several steps to make sure your data won't cause an exception if queried without checking if the query makes sense. Only once that is away, might you be able to try for the most common cases for valid data first.

Again, as DN points out, in Python some may use exceptions that would jump in for the hopefully rare cases the above type of code tries to protect against. That can be a good approach if these cases are rare and identifiable as unique exceptions so your
code focuses on optimizing the good cases you normally expect and shows them up-front with exception-handling code dangling beneath.

I suspect some of us prefer some methods over others but can also be ambidextrous as needed. Older languages rapidly killed any program that tried to divide by zero so every single division needed to be protected if a zero might be involved. Mind you,
newer languages can face serious bugs with things not easily trapped as value like Inf or NaN or missing values of various kinds can propagate and ruin lots of data. What is the mean of a group of numbers that includes an infinite one? What about some
form of NA? Languages like R offer lots of idioms such as having many functions add a codicil like na.rm=TRUE that strips them before they infect your data, but that is not always appropriate.

I do not see most programming as a one-size-fits-all approach. Most advice is best ignored. Anyone who suggests that all functions be say no more than 5 lines and that you should waste lots of time and energy making ever more small functions to decompose
any larger one till it is under 5 lines but now calls lots of meaningless short functions sometimes 10 levels deep, is not helping you. Goals are fine when they make sense but often the opposite is true.

Consider some kind of case statement that has dozens of cases like asking what to do when one of many keys is pressed on a keyboard. The function can be dozens or hundreds of lines long. I could create a function that tests for 'A' and non-A and in the
latter case calls a second function that tests for B and non-B and so on. If the user types Z, it is handled in the 26th function! But worse, you may need to pass all kinds of other variables down this chain so whatever key is pressed can do things with
local variables. This does not sound like an improvement over one longer function.

But yet, sometimes not. You might decide a good way to handle this is to use a dictionary containing all possible keys as keys and varying small functions as arguments. This could make your main function fairly small, once the dictionary had been created
using many long lines.

So you might say that when evaluating multiple possible solutions, one of several guiding mechanisms is to use fairly short functions. But adding may guiding principles opens up the door for many conflicts so add one saying that if your manager or
reviewers insist you do it a specific way, forget the rest unless you do not value your job!

Anyone who has read this far, you have my sympathies. LOL! Like me, I suggest you (and I) get a life! In life, there often are no unique right answers albeit an infinite number of wrong answers.




-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of dn
Sent: Sunday, October 9, 2022 7:41 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list <python-list@python.org> wrote:

"shortest block first"

Have never heard this advice before. Kind-of rankled with me, as it did for others.

Enquiring minds want to know... Played Duck, duck, go on this: zero hits amongst a pile of similar phrases - turns-out there's an algorithm with a similar name, but not related, and an electronics approach (way too 'low' a level for translation to us
though).

Tried prefixing with "program" but no such advice to programmers or program[me] designers.

Tried prefixing with "python", but equal lack of joy.

Would OP please quote source?


On 10/10/2022 05.56, Peter J. Holzer wrote:

On 2022-10-09 12:18:09 -0400, Avi Gross wrote:

Smallest code blocks first may be a more modern invention.

None of the recent-grads or new-hires I've asked this morning (it's already Monday over-here!) have used or heard the term.

Some would argue for a rule related to efficiency of execution. When you
have multiple blocks as in an if-else or case statement with multiple
choices, that you order the most common cases first. Those shorten
execution more often than the rarer cases especially the ones that should
never happen.

Those of us who started programming on 8 bit homecomputers of course
have efficiency always at the back of their heads, but I find this

... for mainframes just as much as micro-computers!

Regarding execution-efficiencies, I'm sure @Avi knows better than I: It
seems likely that Python, as an interpreted language, will create
'blocks' of its virtual-machine code in the same order as they appear in
the Python-source. However, aren't there optimising compilers which do something intelligent with the equivalent clauses/suites in other languages?

Regardless, is a Jump-instruction which transfers else-control to a
block five machine-instructions 'down', any less efficient than a jump
which spans 50-instructions?

So not a rule but realistically not always a bad idea to write code in a
way that draws the attention of readers along the main path of execution
and perhaps not showing all the checking for odd cases first.

much more important. Putting the main path first makes it easier to understand what the code is supposed to do normally. All those pesky exceptions are in the "small print" below.

Absolutely! Has the term "readability" been used 'here'?

Human nature (or is it that of computer programmers in-particular) is to
be optimistic: it will work [this time*]. Accordingly, a colleague talks
of always coding 'the happy line' first (meaning line of logic, cf source-code).

Contrarily, for while-True (infinite) loops, and particularly recursive algorithms, the [wise] counsel is to code the end-condition first.
(always know your closest exit! "The nearest exit may be behind you"...)


Indeed, dare I say, this optimistic-approach is pythonic. Taking an over-simple, two-value division example, the approach is:

try:
a = b / c
except ZeroDivisionError:
... clean-up the mess ...

which contrasts the EAFP philosophy of Python versus the LBYL
expectation of (many) other languages:

assert c != 0
a = b / c

That said, as "Data Science" use of Python expands, it is bringing more
and more needs for an LBYL attitude, eg "data cleaning".

(EAFP, LBYL? https://docs.python.org/3.9/glossary.html)

There is of course the opposite view that you should just get all of the confounding factors out of the way first, so that the default is also
the common case. I also do that sometimes, but then I don't hide this in
in an else: clause but do something like this:

for item in whatever:
if not_this_one(item):
continue
if neither_this_one(item):
continue
if cant_continue(item):
break
if oopsie():
raise SomeError()

do_something_with(item)
and_some_more(item)
we_are_done(item)

which shows visually what the main purpose of the loop (or function or
other block) is.

Nicely stated!

NB I've seen sufficient of @Peter's posts to know that this was never
(even implied to be) intended as a snippet for all occasions!


It also illustrates why such is less readable: because we have to scan
four if-statements before we can 'see' the purpose of the loop. My
'itch' would be to extract this code 'out' to a function - that way the
name will convey the somewhat-obscured purpose of the loop.


Alternately, reduce the 'distractions':-

try:
for item in whatever:
inspect_the_data( item )
do_something_with(item)
and_some_more(item)
we_are_done(item)
except SomeError:
...
except CustomBreakException:
... ?pass? # same effect as break

by 'hiding' in:

def inspect_the_data( item ):
if not_this_one(item):
continue
if neither_this_one(item):
continue
if cant_continue(item):
raise CustomBreakException # was break
if oopsie():
raise SomeError()


It is now easier to understand 'the happy line', ie the thinking of the original-coder, and the 'small print' has been relegated to such and can
be cheerfully disregarded.

Whereas, if 'exceptional circumstances' is the reason one is inspecting
the code in the first-place, then it also helps to have separated-out
the ifs-buts-and-maybes, and into a structure which can be as closely
(and exhaustively) tested, as may be required.


In some ways, (IMHO) there are reasons to feel disquiet over this style
of coding. Learning "Modular Programming", and slightly-later
"Structured Programming", when they were still new (?fresh, ?exciting),
we were inculcated with the 'one way in, one way out' philosophy-of-correctness. This applied to "blocks" of code (per
"module"), as well as formal units, eg functions.

Accordingly, am slightly unnerved by seeing Exceptions being used to
'jump out' of interior/nested blocks, rather than using the
return-mechanism (taking their turn like all the good little boys and
girls). That said, it makes for tidier code - so I'll stop muttering
into my (grey) beard ...


The alternative, assuming the 'errors and omissions' function is a
possible tactic(!), would be to return a boolean, eg

def is_clean_data( item )->bool:
is_verified = False
if ...
...
return is_verified

- thus the do-stuff calls will become a 'successful' if-then 'suite'.


There is more code to write/read - and the toy-example lends itself to
such a tactic. In other situations, perhaps some refactoring or pre-processing, even a decorator, might remove (or reduce) the need for
so much checking within the loop/block.


When to use one or the other approach?

We could hide behind some 'mystery', and say "I just know from
experience", but that smacks of a secret coin-toss (human 'gut feelings'
not being particularly indicative of success). So, here's a stab at it
which harks back to the learn/use 'COBOL or FORTRAN' [argument] days:

If the purpose/considerations of the for-loop (block), are:-
- data-related: check-first
(and thus consider extract and/or invert to promote readability)
- logic/algorithmic implementation, take 'the happy line' first
(and deal with the exceptions ("small print") later)


Worthy of consideration, is that Python is (still) fast-developing. The switch-case construct of v3.10, and protocols and beefed-up descriptors (?interfaces?) could have quite an impact on such thinking, and in the relatively near-future...


* back in the ?bad old days when testing was something that was (only)
done AFTER coding was complete, ie ego-driven development. The
traditional response to the question: "are you coming to lunch/dinner/supper/break/the party/bed/...?" was "in a moment -
[surely?] there's only one more bug"!


I've been 'dipping into' Martin Fowler's "Refactoring", 2e, Pearson,
2019; but don't have it with me to point to useful references. What I do
have to-hand, because it has just arrived, is Mariano Anaya's "Clean
Code in Python", (also 2e), Packt, 2020* - although I didn't see its
previous edition, and have read nothing beyond the Contents(!) to-date;
it talks of "Design by Contract", "Defensive Programming", "Separation
of Concerns" indicating it may have thinking to offer.

* the reviewer was Tarek Ziadé, author of "Expert Python", which is
worth reading - as are his other works (in English and in French)
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Oct 2022 at 14:59, <avi.e.gross@gmail.com> wrote:

Which is more disparaging: "I couldn't find anyone suggesting this" or "The only place I could find it was a PHP style guide"?
ChrisA

Chris,

If someone says they heard something from their own personal guru, people often do not feel threatened or argue. I often am told nutrition or medical or other advice that I simply ignore especially if it is about exotic herbs to use or weird ideas like homeopathy or that I should use language X
because it is the only way to a haven or heaven or whatever.

What we had here was someone suggesting their advice was WELL-KNOWN followed by lots of people sputtering about not having heard of it. I actually think the advice would be reasonable in many circumstances as long as it did not conflict with dozens of goals I find more compelling but which vary on a
case by case basis such as whether I am prototyping something I will use once, ...

It's clearly not all that well known (none of us have heard of it, and
it's not exactly prominent on the internet), and it seems that most of
us disagree that it's even good advice. So, it's not really a good
argument against for-else.

I have studied PHP but have never felt a need to use it and arguably the roles it has played are often done commonly by other programs or methods.

That's because PHP is terrible.

So in my view, the objection is not about PHP but about uniqueness. If the author of one Python textbook and no others, suggest that your code should declare all imports in alphabetical order then declare all functions in alphabetical order, they can not only safely be ignored, but perhaps not taken seriously as imports sometimes need to be done carefully if something needs something else and if a language needs functions to be defined before another function body calls them, ...

It's not JUST about uniqueness. It's also that nobody but PHP
programmers seem to care about it. That's on par with going to an art
supplies forum and trying to argue that you should lay out your paints
in a specific order, because some kindergarten teacher always does it
that way for the kids' fingerpainting sessions.

No, actually, that's unfair to fingerpainting kindergarteners.

But some people seem to miss a point we have discussed. The odd clauses like ELSE after a loop (and quite a few variants in similar and different cases) often provide guarantees such as making sure a file opened is closed.

Citation needed.

Are these things out of the way? Yes, but so what? I see things as a whole not as just a single screen shot. If a loop has several optional clauses lie we are discussing and you know they are normally near the end, then look for them where they are.

So what's your point?

I know some languages, JavaScript being an example, may have things you
might consider odd such as promoting some things like function definitions found further in your code to near the top so you can use a function that is not defined till later even without something like a forward declaration
used in other languages.

I've hardly ever seen good code that actually uses that. And when it
did, it usually wasn't deliberate. Most well-written JS code will do
the same thing that Python code does, calling things that have already
been defined (if not lexically then temporally). No hoisting needed.

I am now going to stop replying on this topic as I have said way too much
and am not in particular disagreement if we are discussing preferences and ideas. I see TOOLS here, not religion. Use what works or that has to be used for a task but don't take any one thing too seriously.

Yes, I see tools too. And this thread started out with a discussion of
the for-else construct, which was disparaged because it violated a
rule that nobody here has heard of, few agree with, and has exceptions
already.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris, a short(er) answer to your addition below.

I did not at first share your perception but maybe do now. If the argument
was that ELSE and other constructs like FINALLY or CATCH are horrible
because they follow other code and important things should be first, that is
a silly argument. Many are at the end precisely because they are not the
main code but have a role to play in making sure various conditions are
dealt with. What some of us ended up discussing was whether the advice made much sense in a broader context and were reasonable to strive for. Many of
us say not as important as many other things, or not important at all.

I note some people looked at the way C had a FOR loop with three parts
between semicolons up front as syntactic sugar. No doubt clauses like ELSE could in some way be moved around but the result may well violate other sensibilities as that did because it is a rather nonstandard syntax.

I have seen languages with CASE or SWITCH statements that fall through and allow some code to be written once and executed for several scenarios.
Others loathe the idea and want each case self-contained. There is no one answer everyone likes. Languages are huge experiments for differing ideas.

But it is largely IRRELEVANT in that Python already made the decision and
for now it is what it is. We had a different argument a while back as to how the word ELSE captured what is happening linguistically and for many here
IT DOES NOT. But once you KNOW what it does, and you choose to use it, then
it works just as well as any other words because it is what it is. If having
an ELSE late disqualifies Python for this person, use another language! Of course, PHP may not be ideal for so many other reasons!




-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Chris Angelico
Sent: Monday, October 10, 2022 12:21 AM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?

On Mon, 10 Oct 2022 at 14:59, <avi.e.gross@gmail.com> wrote:

Which is more disparaging: "I couldn't find anyone suggesting this"
or

"The only place I could find it was a PHP style guide"?

ChrisA

Chris,

If someone says they heard something from their own personal guru,
people often do not feel threatened or argue. I often am told
nutrition or medical or other advice that I simply ignore especially
if it is about exotic herbs to use or weird ideas like homeopathy or
that I should use language X because it is the only way to a haven or

heaven or whatever.

What we had here was someone suggesting their advice was WELL-KNOWN
followed by lots of people sputtering about not having heard of it. I actually think the advice would be reasonable in many circumstances as
long as it did not conflict with dozens of goals I find more
compelling but which vary on a case by case basis such as whether I am prototyping something I will use once, ...

It's clearly not all that well known (none of us have heard of it, and it's
not exactly prominent on the internet), and it seems that most of us
disagree that it's even good advice. So, it's not really a good argument against for-else.

I have studied PHP but have never felt a need to use it and arguably
the roles it has played are often done commonly by other programs or

methods.

That's because PHP is terrible.

So in my view, the objection is not about PHP but about uniqueness. If
the author of one Python textbook and no others, suggest that your
code should declare all imports in alphabetical order then declare all functions in alphabetical order, they can not only safely be ignored,
but perhaps not taken seriously as imports sometimes need to be done carefully if something needs something else and if a language needs
functions to be defined before another function body calls them, ...

It's not JUST about uniqueness. It's also that nobody but PHP programmers
seem to care about it. That's on par with going to an art supplies forum and trying to argue that you should lay out your paints in a specific order, because some kindergarten teacher always does it that way for the kids' fingerpainting sessions.

No, actually, that's unfair to fingerpainting kindergarteners.

But some people seem to miss a point we have discussed. The odd
clauses like ELSE after a loop (and quite a few variants in similar
and different cases) often provide guarantees such as making sure a file

opened is closed.

Citation needed.

Are these things out of the way? Yes, but so what? I see things as a
whole not as just a single screen shot. If a loop has several optional clauses lie we are discussing and you know they are normally near the
end, then look for them where they are.

So what's your point?

I know some languages, JavaScript being an example, may have things
you might consider odd such as promoting some things like function definitions found further in your code to near the top so you can use
a function that is not defined till later even without something like
a forward declaration used in other languages.

I've hardly ever seen good code that actually uses that. And when it did, it usually wasn't deliberate. Most well-written JS code will do the same thing that Python code does, calling things that have already been defined (if not lexically then temporally). No hoisting needed.

I am now going to stop replying on this topic as I have said way too
much and am not in particular disagreement if we are discussing
preferences and ideas. I see TOOLS here, not religion. Use what works
or that has to be used for a task but don't take any one thing too

seriously.

Yes, I see tools too. And this thread started out with a discussion of the for-else construct, which was disparaged because it violated a rule that
nobody here has heard of, few agree with, and has exceptions already.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:

Am Sun, Oct 09, 2022 at 09:58:14AM +0000 schrieb Stefan Ram:

I often follow this rule. For me, it's about readability. Compare:
if not open( disk ):
error( "Can't open disk" )
else:
printf( "now imagine there's some larger block here" )

... ad infinitum ....

Should this not be
if not open( disk ):
error( "Can't open disk" )
else:
do_lots_of_things_with(disk)
as for readability ?

I would not use tabs in source code as they are not
displayed in the same way everywhere. What I see here is:

Should this not be
if not open( disk ):
error( "Can't open disk" )
else:
do_lots_of_things_with(disk)
as for readability ?

. The "d" of "do" is not below the first "e" of "error"!

"If" branch blocks with more than 30 lines can be found in
many Python source files. (I just chose one from the standard
lib at random to see this.)

Functions also come at a cost. From the Web:

|We find that in older studies (pre-2000) short functions
|correlate with higher defect density.
|
|There seem to be no post-2000 studies exclusively
|focusing on function length, but through original research
|we find that modern code bases exhibit similar behavior.
|
From the Web.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, Oct 09, 2022 at 09:58:14AM +0000 schrieb Stefan Ram:

I often follow this rule. For me, it's about readability. Compare:

if not open( disk ):
error( "Can't open disk" )
else:
printf( "now imagine there's some larger block here" )

... ad infinitum ....

Should this not be

if not open( disk ):
error( "Can't open disk" )
else:
do_lots_of_things_with(disk)

as for readability ?

Or even

if not open( disk ):
error( "Can't open disk" )
return what_needs_to_be_returned

do_lots_of_things_with(disk)

The latter version may need some code reorganization, though.

Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/10/2022 03:33, Jach Feng wrote:

Axy 在 2022年10月8日 星期�

�上�11:39:44 [UTC+8] 的信中寫道：

Hi there,

this is rather a philosophical question, but I assume I miss something.
I don't remember I ever used else clause for years I was with python and
my expectation was it executed only if the the main body was never run.
Ha-ha! I was caught by this mental trap.

So, seriously, why they needed else if the following pieces produce same
result? Does anyone know or remember their motivation?

Just curious.

Axy.

print('--- with else')


for i in [1,2,3]:
print(i)
else:
print(4)

for i in []:
print(i)
else:
print(5)

print('--- without else')

for i in [1,2,3]:
print(i)
print(4)

for i in []:
print(i)
print(5)

The else is always coming with the break, not the for.

However, the compiler does not complain.

There are [for ...], [for...break...], and[for...break...else],

That's implied and contradicts Zen of Python, I think. If "else" came
with "break" there had to be a strong indication of that, namely
indentation, as it takes place for all other statements with their
clauses. However, there's no such an explicit connection between "break"
and "else". That's the point.

Well, sorry for this addition to the discussion which went weird way. I
should had to be cautious mentioning particular coding style, that's a
totally different subject, actually. Let's close it at last.

but the [for...else] is insane.

Not in Python.

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Not sure what you mean, but a for-else without a break is quite
useless. What exactly ARE you arguing here?

The else is associated with the break to the exact extent that one is essential to the other's value.

I'm not arguing. That was just for the record, how things are done in
Python. Basically, I simply asked a question and got a definite answer
and clear understanding shortly, in a few replies. All the rest of this
thread looks irrelevant to me, it's about coding style and probably
should be continued under a different title, but I'm not interested to participate in it.

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Axy 在 2022年10月10日 星期一下午5:55:29 [UTC+8] 的信中寫道：

On 09/10/2022 03:33, Jach Feng wrote:

The else is always coming with the break, not the for.

However, the compiler does not complain.

Sure, the compiler will not complain even in a IOCCC contest:-)

but the [for...else] is insane.

Not in Python.

The confusion is always in human mind.

---Jach

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Oct 2022 at 20:56, Axy via Python-list
<python-list@python.org> wrote:

The else is always coming with the break, not the for.

However, the compiler does not complain.

There are [for ...], [for...break...], and[for...break...else],

That's implied and contradicts Zen of Python, I think. If "else" came
with "break" there had to be a strong indication of that, namely
indentation, as it takes place for all other statements with their
clauses. However, there's no such an explicit connection between "break"
and "else". That's the point.

Well, sorry for this addition to the discussion which went weird way. I should had to be cautious mentioning particular coding style, that's a totally different subject, actually. Let's close it at last.

but the [for...else] is insane.

Not in Python.

Not sure what you mean, but a for-else without a break is quite
useless. What exactly ARE you arguing here?

The else is associated with the break to the exact extent that one is
essential to the other's value.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Oct 2022 at 20:46, Karsten Hilbert <Karsten.Hilbert@gmx.net> wrote:

Am Sun, Oct 09, 2022 at 09:58:14AM +0000 schrieb Stefan Ram:

I often follow this rule. For me, it's about readability. Compare:

if not open( disk ):
error( "Can't open disk" )
else:
printf( "now imagine there's some larger block here" )

... ad infinitum ....

Should this not be

if not open( disk ):
error( "Can't open disk" )
else:
do_lots_of_things_with(disk)

as for readability ?

Or even

if not open( disk ):
error( "Can't open disk" )
return what_needs_to_be_returned

do_lots_of_things_with(disk)

The latter version may need some code reorganization, though.

I definitely prefer the fail-and-bail version (mainly because, as the
number of possible failure modes increases, the code complexity
increases linearly, whereas with if/else style it will increase
quadratically - you have to edit the entire block, and indent it, for
each one). But contrasting the original two? A complete wash. There's
no readability difference between them.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/10/2022 12:24, Chris Angelico wrote:

On Mon, 10 Oct 2022 at 21:57, Axy via Python-list
<python-list@python.org> wrote:

Not sure what you mean, but a for-else without a break is quite
useless. What exactly ARE you arguing here?

The else is associated with the break to the exact extent that one is
essential to the other's value.

I'm not arguing. That was just for the record, how things are done in
Python. Basically, I simply asked a question and got a definite answer
and clear understanding shortly, in a few replies. All the rest of this
thread looks irrelevant to me, it's about coding style and probably
should be continued under a different title, but I'm not interested to
participate in it.

Here's where the "rest of this thread" started:

Actually the reason I never used "else" was the violation of the rule of
beauty "shortest block first".

You disparaged a feature on the basis of a style rule that few of us
had heard of or agree with.

Oh, I'm really sorry. My apologies.

We all agree that coding style is
important; none of us would see block length as a reason to avoid
using an else clause on a for loop.

As I understand from the above there must be a committee that delegates
a speaker? Where to read rules? How to participate? There's something
beyond this list I'm not aware of yet?

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Oct 2022 at 21:57, Axy via Python-list
<python-list@python.org> wrote:

Not sure what you mean, but a for-else without a break is quite
useless. What exactly ARE you arguing here?

The else is associated with the break to the exact extent that one is essential to the other's value.

I'm not arguing. That was just for the record, how things are done in
Python. Basically, I simply asked a question and got a definite answer
and clear understanding shortly, in a few replies. All the rest of this thread looks irrelevant to me, it's about coding style and probably
should be continued under a different title, but I'm not interested to participate in it.

Here's where the "rest of this thread" started:

Actually the reason I never used "else" was the violation of the rule of beauty "shortest block first".

You disparaged a feature on the basis of a style rule that few of us
had heard of or agree with. We all agree that coding style is
important; none of us would see block length as a reason to avoid
using an else clause on a for loop.

Your subsequent posts have left me confused as to what you're trying to convey.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 10 Oct 2022 at 22:37, Axy via Python-list
<python-list@python.org> wrote:

On 10/10/2022 12:24, Chris Angelico wrote:

On Mon, 10 Oct 2022 at 21:57, Axy via Python-list
<python-list@python.org> wrote:

Not sure what you mean, but a for-else without a break is quite
useless. What exactly ARE you arguing here?

The else is associated with the break to the exact extent that one is
essential to the other's value.

I'm not arguing. That was just for the record, how things are done in
Python. Basically, I simply asked a question and got a definite answer
and clear understanding shortly, in a few replies. All the rest of this
thread looks irrelevant to me, it's about coding style and probably
should be continued under a different title, but I'm not interested to
participate in it.

Here's where the "rest of this thread" started:

Actually the reason I never used "else" was the violation of the rule of >> beauty "shortest block first".

You disparaged a feature on the basis of a style rule that few of us
had heard of or agree with.

Oh, I'm really sorry. My apologies.

We all agree that coding style is
important; none of us would see block length as a reason to avoid
using an else clause on a for loop.

As I understand from the above there must be a committee that delegates
a speaker? Where to read rules? How to participate? There's something
beyond this list I'm not aware of yet?

We in this thread. Look at the past replies.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-10, Chris Angelico <rosuav@gmail.com> wrote:

On Mon, 10 Oct 2022 at 11:52, MRAB <python@mrabarnett.plus.com> wrote:

On 2022-10-10 00:40, dn wrote:

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
<python-list@python.org> wrote:

"shortest block first"

Have never heard this advice before. Kind-of rankled with me, as it did
for others.

I've followed that advice for several decades. I find it much easier
to read code that's organized that way -- particularly when the
difference in block sizes is large (e.g. the first block is one line,
and the second is a a hundred).

--
Grant

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Core developer Raymond Hettinger explains the history starting at 15:40 https://www.youtube.com/watch?v=OSGv2VnC0go

(which I found on stackoverflow https://stackoverflow.com/questions/9979970/why-does-python-use-else-after-for-and-while-loops )

TL:DR
The �else� is a historical artificial from the way developers thought during the transition from unstructured (i.e. �GOTO�) programming to structured programming. Since we all do structured now, it seems odd.


From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Calvin Spealman <cspealma@redhat.com>
Date: Monday, October 10, 2022 at 10:38 AM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

On Sat, Oct 8, 2022 at 5:35 PM rbowman <bowman@montana.com> wrote:

On 10/7/22 21:32, Axy wrote:

So, seriously, why they needed else if the following pieces produce same result? Does anyone know or remember their motivation?

In real scenarios there would be more logic in the for block that would
meet a condition and break out of the loop. If the condition is never
met, the else block runs. To steal from w3schools:

fruits = ["apple", "peach", "cherry"]
for x in fruits:
print(x)
if x == "banana":
break
else:
print("Yes we got no bananas")

I wonder if for/else could have been less confusing if it was referred to
as for-break-else and if the else clause was only valid syntax if the for
loop actually contained a break statement in the first place.

--

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.spealman@redhat.com M: +1.336.210.5107
[image: https://urldefense.com/v3/__https://red.ht/sig__;!!Cn_UX_p3!lSA-VzlSq_UQvMUO2npcFCxacA2jOlt2ZD6LCiwdfMGpYexlKgYpIgDCxlHPs473PNyH7cww2ufihhXbt2Z5$<https://urldefense.com/v3/__https:/red.ht/sig__;!!Cn_UX_p3!lSA-VzlSq_
UQvMUO2npcFCxacA2jOlt2ZD6LCiwdfMGpYexlKgYpIgDCxlHPs473PNyH7cww2ufihhXbt2Z5$> ] <https://urldefense.com/v3/__https://red.ht/sig__;!!Cn_UX_p3!lSA-VzlSq_UQvMUO2npcFCxacA2jOlt2ZD6LCiwdfMGpYexlKgYpIgDCxlHPs473PNyH7cww2ufihhXbt2Z5$ >
TRIED. TESTED. TRUSTED. <https://urldefense.com/v3/__https://redhat.com/trusted__;!!Cn_UX_p3!lSA-VzlSq_UQvMUO2npcFCxacA2jOlt2ZD6LCiwdfMGpYexlKgYpIgDCxlHPs473PNyH7cww2ufihjGGi9WT$ >
-- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!lSA-VzlSq_UQvMUO2npcFCxacA2jOlt2ZD6LCiwdfMGpYexlKgYpIgDCxlHPs473PNyH7cww2ufihnTgBbx-$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-
list__;!!Cn_UX_p3!lSA-VzlSq_UQvMUO2npcFCxacA2jOlt2ZD6LCiwdfMGpYexlKgYpIgDCxlHPs473PNyH7cww2ufihnTgBbx-$>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Weatherby,Gerard" <gweatherby@uchc.edu> writes:

try:
open(disk)
except:
error(“Can’t open disk”)
lots of things

Those quotation marks will not work in Python.

When "error" is a function that returns, "lots of things"
will be executed even in case of a missing disk according
to your code.

"Except:" would catch anything, even errors one should not
usually catch.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

try:
open(disk)
except:
error(�Can�t open disk�)
lots of things

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Karsten Hilbert <Karsten.Hilbert@gmx.net>
Date: Monday, October 10, 2022 at 5:46 AM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

Am Sun, Oct 09, 2022 at 09:58:14AM +0000 schrieb Stefan Ram:

I often follow this rule. For me, it's about readability. Compare:

if not open( disk ):
error( "Can't open disk" )
else:
printf( "now imagine there's some larger block here" )

... ad infinitum ....

Should this not be

if not open( disk ):
error( "Can't open disk" )
else:
do_lots_of_things_with(disk)

as for readability ?

Or even

if not open( disk ):
error( "Can't open disk" )
return what_needs_to_be_returned

do_lots_of_things_with(disk)

The latter version may need some code reorganization, though.

Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
-- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!nWwvwKC2eetL3YQnTS4jDih5YRZ_ziu4gPuU73R7LDX8-Kq0bXR-h4E_0kJopk-ud2oeAq6NwvykTB40o82ris6pM1aC$<https://urldefense.com/v3/__https:/mail.python.org/mailman/
listinfo/python-list__;!!Cn_UX_p3!nWwvwKC2eetL3YQnTS4jDih5YRZ_ziu4gPuU73R7LDX8-Kq0bXR-h4E_0kJopk-ud2oeAq6NwvykTB40o82ris6pM1aC$>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Oct 8, 2022 at 5:35 PM rbowman <bowman@montana.com> wrote:

On 10/7/22 21:32, Axy wrote:

So, seriously, why they needed else if the following pieces produce same result? Does anyone know or remember their motivation?

In real scenarios there would be more logic in the for block that would
meet a condition and break out of the loop. If the condition is never
met, the else block runs. To steal from w3schools:

fruits = ["apple", "peach", "cherry"]
for x in fruits:
print(x)
if x == "banana":
break
else:
print("Yes we got no bananas")

I wonder if for/else could have been less confusing if it was referred to
as for-break-else and if the else clause was only valid syntax if the for
loop actually contained a break statement in the first place.

--

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.spealman@redhat.com M: +1.336.210.5107
[image: https://red.ht/sig] <https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-10, Calvin Spealman <cspealma@redhat.com> wrote:

On Sat, Oct 8, 2022 at 5:35 PM rbowman <bowman@montana.com> wrote:

On 10/7/22 21:32, Axy wrote:

So, seriously, why they needed else if the following pieces produce same >> > result? Does anyone know or remember their motivation?

In real scenarios there would be more logic in the for block that would
meet a condition and break out of the loop. If the condition is never
met, the else block runs. To steal from w3schools:


fruits = ["apple", "peach", "cherry"]
for x in fruits:
print(x)
if x == "banana":
break
else:
print("Yes we got no bananas")

I wonder if for/else could have been less confusing if it was referred to
as for-break-else and if the else clause was only valid syntax if the for loop actually contained a break statement in the first place.

Watch out, I suggested that here some years ago and it was derided
as being an "arrogant and foolish" idea.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/10/2022 15:52, Weatherby,Gerard wrote:

Core developer Raymond Hettinger explains the history starting at 15:40 https://www.youtube.com/watch?v=OSGv2VnC0go

(which I found on stackoverflow https://stackoverflow.com/questions/9979970/why-does-python-use-else-after-for-and-while-loops )

TL:DR
The “else” is a historical artificial from the way developers thought during the transition from unstructured (i.e. “GOTO”) programming to structured programming. Since we all do structured now, it seems odd.

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Calvin Spealman <cspealma@redhat.com>
Date: Monday, October 10, 2022 at 10:38 AM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

On Sat, Oct 8, 2022 at 5:35 PM rbowman <bowman@montana.com> wrote:

On 10/7/22 21:32, Axy wrote:

So, seriously, why they needed else if the following pieces produce same >>> result? Does anyone know or remember their motivation?

In real scenarios there would be more logic in the for block that would
meet a condition and break out of the loop. If the condition is never
met, the else block runs. To steal from w3schools:


fruits = ["apple", "peach", "cherry"]
for x in fruits:
print(x)
if x == "banana":
break
else:
print("Yes we got no bananas")

I wonder if for/else could have been less confusing if it was referred to
as for-break-else and if the else clause was only valid syntax if the for loop actually contained a break statement in the first place.

Sounds reasonable. It would be something alike UnboundLocalError when a
local variable referenced before assignment. If they won't remove "else" completely in far future, that checking really worths implementing now.

Excellent stackoverflow link, thanks!

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris Angelico wrote:

Yes, I'm aware that code readability becomes irrelevant for
short-duration projects. Beside the point. I'm wondering how important
it really is to have the shortest block first.

I usually put the most expected / frequent / not negated block first if the whole if/else statement is not "too long". Sometimes whatever you want to do becomes pointless if a certain conditions is not met, in which case I do an early break or return and have no else block at all.

Given that for-else is an excellent, if rarely-used, construct

I knew it existed but coming from C I never thought to exploit it. I know I wrote loops like this:

found = None
while not found:
found = search(something)
if found:
break
if not found:
complain()

Need to look into using "else" in these cases.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Grant Edwards wrote:

I've followed that advice for several decades. I find it much easier
to read code that's organized that way -- particularly when the
difference in block sizes is large (e.g. the first block is one line,
and the second is a a hundred).

If any conditionally executed blocks is a hundred lines, I believe your code needs refactoring. I know mine does. Either the long block should go into an extra function, or you do a "fail and bail" (just learned that phrase).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Axy wrote:

Also not really a justification for "shortest block first". Wanting
some elaboration on that. What's the value in it?

Well, the value is productivity. No need to save puzzles "what this
hanging else belongs to?"

If you find yourself asking that question, the if-block is probably too long to begin with.

Code small things first and return early, same
as taking a test: do easy and quick things first and boring and
difficult ones later.

Yes, but in that case you have a very long indented "else" block, and at the point where the unindent happens you are scratching your head again like before. Better to immediately return or break and not to use any "else" block at all.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/10/2022 15:52, Weatherby,Gerard wrote:

I wonder if for/else could have been less confusing if it was
referred to
as for-break-else and if the else clause was only valid syntax if the
for
loop actually contained a break statement in the first place.

Sounds reasonable. It would be something alike UnboundLocalError when
a local variable referenced before assignment. If they won't remove
"else" completely in far future, that checking really worths
implementing now.

Actually, I think a warning would be sufficient, as in the following
quick prototype. If someone can implement this quickly in CPython, that
would be great (last time I hacked it, it was 2.4)

Axy.

import ast

tree = ast.parse('''
# sample code
a = 0
for i in 'asd':
    a += i
    while x:
        pass
    else:
        print('wow')
    break
    print(i)
else:
    print(0)
''', mode='exec')

def check_ast(node):
    if isinstance(node, (ast.For, ast.AsyncFor, ast.While)):
        if node.orelse and have_no_break(node.body):
            print(f'Warning: the loop at line {node.lineno} has no "break" statement,'
                  f' "else" clause at line {node.orelse[0].lineno}
won\'t run')
    else:
        for child in ast.iter_child_nodes(node):
            check_ast(child)

def have_no_break(loop_body):
    for node in loop_body:
        if isinstance(node, (ast.For, ast.AsyncFor, ast.While)):
            # nested loop
            check_ast(node)
        elif isinstance(node, ast.Break):
            return False
        elif isinstance(node, list):
            for child in ast.iter_child_nodes(node):
                if have_no_break(child) == False:
                    return False
    return True


for node in tree.body:
    check_ast(node)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-10 12:40:44 +1300, dn wrote:

On 10/10/2022 05.56, Peter J. Holzer wrote:

On 2022-10-09 12:18:09 -0400, Avi Gross wrote:

Some would argue for a rule related to efficiency of execution. When you have multiple blocks as in an if-else or case statement with multiple choices, that you order the most common cases first. Those shorten execution more often than the rarer cases especially the ones that should never happen.

Those of us who started programming on 8 bit homecomputers of course
have efficiency always at the back of their heads, but I find this

... for mainframes just as much as micro-computers!

I knew this would be coming :-).

Regarding execution-efficiencies, I'm sure @Avi knows better than I: It
seems likely that Python, as an interpreted language, will create 'blocks'
of its virtual-machine code in the same order as they appear in the Python-source. However, aren't there optimising compilers which do something intelligent with the equivalent clauses/suites in other languages?

They can certainly move the code around. So something like

if a:
long block a
elif b:
long block b
else:
long block c

could be compiled into (pseudo-python):

if a:
goto label_a
elif b:
goto label_b
long block c
goto end
label_a:
long block a
goto end
label_b:
long block b
end:
pass

If they can prove that it makes no difference they can also change the
order of checking conditions:

def f(a: int) -> str:
if a < 0:
return "negative"
elif a > 100:
return "big"
else:
return "meh"

could be compiled into the equivalent of:

def f(a: int) -> str:
if a > 100:
return "big"
elif a < 0:
return "negative"
else:
return "meh"

since an int cannot be simultaneously less then 0 and larger than 100.

But if the order does matter, as in

def f(a: bool, b: bool) -> int:
if a:
return 1
elif b:
return 2
else:
return 3

it can't do any transformations which would change the result.

(note that this is a point where it's really important what a language
does or does not guarantee)

Regardless, is a Jump-instruction which transfers else-control to a block five machine-instructions 'down', any less efficient than a jump which spans 50-instructions?

That depends on the CPU. Some CPUs have different jump instructions for different sizes (for example, for a typical risc cpu the instruction and
the offset have to fit in a 32 bit word. So you would be limited to
direct jumps of plus or minus a few hundred megabytes. For longer jumps
you need to load the address into a register and jump indirectly. CISC
CPUs with variable length instructions may have finer distinctions.) A
very short jump may continue within the same cache line or maybe even on
an instruction which has already been decoded. A longer jump may have to
load the next instruction from RAM. Or a jump to the beginning of a
cache line may be faster than one to the middle. And then of course
there is branch prediction ...

So lots of variability there.

There is of course the opposite view that you should just get all of the confounding factors out of the way first, so that the default is also
the common case. I also do that sometimes, but then I don't hide this in
in an else: clause but do something like this:

for item in whatever:
if not_this_one(item):
continue
if neither_this_one(item):
continue
if cant_continue(item):
break
if oopsie():
raise SomeError()

do_something_with(item)
and_some_more(item)
we_are_done(item)

which shows visually what the main purpose of the loop (or function or other block) is.

Nicely stated!

NB I've seen sufficient of @Peter's posts to know that this was never (even implied to be) intended as a snippet for all occasions!

It also illustrates why such is less readable: because we have to scan four if-statements before we can 'see' the purpose of the loop. My 'itch' would
be to extract this code 'out' to a function - that way the name will convey the somewhat-obscured purpose of the loop.

Alternately, reduce the 'distractions':-

try:
for item in whatever:
inspect_the_data( item )
do_something_with(item)
and_some_more(item)
we_are_done(item)
except SomeError:
...
except CustomBreakException:
... ?pass? # same effect as break

by 'hiding' in:

def inspect_the_data( item ):
if not_this_one(item):
continue

This doesn't work. You can't continue (or break) a loop in a calling
function. (I think it works (or used to work) in Perl, but you'll get a warning.)

You could
raise CustomContinueExcection()
and add a �try ... catch CustomContinueExcection: pass� block in the
loop.

In some ways, (IMHO) there are reasons to feel disquiet over this style of coding. Learning "Modular Programming", and slightly-later "Structured Programming", when they were still new (?fresh, ?exciting), we were inculcated with the 'one way in, one way out' philosophy-of-correctness.
This applied to "blocks" of code (per "module"), as well as formal units, eg functions.

Yeah, there is a fine line between using exceptions to hide unnecessary
detail and using exceptions to make a program impenetrable. Or maybe
it's not a fine line but a wide grey area?

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNEbGMACgkQ8g5IURL+ KF2LmhAApKRLFr9G68ZLasBsgo8Wo4oMsN5uImql4q7vlVmmPtrhDmaMWiLvMHf7 bX6z4thqv7JhUncZ+O11Jxj11tarhbQDvUicg5Ihx+90GZqKE8UKki+rDNKqX/4P mda+ShTmFFj1BGG/r1bmEnk/z7+kX/uZgWczemExJz6l2l4G5OHhQB6UcAiPNJ6o 3MbkWE4CuvSqQurkitFYcDIUFRdIbkZtBND5OFwE+kvjfBffRO+v8p9XUeCQ6/mK fwA6axB2rXWHzHExfPk+zsg8hc1a7qTL6e+5pTuuga6Lb+rE1/Xs9zxvNCebmye9 kV7ggj31Ot8V5oxqVDMawPHvB7QCbjW7o7wf+NCx0TdvYIRI10jWRPPRT4y0wWBI tNCVXiblEAYdy2NDJqoGTTUI1vEcmzZdv1/1TzFvdT4q0u9ptY7t4fN3WeKpaapw kbfHLdcLUdfHv1MTDSQoeRdiQuIQAZAjA6UyufDqVS83Ru0AmRWGqTZO+5zAd+jM XaS3nYUUUAfJmAA/LM+lcu29ko4WhUBkcjStZsd8vnR4mL18JSis5+KfYNcUjCsl 9BZYL2xrZWYSx7XB0sRTzLtVZTTS3TBlsL1Dm1si53X0SwGaXn7QUItRXJCDrw2H EtbqX/0OpvHwR4jHt1OR1dzrdCJkARwSCy++xXu

On 09/10/2022 15.02, Peter J. Holzer wrote:

On 2022-10-09 15:32:13 -0400, Avi Gross wrote:

and of course no pipelines.

Since you've now used that term repeatedly: What is a pipeline in
Python?

Could it be what's discussed starting on page 35 of this presentation? <http://www.dabeaz.com/generators/Generators.pdf>

--
Michael F. Stemper
Life's too important to take seriously.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/10/2022 19:25, Weatherby,Gerard wrote:

pylint, at least, provides a warning:

fe.py:4:0: W0120: Else clause on loop without a break statement (useless-else-on-loop)

I'm using flake8, it does not, alas.

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

pylint, at least, provides a warning:

fe.py:4:0: W0120: Else clause on loop without a break statement (useless-else-on-loop)


sum = 0
for i in range(5):
sum += i
else:
print("Always executes")
print(sum)


From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Axy via Python-list <python-list@python.org>
Date: Monday, October 10, 2022 at 1:10 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

On 10/10/2022 15:52, Weatherby,Gerard wrote:

I wonder if for/else could have been less confusing if it was
referred to
as for-break-else and if the else clause was only valid syntax if the
for
loop actually contained a break statement in the first place.

Sounds reasonable. It would be something alike UnboundLocalError when
a local variable referenced before assignment. If they won't remove
"else" completely in far future, that checking really worths
implementing now.

Actually, I think a warning would be sufficient, as in the following
quick prototype. If someone can implement this quickly in CPython, that
would be great (last time I hacked it, it was 2.4)

Axy.

import ast

tree = ast.parse('''
# sample code
a = 0
for i in 'asd':
a += i
while x:
pass
else:
print('wow')
break
print(i)
else:
print(0)
''', mode='exec')

def check_ast(node):
if isinstance(node, (ast.For, ast.AsyncFor, ast.While)):
if node.orelse and have_no_break(node.body):
print(f'Warning: the loop at line {node.lineno} has no
"break" statement,'
f' "else" clause at line {node.orelse[0].lineno}
won\'t run')
else:
for child in ast.iter_child_nodes(node):
check_ast(child)

def have_no_break(loop_body):
for node in loop_body:
if isinstance(node, (ast.For, ast.AsyncFor, ast.While)):
# nested loop
check_ast(node)
elif isinstance(node, ast.Break):
return False
elif isinstance(node, list):
for child in ast.iter_child_nodes(node):
if have_no_break(child) == False:
return False
return True


for node in tree.body:
check_ast(node)
-- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mlK4jRkfDC_akw-fIqWaMVf707GQsiyvj_sRHTsFnuG4ak5mKWwSavtz4njlBNIu1H0VHrR9gyjuQpxGqZ1dacU1Xw$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/
python-list__;!!Cn_UX_p3!mlK4jRkfDC_akw-fIqWaMVf707GQsiyvj_sRHTsFnuG4ak5mKWwSavtz4njlBNIu1H0VHrR9gyjuQpxGqZ1dacU1Xw$>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-09 22:38:28 -0400, avi.e.gross@gmail.com wrote:

[This is an answer for Peter and can easily be skipped by those who know or have no wish to.]

Strictly speaking Peter, the word "pipe" may not mean quite something in Python but other concepts like chaining may be better.

The original use of the word I am used to was at the UNIX shell level where an in-core data structure called a pipe was used

To paraphrase Mark Twain, the reports of Unix' death have been greatly exaggerated.

Unix (or at least its bastard offsprings Linux and OSX) is alive and
well and still has pipes. I use them every day.

If you have an object with some method you can call on it (or in some cases
a normal function call) that returns another (or the same) object, then you can write code like:

This.that.other

Yeah, I thought you might be referring to that. I've just never seen the
term "pipeline" for that construct (I think "method chaining" is
reasonably common).

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNEbv8ACgkQ8g5IURL+ KF2ILBAAmqn3H2FraU/9W7Gb1JrKCYPAB3RNcpdzW2we07ATuBDMwPBX2dDl3JiO +Kuvr/jBRCugag6ewH4q1ynAO5e5yJCzjjVz5TCpmElG9Xw4ePnkMeUgX6rYpb6w IPOv17sXi/fzIQ8O3yRiOPLOnPH0T5sXGYnM8nTCY3rAHDp6zCDk7ePI74Zc6Cl2 TcCwYrRcW5/GyxxTJ54XN8SGL0YdOIi88dHTDKfWdoXBikNlK1fJIR/ueu7ubO72 H2hIIxlZLrUW2hfBa4IOiPqv/g85s7eV0rOM/6kCkkfKzzeegoBL4WbjWmHhh9Mz kQjF2eRARDhH2HcOUDAwGsvrpWPAsRhuf3EAwbw8pqgp9hxDHfXSreCR0boFu7GP bfl8cL3Cf+ufb+oYaXsVoFk5PhpV85kacuNKlNLKFlrS+6i7wQhmggO3+mJcD8cn oX2UOBJNNWB6CVsdvCFkIVvyQviqA3MjP8jZMY2irZoyhvz+G/ZW+K/J4fmbNyab DMUcTyoNxTkm6ZOr2XXVdiDDCliU5zLPpKK6KqfAlK/5yYoj8UVX08bH+8UFxRg+ p1VxmbAxyYQH4my4riRRKMPbbtz3/yPUYS98CHE9He3lp4izFkN3g2kXMKznNc7g Zxx7ewQrCFQuKKz8YnVyjV9+BI9+fukgzWf3DhY

I just want to get clear on what may be a side issue

The suggestion is that a loop with an ELSE clause only makes sense if the
user can BREAK out without finishing, right?

My first question is whether a warning or even error makes sense if there is
no BREAK statement anywhere in the loop but there is another way to break
out such as a RETURN statement or perhaps from an error induced that is not caught and then propagates outward?

Or is there some mechanism that would still run the ELSE clause in such
cases?

The second is to note some break statements are potentially never executed
such as: if False: break

There are actually scenarios where you can remain in a loop to the end and
not do anything rather than break, but of course in that case, the ELSE
clause running makes little sense to only run if you finish normally unless
it can use a shared Boolean variable you used to skip the rest of the loop
and use that to decide. That can be done easily enough without the ELSE, I would think.



-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Weatherby,Gerard
Sent: Monday, October 10, 2022 2:25 PM
To: Axy <axy@declassed.art>; python-list@python.org
Subject: Re: for -- else: what was the motivation?

pylint, at least, provides a warning:

fe.py:4:0: W0120: Else clause on loop without a break statement (useless-else-on-loop)


sum = 0
for i in range(5):
sum += i
else:
print("Always executes")
print(sum)


From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Axy via Python-list <python-list@python.org>
Date: Monday, October 10, 2022 at 1:10 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

On 10/10/2022 15:52, Weatherby,Gerard wrote:

I wonder if for/else could have been less confusing if it was
referred to as for-break-else and if the else clause was only valid
syntax if the for loop actually contained a break statement in the
first place.

Sounds reasonable. It would be something alike UnboundLocalError when
a local variable referenced before assignment. If they won't remove
"else" completely in far future, that checking really worths
implementing now.

Actually, I think a warning would be sufficient, as in the following quick prototype. If someone can implement this quickly in CPython, that would be great (last time I hacked it, it was 2.4)

Axy.

import ast

tree = ast.parse('''
# sample code
a = 0
for i in 'asd':
a += i
while x:
pass
else:
print('wow')
break
print(i)
else:
print(0)
''', mode='exec')

def check_ast(node):
if isinstance(node, (ast.For, ast.AsyncFor, ast.While)):
if node.orelse and have_no_break(node.body):
print(f'Warning: the loop at line {node.lineno} has no "break" statement,'
f' "else" clause at line {node.orelse[0].lineno} won\'t run')
else:
for child in ast.iter_child_nodes(node):
check_ast(child)

def have_no_break(loop_body):
for node in loop_body:
if isinstance(node, (ast.For, ast.AsyncFor, ast.While)):
# nested loop
check_ast(node)
elif isinstance(node, ast.Break):
return False
elif isinstance(node, list):
for child in ast.iter_child_nodes(node):
if have_no_break(child) == False:
return False
return True


for node in tree.body:
check_ast(node)
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python- list__;!!Cn_UX_p3!mlK4jRkfDC_akw-fIqWaMVf707GQsiyvj_sRHTsFnuG4ak5mKWwSavtz4n jlBNIu1H0VHrR9gyjuQpxGqZ1dacU1Xw$<https://urldefense.com/v3/__https:/mail.py thon.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mlK4jRkfDC_akw-fIqWaMVf70 7GQsiyvj_sRHTsFnuG4ak5mKWwSavtz4njlBNIu1H0VHrR9gyjuQpxGqZ1dacU1Xw$>
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 11 Oct 2022 at 08:55, Robert Latest via Python-list <python-list@python.org> wrote:

Chris Angelico wrote:

Yes, I'm aware that code readability becomes irrelevant for
short-duration projects. Beside the point. I'm wondering how important
it really is to have the shortest block first.

I usually put the most expected / frequent / not negated block first if the whole if/else statement is not "too long". Sometimes whatever you want to do becomes pointless if a certain conditions is not met, in which case I do an early break or return and have no else block at all.

Given that for-else is an excellent, if rarely-used, construct

I knew it existed but coming from C I never thought to exploit it. I know I wrote loops like this:

found = None
while not found:
found = search(something)
if found:
break
if not found:
complain()

Need to look into using "else" in these cases.

Yep, that's exactly what for-else is great at!

while True:
if search(something): break
else:
complain()

(although rather than a "while True", you're probably iterating over
things to search for, in some way)

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 10/10/2022 om 04:38 schreef avi.e.gross@gmail.com:

[This is an answer for Peter and can easily be skipped by those who know or have no wish to.]

Strictly speaking Peter, the word "pipe" may not mean quite something in Python but other concepts like chaining may be better.

The original use of the word I am used to was at the UNIX shell level where an in-core data structure called a pipe was used to connect the output of
one process to the inputr of another, sometimes in long chains like:

cat file1 file2 file3 | grep pattern | ... | lp

Something like that can be done in python with the same kind of syntax:

https://code.activestate.com/recipes/580625-collection-pipeline-in-python/

I have my own python3 module with stuff like that and I find it very usefull.

--
Antoon Pardon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Anton,

Your example overlaps with the use of generators in Python to do variants of the same pipeline ideas.

But is that native python or some extension where "|" has been modified to
mean something other than a form of OR in some places? What module do you
need to load to make that happen?

I think there is a long history in Computing where it may be easier to write languages that do things in what some call Reverse Polish Notation and you
have languages of the LISP variety, as one example, that suggest code like (MULT (ADD 1 2) (SUB 5 3)) which gets really annoying for longer
calculations like say the quadratic formula. People (and many programmers
are still people) often prefer some form of infix notation even if the
machine gets re-arranged code that does something like the above.

Pipes in UNIX had real asynchronous but coordinated meaning and often ran
quite a bit faster as some parts could run while others were doing I/O or otherwise waiting. BUT it often led to fairly quick and sloppy solutions
that probably could have been done faster within one application without
lots of overhead.

The kind of pipelines we have been talking about, mainly in Python albeit I mentioned the versions in R, are largely syntactic sugar where often there
is really a single thread of execution which can range from almost
meaningless (as in each part runs to completion and generates lots of data
that is then used by the next stage and eventually intermediates are garbage collected) to some with a sort of zig-zag approach where smaller chunks of
data are made as various functions are called and yield a partial result and
go to sleep as the next function that called it does something similar.
There may be little or no speedup of the code or even a slowing down.

What would be needed for a better emulation of the UNIX (and later LINUX and etc.) pipeline is closer to having asynchronous processes running on
multiple cores and yet communicating efficiently. And it need not be linear. Consider a merge sort as an example where each level subdivides the data and calls multiple others to recursively work on it and the parent waits for
them all to complete and then merges the results. Some algorithms along
those lines can be run across machines entirely or using machines all over
the internet. You can imagine a chess program that ships all reasonable possible next moves to others and gets back some analysis of how well each
move is rated based on multiple levels of look-ahead from each child that farmed out the possible moves to the next level. This kind of approach can
be treelike or a generalized graph and also in higher dimensions.

An example of what I mean by dimensions is tools that work on XML or just
HTML, like xpath or jquery and have various "dimensions" such as following
in a direction that chooses based on ID versus a direction based on CLASS versus a direction based on ancestry, or siblings, or ordinality and many
other such attributes. But enough of that.

Back to your point, the map/filter/reduce kinds of functionality have long
been used in various kinds of functional programming in many languages and
are a way to do pipelining, albeit usually in a more RPN way by nesting function calls within function calls in a harder-to-read way. If the syntax change allows a pipe symbol so it can be written infix, that helps
programmers who prefer to think more linearly.

But since the original topic here was loosely about loops and the silly
choice (there was no great choice) of re-using the ELSE keyword, I note how commonly we often use loops as in:

for first in iterator:
for second in iterator:
...

The second (and deeper) loop(s) sort of run faster than the outer ones. But compare that to how you might write a comprehension like:

[x*y*z for x in range(5) for y in range(5) for z in range(5)]

The above acts sort of like a pipeline as in the first "for" sends 0 to 4 to the second which passes that along plus another 0..4 to the next one which passes that plus it's own contribution to the main body which multiplies
them and adds them to a growing list. Of course the problem in the example
is that the main body is in front even as it is I a sense done last, and the entire construct does the collecting of the results invisibly into a list.
For some people I know, the nested loop version makes more sense and for
some people the comprehension method seems more inline, or at least
condensed.

My point is perhaps both subtle and blatant. There are tons of IDEAS out
there that superficially have some ways they can be perceived as similar but ultimately can be seen to differ in many ways and are not the same thing and often are not interchangeable. A pipeline construct with some kinds of generators can generate an "infinite" amount of data in theory, but in
practice only an indefinite amount, such as the first N primes with N not
being a constant. Another pipeline that calculates the first million primes
and feeds them in a pipeline that perhaps quits after seeing the first few dozen, may look similar but wastes lots of resources in computing too much
and storing too much. And it fails if the program turns out to need more
than a million.

The map and filter and reduce methods often call a function repeatedly on
data and combine the results. But if you use a generator, calling it
repeatedly is more like continuing the existing instance that is just hibernating and can have very different results. Similarly, languages that
are vectorized may do better to not be called through these functions as
they can perform the many operations on their own on known data of a known length. But they can often be easy to pipeline in various ways with other
such vectorized functions somewhat more directly.

This forum often talks about what methods seem more "pythonic" than others. Arguably generators are now part of a pythonic way for many. Not sure if various ideas of "pipelines" are equally pythonic and some may really be
rather foreign to many programmers, at least until they catch on.

Avi


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Antoon Pardon
Sent: Tuesday, October 11, 2022 10:30 AM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?



Op 10/10/2022 om 04:38 schreef avi.e.gross@gmail.com:

[This is an answer for Peter and can easily be skipped by those who
know or have no wish to.]

Strictly speaking Peter, the word "pipe" may not mean quite something
in Python but other concepts like chaining may be better.

The original use of the word I am used to was at the UNIX shell level
where an in-core data structure called a pipe was used to connect the
output of one process to the inputr of another, sometimes in long chains

like:

cat file1 file2 file3 | grep pattern | ... | lp

Something like that can be done in python with the same kind of syntax:

https://code.activestate.com/recipes/580625-collection-pipeline-in-python/

I have my own python3 module with stuff like that and I find it very
usefull.

--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/10/2022 16.19, avi.e.gross@gmail.com wrote:

I won't reply to everything Dave says and especially not the parts I fully agree with.

I think in many situations in life there is no ONE way to do things so most advice is heuristic at best and many exceptions may exist depending on your chosen approach. As such, I do not really think in PYTHON when writing code but an amalgam of many

languages with all kinds of ways of doing things and then zoom in on how to do it in the current language be it Python or R or JavaScript and so on. Yes, I am in some sense focused but also open, just as in Human languages I may mostly be thinking in
English but also sometimes see words and phrases pop into my mind from other languages that mean about the same thing and then filter it out to focus on whichever language I am supposed to be using at the time.

Given that we can both remember programming last-century, this
surprised. (or may have misunderstood!)


If we think, in German, of some parting words for an older friend
departing on a long trip, and translate word-for-word into English we
might come out with: "May God pickle you".

There is a second step, which is to examine the 'solution' in terms of
its expression (how the communication will be received), and thus the more-correct English expression would be: "May God preserve you"!

The two p-words are sufficiently-similar in meaning to appear
synonymous, when examined in-isolation. However, that first expression
would at least bemuse an (only) English-speaker, and quite possibly confuse!


One of the problems which 'appeared' when programmers were first given direct-access to the computer, eg time-sharing mini-computers; and which persists to this day, is "the rush to code". Indeed there are (still)
some 'managers' who think that unless a programmer is writing code (s)he
isn't 'working' - but we're only interested in our own behavior.

Accordingly, "design" and "development".

Back-when, some lecturers insisted that we first create a flow-chart or
a pseudo-code solution for an assignment - BEFORE we coded in COBOL,
FORTRAN, or whatever. In many ways, because we were learning the programming-language, most felt it very difficult to draw a flow-chart
that didn't merely look like FORTRAN.
(to make that worse (for ourselves) I suspect many of us performed the
latter first, and then ...) Many of us will have felt this some sort of academic-exercise or even 'a nuisance', but there was 'method in their madness'!


Relating back to the comment (above): when *designing* a solution/flow-charting/pseudo-code, an "amalgam" of programming
constructs and human-language expressions will indeed add richness, opportunity, and alternatives. All serving to amplify analytic and
design skill.

Conversely, when *coding*, the skill comes from employing the (specific, programming) language to best advantage. At which time, one's
JS-knowledge is almost irrelevant, because the task is to convert a
design outline or planned-solution, into Python.
(idiomatic, pythonic, efficient, readable, ...)
--
Regards,
=dn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-11, <avi.e.gross@gmail.com> <avi.e.gross@gmail.com> wrote:

But is that native python or some extension where "|" has been modified to mean something other than a form of OR in some places?

The latter.

What module do you need to load to make that happen?

The provided link is for a page that shows the module and explains the
usage.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/10/2022 06:15, avi.e.gross@gmail.com wrote:

Chris, a short(er) answer to your addition below.

I did not at first share your perception but maybe do now. If the argument was that ELSE and other constructs like FINALLY or CATCH are horrible
because they follow other code and important things should be first, that is a silly argument.

You know, sometimes I'm of the same opinion, especially looking at
"defer" efforts in Go.

However, I wouldn't judge that in terms of mental capabilities. Every
construct has some initial rationale but sometimes even best practices eventually become notorious. There are many point of views to every
feature but in general features aren't divine and worth revising even
this looks disparaging.

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Axy <axy@declassed.art> writes:

So, seriously, why they needed else if the following pieces produce same >result? Does anyone know or remember their motivation?

Just wrote code wherein I used "else"! This:

import locale
for name in( 'de', 'de_DE', 'deu_deu', 'deu', 'German', 'Deutsch' ):
try: locale.setlocale( locale.LC_ALL, name ); break
except locale.Error: pass
else: print( "Programm kann deutsche Schreibweise nicht einrichten." )

.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

As did I.

tree = ET.parse(lfile)
for child in tree.getroot():
if child.tag == 'server':
break
else:
raise ValueError(f"server tag not found in {lfile}")

I think there are other places I could be using it, but honestly I tend to forget it�s available.

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Stefan Ram <ram@zedat.fu-berlin.de>
Date: Wednesday, October 12, 2022 at 2:22 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

Axy <axy@declassed.art> writes:

So, seriously, why they needed else if the following pieces produce same >result? Does anyone know or remember their motivation?

Just wrote code wherein I used "else"! This:

import locale
for name in( 'de', 'de_DE', 'deu_deu', 'deu', 'German', 'Deutsch' ):
try: locale.setlocale( locale.LC_ALL, name ); break
except locale.Error: pass
else: print( "Programm kann deutsche Schreibweise nicht einrichten." )

.


-- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iyDac-XjNlj78G0XwNzZ-FEHyuCZIy33n3cI9MUDM_FnEdR04mSQ5Ln0OA1ETUNloyH24iY9meNHVdixLgWRYL8$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/
python-list__;!!Cn_UX_p3!iyDac-XjNlj78G0XwNzZ-FEHyuCZIy33n3cI9MUDM_FnEdR04mSQ5Ln0OA1ETUNloyH24iY9meNHVdixLgWRYL8$>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-10 10:11:10 +0000, Stefan Ram wrote:

I would not use tabs in source code as they are not
displayed in the same way everywhere.

Some would argue that this is a feature. Different people prefer
different indentation widths. Using a single tab character for an
indentation level allows everybody to view the file in their preferred
layout.

I have, however, found out that this requires more discipline than I and
the people I work with can muster. There is always someone who
accidentally converts some tabs to spaces, messing up indentation for
everyone else. So I require a "indent by x spaces" rule for all projects
I work on (unless the language convention have a strong preference for
tabs, like in Go).

In email I would always use spaces. Tabs are just too unreliable there.

Functions also come at a cost. From the Web:

^^^^^^^^^^^^
Ah yes. Your infamous aversion against useful citations strikes again.

For those too lazy to use a search engine, the excerpt seems to be from https://softwarebyscience.com/very-short-functions-are-a-code-smell-an-overview-of-the-science-on-function-length/

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNHU7QACgkQ8g5IURL+ KF2qoA//Y33q2hV+dCLnbu18L+tczYRxFD5NYsl123ZEW/JTpAjBhU87gHc77R40 bcdChC+RvI8MISMvXEfGPz0Ze0SMben3nWkQj7iHjya3FGCCxwOW/2ohxQUhGEMI LCxdTZEpW6ZPBNKbIXC/6OV1JSidJJrSQAbUO47QpwX3G4LVK0pLGPHqj9/2FJuE R3XWRxXCtfxeV9h9L9k+hJsn7DITQnTU5MJjL6W/oYWQZUPlAIBMR1n5Rxeg8BiN t1Z3+e73NzoGYgrT224S6LnGW9CQIIFpvgVcXNcsZqFjJJiq8CpXUig5YBcrz1F2 pCYbPqiyllNUvoW+EvmQF2CdvMzrXtgI/QoCZ9glQxyOg1lg1a2m4vijn/pZYIos lRnGsT8tSI9WbcK9uctYZ6BpvJMJ1ZR5fwGcZVMlllbeIb5RUOB/VNuQUZTOZFTJ DD2zBjzsbj9pG9LFKIp2JNQF4nDnNsXh+k8ubiNQYPhahJ6uICj980qWNjMhkhuW JaAWycEz0yM+uJMhlfYdsx7Wvrz1yP+ZS1rwrD9n2kf4QssVcpdJpHnk16Ftz79+ MudADvbkJ9kozNzzpz8eODc6T54f/mbgHxpv5Dc1oMf1plL9JvoZ8+4KWTma5iaQ RkmLyAuE24BKEZSn+82j8SE2uZ8N2RjO9dSpGi0

On 2022-10-10 16:48:04 +0000, Robert Latest via Python-list wrote:

Axy wrote:

Also not really a justification for "shortest block first". Wanting
some elaboration on that. What's the value in it?

Well, the value is productivity. No need to save puzzles "what this hanging else belongs to?"

If you find yourself asking that question, the if-block is probably too long to
begin with.

ACK.

Code small things first and return early, same

^^^^^^^^^^^^

as taking a test: do easy and quick things first and boring and
difficult ones later.

Yes, but in that case you have a very long indented "else" block,

If you return you don't have to indent the rest.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNHVDIACgkQ8g5IURL+ KF0G3A/9Gjd7t41nXc4gagiDv9jNKVSXjCh+nJF4GX6ySQb0TphcKyBmyvXP9Rr0 H/5GoX8Rf3P2Jv8PPvTc36zLaJ66vnCIi3NmDrrLEPYdhCIByOkQMMm4l/X337N1 tdDqeefYn4qA24IJV0xr7UCMPOUqIJwKld7t1F5PiK74TBiFHsgBC/ZFEub2UDl3 lcP/W2q1SELwoDSyNMqlz2PhmmU176Xmnt/29AcKQ+/IeDblLHzH4hIs13x+RPq3 NP0YLoDWZUH3duccRGI+yW8pwT2gpb47r4sc/RtTMgXYAmMtUnNzg0B9Klp7muYj P4grARD2h9CX58AUl83UDQFioleE4QYXF5dwOe+v468nU+JalyjN247ZpMQRxyfh b7JsJ4cTKHSk4TX6Mxt/JPT/NdDHDzUaiv6RoiJ2AdR5QMNQ0m2A4LGy1CHN2zu6 ggdksOa9GafhJKWqGyO9rR6Vb6eLNbUGLesz2nT00Xi00UVI2MFOfBqDfD4/VDfo o63BqUVpv4ekoWeBTZFqum3jB9+NYT/65hpRC4PYqDFMuxGsQ0FWqk2wZwifuKOw TDlFqdJcxN/uUG5X8QumhHyC9lCrsyaGC2m924646Q0ZArfz72TIZbQV2Vmsymzz ycAdeUQadvrex+xqjOp7qrl0mFSDQFUg9XFbBYc

On 11/10/2022 02.13, Grant Edwards wrote:

On 2022-10-10, Chris Angelico <rosuav@gmail.com> wrote:

On Mon, 10 Oct 2022 at 11:52, MRAB <python@mrabarnett.plus.com> wrote:

On 2022-10-10 00:40, dn wrote:

On Sun, 9 Oct 2022 at 15:39, Axy via Python-list
<python-list@python.org> wrote:

"shortest block first"

Have never heard this advice before. Kind-of rankled with me, as it did >>>> for others.

I've followed that advice for several decades. I find it much easier
to read code that's organized that way -- particularly when the
difference in block sizes is large (e.g. the first block is one line,
and the second is a a hundred).

Makes sense. Keep the 'cause' and 'effect' close together. In other
words, making it easy to look 'up' from one of the 'suites' to see the if-statement/condition which directs that logic-branch.


Contrarily, (see @Karsten, earlier) the preference to bundle the
"hundred" into one or more functions, rather than present as a 'wall of
text'. Added advantage: well-chosen function names(!) will remind the
reader of the purposes(!) of the "hundred".

Once both suites are short[ened], visibility improves (readability), and
the above contention goes-away. Thus the sense of the condition becomes
the most worthy consideration.

--
Regards,
=dn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I too have occasionally used for ... else.  It does have its uses. But
oh, how I wish it had been called something else more meaningful,
whether 'nobreak' or whatever.  It used to really confuse me.  Now I've learned to mentally replace "else" by "if nobreak", it confuses me a bit
less.
Rob Cliffe

On 12/10/2022 22:11, Weatherby,Gerard wrote:

As did I.

tree = ET.parse(lfile)
for child in tree.getroot():
if child.tag == 'server':
break
else:
raise ValueError(f"server tag not found in {lfile}")

I think there are other places I could be using it, but honestly I tend to forget it’s available.

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Stefan Ram <ram@zedat.fu-berlin.de>
Date: Wednesday, October 12, 2022 at 2:22 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

Axy <axy@declassed.art> writes:

So, seriously, why they needed else if the following pieces produce same
result? Does anyone know or remember their motivation?

Just wrote code wherein I used "else"! This:

import locale
for name in( 'de', 'de_DE', 'deu_deu', 'deu', 'German', 'Deutsch' ):
try: locale.setlocale( locale.LC_ALL, name ); break
except locale.Error: pass
else: print( "Programm kann deutsche Schreibweise nicht einrichten." )

.

-- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iyDac-XjNlj78G0XwNzZ-FEHyuCZIy33n3cI9MUDM_FnEdR04mSQ5Ln0OA1ETUNloyH24iY9meNHVdixLgWRYL8$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/

python-list__;!!Cn_UX_p3!iyDac-XjNlj78G0XwNzZ-FEHyuCZIy33n3cI9MUDM_FnEdR04mSQ5Ln0OA1ETUNloyH24iY9meNHVdixLgWRYL8$>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-12, Rob Cliffe via Python-list <python-list@python.org> wrote:

I too have occasionally used for ... else.  It does have its uses. But
oh, how I wish it had been called something else more meaningful,
whether 'nobreak' or whatever.

I use it a few times year. I have to look it up in the documentation
every single time I do, and I always add a comment in the "else"
clause stating whether the looped completed "normally" or not.

--
Grant

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12 Oct 2022 23:19:39 +0100, Rob Cliffe <rob.cliffe@btinternet.com> declaimed the following:

I too have occasionally used for ... else.� It does have its uses. But
oh, how I wish it had been called something else more meaningful,
whether 'nobreak' or whatever.� It used to really confuse me.� Now I've

"expired"?


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This has been discussed so often precisely because I swear NO CHOICE of keyword would satisfy everybody! Most languages start with designated keywords and some reserve a few for later use. But then things can get frozen in place to avoid breaking
existing programs or break older compilers/interpreters.

Some languages use techniques to extend themselves more harmlessly such as creating a singleton object that has content that can be regular data as in math.pi, or functions/methods or new ides like "Symbols" that allow all kinds of extensions to the
language in a fairly harmless way as no older program would likely have used features that did not exist.

That might not easily solve this problem. But I wonder if reserving some kind of prefix might help, so anything like extension.0nNoBreak could be added to a loop as a final clause and be treated as a non-key keyword of sorts.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, October 12, 2022 6:20 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?

I too have occasionally used for ... else. It does have its uses. But oh, how I wish it had been called something else more meaningful, whether 'nobreak' or whatever. It used to really confuse me. Now I've learned to mentally replace "else" by "if
nobreak", it confuses me a bit less.
Rob Cliffe

On 12/10/2022 22:11, Weatherby,Gerard wrote:

As did I.

tree = ET.parse(lfile)
for child in tree.getroot():
if child.tag == 'server':
break
else:
raise ValueError(f"server tag not found in {lfile}")

I think there are other places I could be using it, but honestly I tend to forget it’s available.

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org>
on behalf of Stefan Ram <ram@zedat.fu-berlin.de>
Date: Wednesday, October 12, 2022 at 2:22 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding,
opening attachments or clicking on links. ***

Axy <axy@declassed.art> writes:

So, seriously, why they needed else if the following pieces produce
same result? Does anyone know or remember their motivation?

Just wrote code wherein I used "else"! This:

import locale
for name in( 'de', 'de_DE', 'deu_deu', 'deu', 'German', 'Deutsch' ):
try: locale.setlocale( locale.LC_ALL, name ); break
except locale.Error: pass
else: print( "Programm kann deutsche Schreibweise nicht einrichten." )

.

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/p ython-list__;!!Cn_UX_p3!iyDac-XjNlj78G0XwNzZ-FEHyuCZIy33n3cI9MUDM_FnEd R04mSQ5Ln0OA1ETUNloyH24iY9meNHVdixLgWRYL8$<https://urldefense.com/v3/_ _https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iyDa c-XjNlj78G0XwNzZ-FEHyuCZIy33n3cI9MUDM_FnEdR04mSQ5Ln0OA1ETUNloyH24iY9me NHVdixLgWRYL8$>

--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 16 Oct 2022 at 21:19, Antoon Pardon <antoon.pardon@vub.be> wrote:

Op 16/10/2022 om 00:50 schreef avi.e.gross@gmail.com:

This has been discussed so often precisely because I swear NO CHOICE of keyword would satisfy everybody! Most languages start with designated keywords and some reserve a few for later use. But then things can get frozen in place to avoid breaking

existing programs or break older compilers/interpreters.

Some languages use techniques to extend themselves more harmlessly such as creating a singleton object that has content that can be regular data as in math.pi, or functions/methods or new ides like "Symbols" that allow all kinds of extensions to the

language in a fairly harmless way as no older program would likely have used features that did not exist.

That might not easily solve this problem. But I wonder if reserving some kind of prefix might help, so anything like extension.0nNoBreak could be added to a loop as a final clause and be treated as a non-key keyword of sorts.

My idea would be to reserve different unicode blocks for the keywords
and the identifiers. e.g. We could reserve the mathematical alphanumeric block for keywords and all other letters and numbers for identifiers.
Doing so would allow extenting the keywords without breaking programs
that already use that combination as an identifier.

Python currently defines identifiers as follows: https://docs.python.org/3/reference/lexical_analysis.html#identifiers

Briefly, what it means is that (aside from some backward compatibility
special cases) an identifier contains letters, numbers, and connector punctuation, and must not start with a number. It's not by blocks,
it's by types.

It's way WAY too late to change what's allowed for identifiers, as you
will potentially be breaking programs that use the current rules.

Python could slowly transition in this direction by first allowing the current keywords to be in this block. Every new keyword would only be in
that unicode block. If would then be possible to write python code with
this convention but it wouldn't be obligatory. After some time the
python developers could decide to make it obligatory.

Obligatory??? Please explain how you intend to convince the entire
world that non-ASCII code is an acceptable requirement. Explain to me
how you're going to go to every text editor and ensure that it
supports easy entry of Python keywords that aren't ASCII. And please
explain how this is even better.

I doubt this will idea will get from the ground, but I think it would
allow for a smoother transition into new concepts, as it is no longer a strugle searching for a keyword that will break as little programs as possible.

Yeah it won't. Good luck though.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 16/10/2022 om 00:50 schreef avi.e.gross@gmail.com:

This has been discussed so often precisely because I swear NO CHOICE of keyword would satisfy everybody! Most languages start with designated keywords and some reserve a few for later use. But then things can get frozen in place to avoid breaking

existing programs or break older compilers/interpreters.

Some languages use techniques to extend themselves more harmlessly such as creating a singleton object that has content that can be regular data as in math.pi, or functions/methods or new ides like "Symbols" that allow all kinds of extensions to the

language in a fairly harmless way as no older program would likely have used features that did not exist.

That might not easily solve this problem. But I wonder if reserving some kind of prefix might help, so anything like extension.0nNoBreak could be added to a loop as a final clause and be treated as a non-key keyword of sorts.

My idea would be to reserve different unicode blocks for the keywords
and the identifiers. e.g. We could reserve the mathematical alphanumeric
block for keywords and all other letters and numbers for identifiers.
Doing so would allow extenting the keywords without breaking programs
that already use that combination as an identifier.

Python could slowly transition in this direction by first allowing the
current keywords to be in this block. Every new keyword would only be in
that unicode block. If would then be possible to write python code with
this convention but it wouldn't be obligatory. After some time the
python developers could decide to make it obligatory.

I doubt this will idea will get from the ground, but I think it would
allow for a smoother transition into new concepts, as it is no longer a
strugle searching for a keyword that will break as little programs as
possible.

--
Antoon Pardon.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 16/10/2022 om 13:03 schreef Chris Angelico:

On Sun, 16 Oct 2022 at 21:19, Antoon Pardon<antoon.pardon@vub.be> wrote:

My idea would be to reserve different unicode blocks for the keywords
and the identifiers. e.g. We could reserve the mathematical alphanumeric
block for keywords and all other letters and numbers for identifiers.
Doing so would allow extenting the keywords without breaking programs
that already use that combination as an identifier.

Python currently defines identifiers as follows: https://docs.python.org/3/reference/lexical_analysis.html#identifiers

Briefly, what it means is that (aside from some backward compatibility special cases) an identifier contains letters, numbers, and connector punctuation, and must not start with a number. It's not by blocks,
it's by types.

It's way WAY too late to change what's allowed for identifiers, as you
will potentially be breaking programs that use the current rules.

So? Python has broken backward compatibility before. The cost could
be acceptable. How many programs do you estimated use the mathematical alphanumeric block for an identifier at this moment?

Python could slowly transition in this direction by first allowing the
current keywords to be in this block. Every new keyword would only be in
that unicode block. If would then be possible to write python code with
this convention but it wouldn't be obligatory. After some time the
python developers could decide to make it obligatory.

Obligatory??? Please explain how you intend to convince the entire
world that non-ASCII code is an acceptable requirement. Explain to me
how you're going to go to every text editor and ensure that it
supports easy entry of Python keywords that aren't ASCII. And please
explain how this is even better.

Why should I do that? It seems you have already made your mind up.
That is fine. It just makes explaining not very senseful.

I doubt this will idea will get from the ground, but I think it would
allow for a smoother transition into new concepts, as it is no longer a
strugle searching for a keyword that will break as little programs as
possible.

Yeah it won't. Good luck though.

Why would I need good luck? I expressed an idea and you didn't like it.
That won't affect my life in a meaningful way.

--
Antoon Pardon.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 16 Oct 2022 at 22:47, Antoon Pardon <antoon.pardon@vub.be> wrote:

Op 16/10/2022 om 13:03 schreef Chris Angelico:

On Sun, 16 Oct 2022 at 21:19, Antoon Pardon<antoon.pardon@vub.be> wrote:

My idea would be to reserve different unicode blocks for the keywords
and the identifiers. e.g. We could reserve the mathematical alphanumeric >> block for keywords and all other letters and numbers for identifiers.
Doing so would allow extenting the keywords without breaking programs
that already use that combination as an identifier.

Python currently defines identifiers as follows: https://docs.python.org/3/reference/lexical_analysis.html#identifiers

Briefly, what it means is that (aside from some backward compatibility special cases) an identifier contains letters, numbers, and connector punctuation, and must not start with a number. It's not by blocks,
it's by types.

It's way WAY too late to change what's allowed for identifiers, as you
will potentially be breaking programs that use the current rules.

So? Python has broken backward compatibility before. The cost could
be acceptable. How many programs do you estimated use the mathematical alphanumeric block for an identifier at this moment?

Why would I need good luck? I expressed an idea and you didn't like it.
That won't affect my life in a meaningful way.

Well, with that attitude, it's not going to affect anyone else's life
either, so go ahead, carry on.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Interesting idea, Anton.

I would be interested in hearing more detail on how it would work.

Although much of programming has been centered on the Latin alphabet and especially English, that may change. I can imagine a customized compiler or interpreter that uses key words in the local language instead of for or
while or if or else or even import.

If a region of UNICODE was set aside, would it have to be as a sort of additional ALT or shift key for anything, or just English characters or
would it be for abstract symbols that would be mapped to and from a long
list of reserved key words that may vary by locale?

A serious problem I have been noting is the interactions between
typographical paradigms never expected to interact. I mean special
characters allowed or expected that clash. An example in Python and many
other languages is regular expressions. When using a string of characters,
you may have to deal with the rules for evaluating a string of that type
and double up backslash characters or be carefully as a dollar sign or
curly brace might invoke a side effect and interpolate something into it.
But for languages that allow RE to be entered without a string as in /.../
you have to write it differently.

I noted other ways in which naming conventions and even sort of keywords
need special care. Consider a Javascript program in a browser that can read
and manipulate HTML and CSS. The rules for names in JS do not allow hyphens while others often do. So the programmers making the structures in the DOM
had to twist things. To access something like font-type you ask for font
Type as an example by changing the identifier to camel case.

I sometimes have programs that combine R and Python somewhat
interchangeably and it highlights places the naming does not match. R
allows periods as parts of names as in my.data and almost anything
including spaces if you use grave accent quotes such as `one [identifier`
so it is perfectly valid to have a function call like `[`(x, 5) to mean
x[5] albeit explaining why that is useful is beyond the scope. Similarly
you can make all kinds of in-line functions between percent signs as in %*%
or %specialized computation% and you sort of make your own keywords albeit Chris and others may rightly suggest they are something else rather than
the first level of syntax.

My point is that your idea may need to support keywords for disparate ideas
and languages.

On Sun, Oct 16, 2022, 6:20 AM Antoon Pardon <antoon.pardon@vub.be> wrote:

Op 16/10/2022 om 00:50 schreef avi.e.gross@gmail.com:

This has been discussed so often precisely because I swear NO CHOICE of

keyword would satisfy everybody! Most languages start with designated keywords and some reserve a few for later use. But then things can get
frozen in place to avoid breaking existing programs or break older compilers/interpreters.

Some languages use techniques to extend themselves more harmlessly such

as creating a singleton object that has content that can be regular data as in math.pi, or functions/methods or new ides like "Symbols" that allow all kinds of extensions to the language in a fairly harmless way as no older program would likely have used features that did not exist.

That might not easily solve this problem. But I wonder if reserving some

kind of prefix might help, so anything like extension.0nNoBreak could be added to a loop as a final clause and be treated as a non-key keyword of sorts.

My idea would be to reserve different unicode blocks for the keywords
and the identifiers. e.g. We could reserve the mathematical alphanumeric block for keywords and all other letters and numbers for identifiers.
Doing so would allow extenting the keywords without breaking programs
that already use that combination as an identifier.

Python could slowly transition in this direction by first allowing the current keywords to be in this block. Every new keyword would only be in
that unicode block. If would then be possible to write python code with
this convention but it wouldn't be obligatory. After some time the
python developers could decide to make it obligatory.

I doubt this will idea will get from the ground, but I think it would
allow for a smoother transition into new concepts, as it is no longer a strugle searching for a keyword that will break as little programs as possible.

--
Antoon Pardon.
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 16/10/2022 om 17:05 schreef Chris Angelico:

On Sun, 16 Oct 2022 at 22:47, Antoon Pardon<antoon.pardon@vub.be> wrote:

Why would I need good luck? I expressed an idea and you didn't like it.
That won't affect my life in a meaningful way.

Well, with that attitude, it's not going to affect anyone else's life
either, so go ahead, carry on.

What attitude? I just floated a little idea. It was not meant/expected to affect anyone else's life. So why do you react as if it was?

--
Antoon Pardon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote:

Op 16/10/2022 om 00:50 schreef avi.e.gross@gmail.com:

That might not easily solve this problem. But I wonder if reserving
some kind of prefix might help, so anything like extension.0nNoBreak
could be added to a loop as a final clause and be treated as a
non-key keyword of sorts.

My idea would be to reserve different unicode blocks for the keywords and
the identifiers. e.g. We could reserve the mathematical alphanumeric block for keywords and all other letters and numbers for identifiers. Doing so would allow extenting the keywords without breaking programs that already
use that combination as an identifier.

Or you could go back to the old Algol idea of underlining keywords.

Both have the same problem, though: They make editing with an ordinary
text editor pretty much impossible. You need a language-aware IDE which
makes entering these characters or markups simple. Maybe even a
specialized keyboard like they had for APL (or the Sinclair ZX computers
which had special combinations for all the BASIC keywords). And if you
go this way, why not go a step further and dissociate the program from
its linear text representation? Add footnotes, different views,
hyperlinks, format mathematical expressions like formulas, etc.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNMOMsACgkQ8g5IURL+ KF0+8Q//S1qgVyHuCK6jUmXsDMlDMcrtF9+Nx+kQRP8kmm7qllO9FPZat7sl+5G+ +4+Fp2v1cmUkr9OFOmxbkbfnfha48nf6Ygn5eK5ItKSsmxdHTPQJkmoy1ufFx1T6 C1PiOP5gyihnwzoPmsHiU++LtrIDr83xDM2WtlhA0U0EKu9iPbKXw+XPBvquPG/W nnwoDEYlshge9VNtYCOtlytWIV1oKlHSP9V5fCvBWqRxbeMA8AHbghCeG9VEapfr lUZnJtKvhob0KIZPA6KA6KO42OyIS31cPMXw5ciO6qk6dGsqhPg4uS6IKaeFnagQ wsTzQ05mpVnuLNSEWMpF+Hjn0zez2bDTOL74tCnuOlX5fGc65FGEPhTKUkM9ZtPJ rygJycTbJJUeUxPwkJX7K8L62MtguQ/QQpr9maFAegumC4XMoJvyhibmgNjiJTJ6 cIaP/DYroXSIOpSfPFJgf5errYIc7vmAxQvmF1QwgSw0jWelSEZecdRWm97h4U7r MP1K3SfCqYQZuXA+Szc2f2lyF8SQ+mffajsXOYYAcjeY59gUMIV4K28xL8/P8wjm 2o3hfTpUJE+QtK1O31aX+wQlVTPZaZQ7fxysnDDneLcL2XxNsrhBcVaweDdwj2j/ HM17KkhLAM900VWQnhPFNknlr+5PfmfE2cpiZfJ

On Mon, 17 Oct 2022 at 03:57, Antoon Pardon <antoon.pardon@vub.be> wrote:

Op 16/10/2022 om 17:05 schreef Chris Angelico:

On Sun, 16 Oct 2022 at 22:47, Antoon Pardon<antoon.pardon@vub.be> wrote:

Why would I need good luck? I expressed an idea and you didn't like it.
That won't affect my life in a meaningful way.

Well, with that attitude, it's not going to affect anyone else's life either, so go ahead, carry on.

What attitude? I just floated a little idea. It was not meant/expected to affect anyone else's life. So why do you react as if it was?

You expressed an idea that you would like to see implemented in
Python, and part of that idea was that people would be *obliged* to
write their code using non-ASCII keywords. If that were to be
implemented, it absolutely WOULD affect many people's lives. So if
you're saying that your idea was not meant to affect anyone else's
life, you are saying that you floated the idea fully intending for it
to be ignored, which makes me wonder why you posted it in the first
place.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-15 23:50, avi.e.gross@gmail.com wrote:

This has been discussed so often precisely because I swear NO CHOICE of keyword would satisfy everybody! Most languages start with designated keywords and some reserve a few for later use. But then things can get frozen in place to avoid breaking

existing programs or break older compilers/interpreters.

Some languages use techniques to extend themselves more harmlessly such as creating a singleton object that has content that can be regular data as in math.pi, or functions/methods or new ides like "Symbols" that allow all kinds of extensions to the

language in a fairly harmless way as no older program would likely have used features that did not exist.

That might not easily solve this problem. But I wonder if reserving some kind of prefix might help, so anything like extension.0nNoBreak could be added to a loop as a final clause and be treated as a non-key keyword of sorts.

If you'd accept 2 words:

for child in tree.getroot():
if child.tag == 'server':
break
not break:
raise ValueError(f"server tag not found in {lfile}")

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, October 12, 2022 6:20 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?

I too have occasionally used for ... else. It does have its uses. But oh, how I wish it had been called something else more meaningful, whether 'nobreak' or whatever. It used to really confuse me. Now I've learned to mentally replace "else" by "if

nobreak", it confuses me a bit less.

Rob Cliffe

On 12/10/2022 22:11, Weatherby,Gerard wrote:

As did I.

tree = ET.parse(lfile)
for child in tree.getroot():
if child.tag == 'server':
break
else:
raise ValueError(f"server tag not found in {lfile}")

I think there are other places I could be using it, but honestly I tend to forget it’s available.

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org>
on behalf of Stefan Ram <ram@zedat.fu-berlin.de>
Date: Wednesday, October 12, 2022 at 2:22 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: for -- else: what was the motivation?
*** Attention: This is an external email. Use caution responding,
opening attachments or clicking on links. ***

Axy <axy@declassed.art> writes:

So, seriously, why they needed else if the following pieces produce
same result? Does anyone know or remember their motivation?

Just wrote code wherein I used "else"! This:

import locale
for name in( 'de', 'de_DE', 'deu_deu', 'deu', 'German', 'Deutsch' ):
try: locale.setlocale( locale.LC_ALL, name ); break
except locale.Error: pass
else: print( "Programm kann deutsche Schreibweise nicht einrichten." )

.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 16/10/2022 om 19:03 schreef Chris Angelico:

On Mon, 17 Oct 2022 at 03:57, Antoon Pardon<antoon.pardon@vub.be> wrote:

Op 16/10/2022 om 17:05 schreef Chris Angelico:

On Sun, 16 Oct 2022 at 22:47, Antoon Pardon<antoon.pardon@vub.be> wrote: >>>> Why would I need good luck? I expressed an idea and you didn't like it. >>>> That won't affect my life in a meaningful way.
Well, with that attitude, it's not going to affect anyone else's life
either, so go ahead, carry on.

What attitude? I just floated a little idea. It was not meant/expected to
affect anyone else's life. So why do you react as if it was?

You expressed an idea that you would like to see implemented in
Python, and part of that idea was that people would be *obliged* to
write their code using non-ASCII keywords. If that were to be
implemented, it absolutely WOULD affect many people's lives.

So what? I made it clear that was an if I didn't expect to happen.
An idea that doesn't happen will not affect anyone, whatever the
consequences tied to the idea.

So if
you're saying that your idea was not meant to affect anyone else's
life, you are saying that you floated the idea fully intending for it
to be ignored, which makes me wonder why you posted it in the first
place.

People can find it interesting to discuss an idea, even if they think
there is no chance the idea will be carried out.

--
Antoon Pardon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 16/10/2022 om 17:03 schreef Avi Gross:

Interesting idea, Anton.

I would be interested in hearing more detail on how it would work.

Although much of programming has been centered on the Latin alphabet
and especially English, that may change. I can imagine a customized
compiler or interpreter that uses key words in the local language
instead of for or while or if or else or even import.

If a region of UNICODE was set aside, would it have to be as a sort of additional ALT or shift key for anything, or just English characters
or would it be for abstract symbols that would be mapped to and from a
long list of reserved key words that may vary by locale?

I think you are carrying my idea further than I intended. I was just
thinking that instead of using U+0064 U+0065 U+0066 [beinf def] we could
be using U+1D41D U+1D41E U+1D41F [being  𝐝𝐞𝐟].

--
Antoon Pardon.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 16/10/2022 om 19:01 schreef Peter J. Holzer:

On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote:

Op 16/10/2022 om 00:50 schreefavi.e.gross@gmail.com:

That might not easily solve this problem. But I wonder if reserving
some kind of prefix might help, so anything like extension.0nNoBreak
could be added to a loop as a final clause and be treated as a
non-key keyword of sorts.

My idea would be to reserve different unicode blocks for the keywords and
the identifiers. e.g. We could reserve the mathematical alphanumeric block >> for keywords and all other letters and numbers for identifiers. Doing so
would allow extenting the keywords without breaking programs that already
use that combination as an identifier.

Or you could go back to the old Algol idea of underlining keywords.

Both have the same problem, though: They make editing with an ordinary
text editor pretty much impossible. You need a language-aware IDE which
makes entering these characters or markups simple.

That is not true with my idea. The editor would just need to be able
to work with unicode characters. Vim can work with 𝐝𝐞𝐟 just as it can with def.

In vim I can also define abbreviations so that whenever I type ^Bd vim
wil insert 𝐝𝐞𝐟 for me.

It may be useful to have an alternative keyboard definition ready to
easily insert these characters into the editor but ordinary editors
should already be able to treat these characters as any other unicode character.

--
Antoon Pardon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/10/2022 18:43, Antoon Pardon wrote:

Op 16/10/2022 om 17:03 schreef Avi Gross:

Interesting idea, Anton.

I would be interested in hearing more detail on how it would work.

Although much of programming has been centered on the Latin alphabet
and especially English, that may change. I can imagine a customized
compiler or interpreter that uses key words in the local language
instead of for or while or if or else or even import.

Please, please please... forget about that idea.

I know examples. They had no future, and have no future. Either RMS or
ESR once have written in one of their book: "Please write in C". Same
here: please speak in English.

Although, if you like that idea who can stop you? In such a case I vote
for ภาษาไทย

Axy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-16 19:52:47 +0200, Antoon Pardon wrote:

Op 16/10/2022 om 19:01 schreef Peter J. Holzer:

On 2022-10-16 12:17:39 +0200, Antoon Pardon wrote:

Op 16/10/2022 om 00:50 schreefavi.e.gross@gmail.com:

That might not easily solve this problem. But I wonder if reserving some kind of prefix might help, so anything like extension.0nNoBreak could be added to a loop as a final clause and be treated as a
non-key keyword of sorts.

My idea would be to reserve different unicode blocks for the keywords and the identifiers. e.g. We could reserve the mathematical alphanumeric block
for keywords and all other letters and numbers for identifiers. Doing so would allow extenting the keywords without breaking programs that already use that combination as an identifier.

Or you could go back to the old Algol idea of underlining keywords.

Both have the same problem, though: They make editing with an ordinary
text editor pretty much impossible. You need a language-aware IDE which makes entering these characters or markups simple.

That is not true with my idea. The editor would just need to be able
to work with unicode characters. Vim can work with 𝐝𝐞𝐟 just as it can
with def.

Yes, vim can. But can the user? And the user's system?

And vim isn't the only editor out there. So you need a system for every
editor some Python programmer might want to use. While most will
probably use a sufficiently powerful editor, some won't.

In vim I can also define abbreviations so that whenever I type ^Bd vim
wil insert 𝐝𝐞𝐟 for me.

Which requires the user to define and type abbreviations. Which may be
hard if they can't enter the characters in the first place (Ok, that may
not be a problem as most users will probably just install a package from
the internet,)

The same does work with underlines:

d̲e̲f̲

although weirdly my terminal underlines the wrong characters (the one to
the right instead of the one to the left).

The pragmatic action would of course to define "def" as an abbreviation
for "𝐝𝐞𝐟" (or "d̲e̲f̲"), but then what have you won?

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNMaQUACgkQ8g5IURL+ KF3MEg//eK4fsVNFEc4ddwPdbxwM9hc2jIGnjBVp2896OsuAOrmjugnwuo9KRjhI 1+AAf1FssU8sDIc3qp4OuoE7i133nOhDguFNIwFKMMtPRZtFSeBWVHlPcn37vmDi DbNPbQ5nQFmJ3498vSkOmS7bFYi+gkL19snRy3t78d0J+62WqzSkx0t1Id+RMiIo vRCUKeuKzVsWqcLni8xGNwQRZ8oyxhgmpoZQEG2RnfVSRhamfPHAU6mu3CZwy6wg v7DD364jTfpQVfPfbv3jWOjJZeGMCx/nInWDympzOKFWghNVrGjhwWAwG6XFrkQc zFSRG/XolqX6Yuqb6xsshZr0vS0ghnfNqM335YaUL/tZPL2Bd2d489Es0FEB2OU/ VZeHH+xLfP3Rl+CvSUsCA25KnWSh91Vy13aqAM7z+3iQ5L8XIAArOvA1HngdFKfn SAGIBk8iPgHRv2SpzeNSO7Cg5m29+Q03zJ6yn5A1uWClimmKIirfhfxjsdIgIFlj PraO1Iw9qegVDbWGSBI7JASMD+CtmrmHJLGnXF1A0rZw7FgmnHfyWbhuCYp6BPK9 0tq3W5yh+fDOd/4ec/rAK1LB+Ep0INC6/lYK1BJkfvt4s4WZe1jzOd9Jq61f9/f+ hQ3EFX0tBsY6FYw/RXHtSeLKpR9Qu1UnEXlOFnv

Realistically an idea about something new is easier to consider than
changing what you have.

Some newer languages may well be designed from the start in new ways and
Julia is an example of a language that allows a wide swath of UNICODE characters to be used in identifiers. They also let you type them in even
using ASCII keyboards for some level of compatibility.

The original topic asked about the topic of re-using ELSE as a known keyword
in a context I and some others feel is a stretch. But the alterative could
be to add an ever increasing number of keywords to meet new needs.

I had another crazy thought that I AM NOT ASKING anyone to do. OK?

I was wondering about a sort of catch method you could use that generates a pseudo-signal only when the enclosed preceding loop exits normally as a
sort of way to handle the ELSE need without the use of a keyword known by
the language. All you would need is an object of the right kind that is
thrown and optionally caught.

Of course, even if I fleshed this out and even if anyone thought it made
sense, there is no such need now as Python has made a choice that meets the need even if few may dare use it or even know about it! LOL!




-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Antoon Pardon
Sent: Sunday, October 16, 2022 1:38 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?



Op 16/10/2022 om 19:03 schreef Chris Angelico:

On Mon, 17 Oct 2022 at 03:57, Antoon Pardon<antoon.pardon@vub.be> wrote:

Op 16/10/2022 om 17:05 schreef Chris Angelico:

On Sun, 16 Oct 2022 at 22:47, Antoon Pardon<antoon.pardon@vub.be>

wrote:

Why would I need good luck? I expressed an idea and you didn't like it. >>>> That won't affect my life in a meaningful way.

Well, with that attitude, it's not going to affect anyone else's
life either, so go ahead, carry on.

What attitude? I just floated a little idea. It was not
meant/expected to affect anyone else's life. So why do you react as if it was?

You expressed an idea that you would like to see implemented in
Python, and part of that idea was that people would be *obliged* to
write their code using non-ASCII keywords. If that were to be
implemented, it absolutely WOULD affect many people's lives.

So what? I made it clear that was an if I didn't expect to happen.
An idea that doesn't happen will not affect anyone, whatever the
consequences tied to the idea.

So if
you're saying that your idea was not meant to affect anyone else's
life, you are saying that you floated the idea fully intending for it
to be ignored, which makes me wonder why you posted it in the first
place.

People can find it interesting to discuss an idea, even if they think there
is no chance the idea will be carried out.

--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 17 Oct 2022 at 08:22, <avi.e.gross@gmail.com> wrote:

I had another crazy thought that I AM NOT ASKING anyone to do. OK?

Here's another proposal: Let's ban you from this mailing list. Don't
worry, I AM NOT ASKING anyone to do it. OK?

Do you see how ridiculous and pointless it is to have proposals with
that kind of caveat?

Make serious proposals that we can discuss reasonably, don't make fake proposals and hide behind a caveat.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

My point Chris was that you can have a conversation where you are exploring
and not proposing. Brainstorming, perhaps.

I was saying that there are many ways to signal things and in some
hypothetical new language, it may be implemented in novel ways that do not break anything.

I note languages like JavaScript seem to love passing functions or setting event handlers that may only be activated under unusual conditions.

So my POINT (and I repeat NOT a suggestion) is that I can IMAGINE ways to
add a feature to a loop, such as an extra optional argument that is called
if the loop exits from the bottom. The code you now put in the ELSE clause might have to be in the lambda or whatever. That may not be a good fit for Python.

What may aggravate you is that lots of people keep telling you that the ELSE
on a loop feature is not intuitive to many, sometimes even after it is explained.

My suggestion is you should deal with that and not take it out on others.
Live and let live.

My view remains that something has been added and is available and won't
likely be changed so use it as-is or ignore it.

But if anyone wants to make their own language, they can feel free to design around this any way they wish. If they design an object that encapsulates a loop and then add attributes to the object that are guaranteed to tell you
how the loop ended and run some code if it is set there, fine.

This forum may be about Python but not exclusively. I personally often enjoy hearing how some other system does something similar, such as discussions on how and whether Python should allow an underscore in static numbers given
other languages do so, not always identically. We can learn from such comparisons, for good and also for bad.

I am NOT proposing we change anything about ELSE and that was not my point.
My point was that sometimes rather than reuse an existing keyword in the language or create new reserved keywords, there can be many possible ways to extend functionality.

I know of languages with multiple variations on loops that do not break existing code. If your syntax is for (...) { ...} then if you add the
ability to place some identifier ONLY in the context involved then for XXX (...) { ...} may mean some altered functionality while YYY in the same spot means something else and the original form continues to do what it always
did.

So are XXX and YYY keywords or something else?

Again, I do not understand why people here get so touchy.

But if it makes you happy, take me off this list! I have so many things I
need to do and free up time for.




-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On Behalf Of Chris Angelico
Sent: Sunday, October 16, 2022 6:56 PM
To: python-list@python.org
Subject: Re: for -- else: what was the motivation?

On Mon, 17 Oct 2022 at 08:22, <avi.e.gross@gmail.com> wrote:

I had another crazy thought that I AM NOT ASKING anyone to do. OK?

Here's another proposal: Let's ban you from this mailing list. Don't worry,
I AM NOT ASKING anyone to do it. OK?

Do you see how ridiculous and pointless it is to have proposals with that
kind of caveat?

Make serious proposals that we can discuss reasonably, don't make fake proposals and hide behind a caveat.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 17 Oct 2022 at 10:46, <avi.e.gross@gmail.com> wrote:

My point Chris was that you can have a conversation where you are exploring and not proposing. Brainstorming, perhaps.

And my point is that either a proposal is a serious one that can
expect serious discussion, or it isn't. Yes, I'm aware that it wasn't
you who backpedalled as soon as any criticism was posted, but your
caveat comes to the same thing - if you're trying to avoid serious
criticism, you have to not post an idea.

So my POINT (and I repeat NOT a suggestion) is that I can IMAGINE ways to
add a feature to a loop, such as an extra optional argument that is called
if the loop exits from the bottom. The code you now put in the ELSE clause might have to be in the lambda or whatever. That may not be a good fit for Python.

If you're inventing a completely new language, you can do whatever you
like, but it's not very practical to discuss small features when
there's no language to discuss them in. So are you discussing this as
a Python feature, or just saying "hey, in a vacuum, we could do this",
which is vacuously true?

What may aggravate you is that lots of people keep telling you that the ELSE on a loop feature is not intuitive to many, sometimes even after it is explained.

I know it's unintuitive. That doesn't stop it being useful.

My suggestion is you should deal with that and not take it out on others. Live and let live.

That's unrelated. Sorry to disappoint you.

This forum may be about Python but not exclusively. I personally often enjoy hearing how some other system does something similar, such as discussions on how and whether Python should allow an underscore in static numbers given other languages do so, not always identically. We can learn from such comparisons, for good and also for bad.

That's correct, but usually there's at least SOME context. And if none
is given, is it or is it not reasonable to assume that people are
talking about Python?

But if it makes you happy, take me off this list! I have so many things I need to do and free up time for.

I'm not in a position to do that, and my point was to show how
ridiculous empty proposals are :)

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 17/10/2022 om 04:01 schreef Chris Angelico:

On Mon, 17 Oct 2022 at 10:46,<avi.e.gross@gmail.com> wrote:

My point Chris was that you can have a conversation where you are exploring >> and not proposing. Brainstorming, perhaps.

And my point is that either a proposal is a serious one that can
expect serious discussion, or it isn't. Yes, I'm aware that it wasn't
you who backpedalled as soon as any criticism was posted, but your
caveat comes to the same thing - if you're trying to avoid serious
criticism, you have to not post an idea.

Your reaction was not serious criticisme but a belligerent reaction.
You made it clear you wanted a fight. I choose not to enter that
fight.

--
Antoon Pardon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 17 Oct 2022 at 16:36, Antoon Pardon <antoon.pardon@vub.be> wrote:

Op 17/10/2022 om 04:01 schreef Chris Angelico:

On Mon, 17 Oct 2022 at 10:46,<avi.e.gross@gmail.com> wrote:

My point Chris was that you can have a conversation where you are exploring
and not proposing. Brainstorming, perhaps.

And my point is that either a proposal is a serious one that can
expect serious discussion, or it isn't. Yes, I'm aware that it wasn't
you who backpedalled as soon as any criticism was posted, but your
caveat comes to the same thing - if you're trying to avoid serious criticism, you have to not post an idea.

Your reaction was not serious criticisme but a belligerent reaction.
You made it clear you wanted a fight. I choose not to enter that
fight.

Well, if reacting strongly to a proposal to break LITERALLY EVERY
PYTHON PROGRAM EVER counts as not a serious criticism but a
belligerent reaction, then there's not really a lot of point
discussing further.

Bye.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

<avi.e.gross@gmail.com> wrote:

I had another crazy thought that I AM NOT ASKING anyone to do. OK?

I was wondering about a sort of catch method you could use that generates a pseudo-signal only when the enclosed preceding loop exits normally as a
sort of way to handle the ELSE need without the use of a keyword known by
the language. All you would need is an object of the right kind that is thrown and optionally caught.

(untested)

try:
while condition:
if not do_something():
raise RuntimeError
except RuntimeError:
pass
else:
print('Loop exited normally')

Ironically, this again relies on the much-used "else" and adds the overhead of exception handling. Also from a natural language perspective I find the "try ... except ... else" clause just as questionable as "while ... else." Since we're discussing weird keywords: Maybe we can find another use for "finally." In fact, one could argue that "while ... finally" could make just as much sense as "while ... else" (but I won't).

Of course, even if I fleshed this out and even if anyone thought it made sense, there is no such need now as Python has made a choice that meets the need even if few may dare use it or even know about it! LOL!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:

which had special combinations for all the BASIC keywords). And if you
go this way, why not go a step further and dissociate the program from
its linear text representation? Add footnotes, different views,
hyperlinks, format mathematical expressions like formulas, etc.

http://literateprogramming.com/

Right. That's one of the inspirations for my comment.

But literate programming is of course still very much rooted in the
"linear text representation" paradigm. You have one definite source
which is a linear text.

In a world of IDEs, databases and hypertext that's probably not the best
we can do. As Raymond Hettinger would say, "there must be a better way".

It would be very different from mainstream programming languages,
however. And ideally you would want it to integrate with a lot of other infrastructure. So that alone might make it a non-starter, even if it
was really good (which realistically early iterations wouldn't be).

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNPS/kACgkQ8g5IURL+ KF3DXw/9HBsqvmoz2o5ppZVSsg4nMyBXPneznKQM0GILM00yeuClKO9olCavwlQA jdpFkHLWNSSab1+MIM+DCcTEOb39y9h0MuiTFJkq7jb/iWsoTBM8XoXI/MNGxMAB 9S34u0OBQQZU0nr/q7KXdYqn8AoGfed7M4jpT+iCH/4nODbXLGXWX/UyeI07qQUi vpBvSRdrc0lylTXU2BVkwF24UChzl/BOn74mLuzko1YBsQSgYmXv3L1Vi33J9PQz 6bZE7vgGquITWLc+2Es1M/GmlJkQMpnIgVODld50HvEuI4g9Sj8iKNr6KfZoVhXG In3zZcVE5Ojbw+RIGVjonTVjpBwVYz+6021gicPYlpeb3B+CadQd00nJ+iRRW6GG fsbkjUW9V8FhuqJoSgHd7YaDWBphNnyphFPyKXKe4AtTzLwwzqApv35GsjvEiag9 GNCxc/f5a0kMAoKQpMz+mUieaHWfBBoBDE/cbj61RIe5bBXgsHbhQ3Hd6Yvm1Ord GXYvd3b4beHJn1uk5vn5MLWQqNt392i8DY8nUra44PwYOSzDTfMiRsuRBiZ7owm0 p9Z5e47O9JPODdkH3POt5mL3Qba2B0z8Slv2tpqsdN2MR+UMfjzn52+vuXx/NHHI NVyM61dHtIhEkuNV9haHlSOL00RaG5vMOoTbxyJ

On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer <hjp-python@hjp.at> wrote:

On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:

which had special combinations for all the BASIC keywords). And if you
go this way, why not go a step further and dissociate the program from its linear text representation? Add footnotes, different views, hyperlinks, format mathematical expressions like formulas, etc.

http://literateprogramming.com/

Right. That's one of the inspirations for my comment.

But literate programming is of course still very much rooted in the
"linear text representation" paradigm. You have one definite source
which is a linear text.

In a world of IDEs, databases and hypertext that's probably not the best
we can do. As Raymond Hettinger would say, "there must be a better way".

It would be very different from mainstream programming languages,
however. And ideally you would want it to integrate with a lot of other infrastructure. So that alone might make it a non-starter, even if it
was really good (which realistically early iterations wouldn't be).

There are special-purpose languages like Scratch which are not simple
text in that form. My Twitch channel bot has a command executor whose
language, if you call it that, is basically JSON - and the way to edit
those commands is very Scratch-inspired. These are not general-purpose programming languages, but for what they do, they can be very useful.
It's a great way to put together incredibly high level primitives that
tie in well with the system they're in. (Imagine programming a model
train set, with primitives like "change the points here to go
straight" and "advance train #32 to the next red signal".)

I'm not sure how you'd make that useful for general-purpose
programming, but there's definitely a LOT of value in non-textual
languages for certain situations.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:

On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer <hjp-python@hjp.at> wrote:

On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:

http://literateprogramming.com/

Right. That's one of the inspirations for my comment.

But literate programming is of course still very much rooted in the
"linear text representation" paradigm. You have one definite source
which is a linear text.

In a world of IDEs, databases and hypertext that's probably not the best
we can do. As Raymond Hettinger would say, "there must be a better way".

It would be very different from mainstream programming languages,
however. And ideally you would want it to integrate with a lot of other infrastructure. So that alone might make it a non-starter, even if it
was really good (which realistically early iterations wouldn't be).

There are special-purpose languages like Scratch which are not simple
text in that form.

Yes, I know.

It has a different goal though: Scratch tries to establish a friendly
learning environment. Get rid of typing and syntax errors that beginners
find so frustrating.

What I'm interested in is an enviroment for developing medium-sized real applications. Somewhere in the several person-months to several
person-years of effort, hundreds of user-stories, maybe thousands of bug-reports and change-requests over its life-time.

The people using such a system/language would be professional
programmers. They probably don't need much help to get the syntax of a
for loop right. What they do need, though:

* Cross-reference between requirements and code. (Yes, you can write
comments, yes, you will hopefully have meaningful commit messages.
Still, I see a lot of room for improvements there)
* Cross-references between related parts of the code. (Yes, many IDEs
can jump to the definition of an instance or list all instances of a
definiton, But sometimes the relationship isn't that mechanic. And
yes, you can use comments fpr that, too)
* Views which highlight some parts of the code and omit others. (Folding
editors do that in a very limited fashion)
* For example, I might want to see only the code proper when I'm
focusing on an algorithm or I might want to see lots of context
(type definitions, requirements, test results, ...)
* Classes often have quite a lot of methods with no natural order.
Being able to view only a subset of them in some custom order may
help.
* Going back to the core idea of literate programming: Especially
views which show some requirement(s) together with the code that
implements them plus some explanation why that implementation was
chosen.

Presented like this, it's clear that the "language" (i.e. the file
format) is probably the smallest part of the problem. How the user can
view the program, how they can edit it, and how to keep the whole thing manageable is a much bigger question. And it would probably be a good
idea to start at the system level and not at the language level.

My Twitch channel bot has a command executor whose language, if you
call it that, is basically JSON - and the way to edit those commands
is very Scratch-inspired.

I designed a graphical filter language for database queries once. The idea
was that you could combine various operations (selects, projections,
grouping, transformations, ...) into pipelines via a web interface. We
did implement it (sadly it wasn't me who did it), and it turned out to
be a lot harder than I thought to make that actually usable.

And of course there have been lots of CASE tools over the years. That
seems to have been mostly a fad of 90s. Still, there were some good
ideas there (although not alway implemented well), and something bubbles
back up every now and then.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNT6nUACgkQ8g5IURL+ KF3/jA/+Pd7K+icd0rAhAFTK4QgqlU09X5twqHzvTh23pOnpsQAj2Dtty61HTWxE t2+zVW4XHQ5BdBvqoPgkWa0sUGBGSYlyqJS6wbDQ44KpvhrqqIGe+SCtD3ki4zFn ugsfLrh+Jzo01RgZGDBUDmDJ4EnGYaB4YTRhKO29e8bG4UxgRCKSExwTN4tUaaSV 9h0w8JBv0/PT8zwKvCJbdyGlsrCGbbcm7MO2aQEOV9FmdmVWwZS5TtBwXe+g0lKo DwfUml+budON+OZ6oGn+ywRsG4k+uLG24qkbiYgXbcqzL/2M4llbUbRnFXHxm3KR hWB0a01OwdkP2EyhSBX37PI2Wv+6UchdjCu6hCPsaSQJXxdWPwxcosnmIcnNmgdy 7NK5Nj49x9ZEGiN64kIA8Nmir/20GjCY11fIk2e9KCHxKE55bvjNqG1OwZpOlZ57 dg3vmBPW6VM5NKJ6Cj8kmllxs2bwRyENk0Iw6A6QDeBO64fr1ao2lOweEE5px85o tbHUXxb0U0Gt0s6P/+kfQqIYOnOX+n3RZZAEwNoG5gTo2GtIY/g6ZrC6eBdbIZ06 newuGwxeN7+/x+EPHi6N6b6Hryr20U1bALVI9c82/DRlHRLIDV5udL+xfv1hXP0G WGYkRrO7JOWaUBfP3o5G3mDYFslf43tB6zimPla

On 2022-10-22 15:04:58 +0200, Peter J. Holzer wrote:

On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:

On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer <hjp-python@hjp.at> wrote:

On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:

http://literateprogramming.com/

Right. That's one of the inspirations for my comment.

But literate programming is of course still very much rooted in the "linear text representation" paradigm. You have one definite source
which is a linear text.

In a world of IDEs, databases and hypertext that's probably not the best we can do. As Raymond Hettinger would say, "there must be a better way".

It would be very different from mainstream programming languages, however. And ideally you would want it to integrate with a lot of other infrastructure. So that alone might make it a non-starter, even if it
was really good (which realistically early iterations wouldn't be).

There are special-purpose languages like Scratch which are not simple
text in that form.

Yes, I know.

It has a different goal though: Scratch tries to establish a friendly learning environment. Get rid of typing and syntax errors that beginners
find so frustrating.

What I'm interested in is an enviroment for developing medium-sized real applications. Somewhere in the several person-months to several
person-years of effort, hundreds of user-stories, maybe thousands of bug-reports and change-requests over its life-time.

[...]

And of course there have been lots of CASE tools over the years.

A possibly totally different approach:

There are tools[1] for authors which are supposed to help them keep all
their characters, events, timelines, etc. in order. I have never used
one (I don't plan to write a novel anytime soon), but what I've heard of
them sounds like it would be useful for software-development, too.

hp

[1] E.g. Campfire (https://www.campfirewriting.com/)

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNT7LkACgkQ8g5IURL+ KF3s3A/+IMKl3oY+2bCcYaJrRZejquqUFkRiFPWwyw9LN3k9vNfgJ46f8OXiyZ18 JADCZfVYelcnloldcyqLDsUuZ9kC3rqGYA9AQe1Au9lWPjzrjP+dKRk1VZ/I/j9n 8lxV7GwOzZxIa4hQj6H0MqyBojEOS7N+N3ZjVm5MmwKx0pwEVVT0kW4yCjhrKgFc ouChoyjYfPBNaHM9nb8OcIMhMm5ho+KIifoDOX78obH6IoJ4LqVnVgiOCmNriBxg I2kGNvvet923TqFo65NvDx69TmLNkdMd0fUFZuUW8zpH2AebRbY2x1IGEzju+BJt 5thqpNTNDdsgMbNJH4FuQ4WgjLjprHfRpGhesawRSSLC7iX2xkX5M0NRbwcXDRdD KhLAH8DBWhBU7BFuVDXwuvhOuNZ5QgWdwk+YblVwTDAYNTIxAtQ/84IqhXKU8UxJ +39+hyNl2qUjb9X/nk70e3O5ZJEnv3F//02T5Fjr2cm1dgg7wO5o34ZJThYPXlhp HYzfKNcVBE7OyxFT61vkVYgTm53Jl48nQjrwjEn8xQ+B1rGhEgBgq+rqPhyLgbBs TJCO0zzz+yes7+wi288KuqB68eQethHzvmd43cwUCsVOSosmYg0APB06nY5DypiV uvJW8uyEEw18TtORh4nCqW2+mj+RHMssp01uYj5

the fuck?

On Sat, Oct 22, 2022 at 9:06 AM Peter J. Holzer <hjp-python@hjp.at> wrote:

On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:

On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer <hjp-python@hjp.at> wrote:

On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:

http://literateprogramming.com/

Right. That's one of the inspirations for my comment.

But literate programming is of course still very much rooted in the "linear text representation" paradigm. You have one definite source
which is a linear text.

In a world of IDEs, databases and hypertext that's probably not the

best

we can do. As Raymond Hettinger would say, "there must be a better

way".

It would be very different from mainstream programming languages, however. And ideally you would want it to integrate with a lot of other infrastructure. So that alone might make it a non-starter, even if it
was really good (which realistically early iterations wouldn't be).

There are special-purpose languages like Scratch which are not simple
text in that form.

Yes, I know.

It has a different goal though: Scratch tries to establish a friendly learning environment. Get rid of typing and syntax errors that beginners
find so frustrating.

What I'm interested in is an enviroment for developing medium-sized real applications. Somewhere in the several person-months to several
person-years of effort, hundreds of user-stories, maybe thousands of bug-reports and change-requests over its life-time.

The people using such a system/language would be professional
programmers. They probably don't need much help to get the syntax of a
for loop right. What they do need, though:

* Cross-reference between requirements and code. (Yes, you can write
comments, yes, you will hopefully have meaningful commit messages.
Still, I see a lot of room for improvements there)
* Cross-references between related parts of the code. (Yes, many IDEs
can jump to the definition of an instance or list all instances of a
definiton, But sometimes the relationship isn't that mechanic. And
yes, you can use comments fpr that, too)
* Views which highlight some parts of the code and omit others. (Folding
editors do that in a very limited fashion)
* For example, I might want to see only the code proper when I'm
focusing on an algorithm or I might want to see lots of context
(type definitions, requirements, test results, ...)
* Classes often have quite a lot of methods with no natural order.
Being able to view only a subset of them in some custom order may
help.
* Going back to the core idea of literate programming: Especially
views which show some requirement(s) together with the code that
implements them plus some explanation why that implementation was
chosen.

Presented like this, it's clear that the "language" (i.e. the file
format) is probably the smallest part of the problem. How the user can
view the program, how they can edit it, and how to keep the whole thing manageable is a much bigger question. And it would probably be a good
idea to start at the system level and not at the language level.

My Twitch channel bot has a command executor whose language, if you
call it that, is basically JSON - and the way to edit those commands
is very Scratch-inspired.

I designed a graphical filter language for database queries once. The idea was that you could combine various operations (selects, projections, grouping, transformations, ...) into pipelines via a web interface. We
did implement it (sadly it wasn't me who did it), and it turned out to
be a lot harder than I thought to make that actually usable.

And of course there have been lots of CASE tools over the years. That
seems to have been mostly a fad of 90s. Still, there were some good
ideas there (although not alway implemented well), and something bubbles
back up every now and then.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-22 15:04:58 +0200, Peter J. Holzer wrote:

On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:

On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer <hjp-python@hjp.at> wrote:

On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote:

http://literateprogramming.com/

Right. That's one of the inspirations for my comment.

But literate programming is of course still very much rooted in the "linear text representation" paradigm. You have one definite source
which is a linear text.

In a world of IDEs, databases and hypertext that's probably not the best we can do. As Raymond Hettinger would say, "there must be a better way".

It would be very different from mainstream programming languages, however. And ideally you would want it to integrate with a lot of other infrastructure. So that alone might make it a non-starter, even if it
was really good (which realistically early iterations wouldn't be).

There are special-purpose languages like Scratch which are not simple
text in that form.

Yes, I know.

It has a different goal though: Scratch tries to establish a friendly learning environment. Get rid of typing and syntax errors that beginners
find so frustrating.

What I'm interested in is an enviroment for developing medium-sized real applications.

Late addendum: Watch

["Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022)](https://www.youtube.com/watch?v=8Ab3ArE8W3s)

for an overview of some ideas about programming environments.

hp


--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAmNmTqAACgkQ8g5IURL+ KF04ag/9Hy2ibuRENJZeVErimSVnkw/qEWAEm+BPJLtZSM4DES0Ywdu0wNMgWw8+ 8qVs32lSFJpsSYVWAVyYg34H7b4hMmRhCtmLENZ4YW67mWV05DJwnWILzwt5Pvt7 FAwRAc/b82dwI2SQUDXQZqhYR24xV9Fcd1M0sCXlwl04XJ40K6iKuMg5N4yv9xhl qDshJ25saA7YQPJli2oR3sporLaAlTH+JkkzOkN3x/elylKH+u+ony+e2UUz4W/i 5O0Uo3wKrJ8PYA6Pyd7lXg6Koz4nFLsX4Tol+x2z/Iyt6qOSCo0osHpAiquX17IU XaxSLYoiiTy8KJCYKLIhD+6MQOXJ4/U57f+KBB7nVGY6P2ymheq5x5szjGF6zodN 6aqDT9PHnZ1dXeszDGy9pw4Leam8cW0gmh0m0IJ9oFodUjlalfaJiQooyDKSuEZD kQx4PQtXbQAMWHR+xMeH7tceiBb9jk/nhBv8KqOwykFhsdXhSC2shU7jV4s1TYdG 8oHOOn98I2ZDGjYnyfSx4I7EWmKwg+MQyfgyojqd0sBTMbPujg9AcLkhS5r5HJ90 9PtHkk+/U88ZMrOxHhx4TkywOCESw40qSQBz5392pDD6DX4fHqMJUNDGZDZgxUpb 6JNsuO/v8gTjpBo8nFv4U5lh84DPfJzvfSOSHw1