Re: lxml empty versus self closed tag

[Robin Becker]

On 02/03/2022 18:39, Dieter Maurer wrote:

Robin Becker wrote at 2022-3-2 15:32 +:

I'm using lxml.etree.XMLParser and would like to distinguish



from



I seem to have e.getchildren()==[] and e.text==None for both cases. Is there a 
way to get the first to have e.text==''


I do not think so (at least not without a DTD):


I have a DTD which has



so I guess the empty case is allowed as well as the self closed.

I am converting from an older parser which has text=='' for  and text==None for the self closed version. I 
don't think I really need to make the distinction. However, I wonder how lxml can present an empty string content 
deliberately or if that always has to be a semantic decision.



`

ag/>' is just a shorthand notation for '' and

the difference has no influence on the DOM.

Note that `lxml` is just a Python binding for `libxml2`.
All the parsing is done by this library.

yes I think I knew that
--
https://mail.python.org/mailman/listinfo/python-list

Re: lxml empty versus self closed tag

[Dieter Maurer]

Robin Becker wrote at 2022-3-3 09:21 +:
>On 02/03/2022 18:39, Dieter Maurer wrote:
>> Robin Becker wrote at 2022-3-2 15:32 +:
>>> I'm using lxml.etree.XMLParser and would like to distinguish
>>>
>>> 
>>>
>>> from
>>>
>>> 
>>>
>>> I seem to have e.getchildren()==[] and e.text==None for both cases. Is 
>>> there a way to get the first to have e.text==''
>>
>> I do not think so (at least not without a DTD):
>
>I have a DTD which has
>
>
>
>so I guess the empty case is allowed as well as the self closed.

Potentially, something changes when `content` contains `PCDATA` (as
one possibility) (but I doubt it).
-- 
https://mail.python.org/mailman/listinfo/python-list

Behavior of the for-else construct

[computermaster360]

I want to make a little survey here.

Do you find the for-else construct useful? Have you used it in
practice? Do you even know how it works, or that there is such a thing
in Python?

I have used it maybe once. My issue with this construct is that
calling the second block `else` doesn't make sense; a much more
sensible name would be `then`.

Now, imagine a parallel universe, where the for-else construct would
have a different behavior:

for elem in iterable:
process(elem)
else:
# executed only when the iterable was initially empty
print('Nothing to process')

Wouldn't this be more natural? I think so. Also, I face this case much
more often than having detect whether I broke out of a loop early
(which is what the current for-else construct is for).

Now someone may argue that it's easy to check whether the iterable is
empty beforehand. But is it really? What if it's an iterator?
Then one would have to resort to using a flag variable and set it in
each iteration of the loop. An ugly alternative would be trying to
retrieve
the first element of the iterable separately, in a try block before
the for-loop, to find out whether the iterable is empty. This would of
course
require making an iterator of the iterable first (since we can't be
sure it is already an iterator), and then -- if there are any elements
-- processing
the first element separately before the for-loop, which means
duplicating the loop body. You can see the whole thing gets really
ugly really quickly...

What are your thoughts? Do you agree? Or am I just not Dutch enough...?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: All permutations from 2 lists

[Larry Martell]

On Wed, Mar 2, 2022 at 9:42 PM Avi Gross via Python-list
 wrote:
>
> Larry,
>
> i waited patiently to see what others will write and perhaps see if you 
> explain better what you need. You seem to gleefully swat down anything 
> offered. So I am not tempted to engage.

But then you gave in to the temptation.

> And it is hard to guess as it is not clear what you will do with this.

In the interests of presenting a minimal example I clearly
oversimplified. This is my use case: I get a dict from an outside
source. The dict contains key/value pairs that I need to use to query
a mongodb database. When the values in the dict are all scalar I can
pass the dict directly into the query, e.g.:
self._db_conn[collection_name].find(query). But if any of the values
are lists that does not work. I need to query with something like the
cross product of all the lists. It's not a true product since if a
list is empty it means no filtering on that field, not no filtering on
all the fields.  Originally I did not know I could generate a single
query that did that. So I was trying to come up with a way to generate
a list of all the permutations and was going to issue a query for each
individually.  Clearly that would become very inefficient if the lists
were long or there were a lot of lists. I then found that I could
specify a list with the "$in" clause, hence my solution.

> def query_lfixer(query):
> for k, v in query.items():
> if type(v)==list:
> query[k] = {"$in": v}
> return query
>
> self._db_conn[collection_name].find(query_lfixer(query))
>
>
> So why did so many of us bother?

Indeed - so why did you bother?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: All permutations from 2 lists

[Grant Edwards]

On 2022-03-03, Chris Angelico  wrote:
> On Thu, 3 Mar 2022 at 13:05, gene heskett  wrote:
>> I take it back, kmail5 had decided it was a different thread. My bad, no
>> biscuit.
>>
>
> Awww, I was going to make a really bad joke about timezones :)

As opposed to all the really good jokes about timezones... ;)


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

Re: All permutations from 2 lists

[Rob Cliffe via Python-list]

On 03/03/2022 14:07, Larry Martell wrote:

On Wed, Mar 2, 2022 at 9:42 PM Avi Gross via Python-list
  wrote:

Larry,

i waited patiently to see what others will write and perhaps see if you explain 
better what you need. You seem to gleefully swat down anything offered. So I am 
not tempted to engage.

But then you gave in to the temptation.


And it is hard to guess as it is not clear what you will do with this.

In the interests of presenting a minimal example I clearly
oversimplified. This is my use case: I get a dict from an outside
source. The dict contains key/value pairs that I need to use to query
a mongodb database. When the values in the dict are all scalar I can
pass the dict directly into the query, e.g.:
self._db_conn[collection_name].find(query). But if any of the values
are lists that does not work. I need to query with something like the
cross product of all the lists. It's not a true product since if a
list is empty it means no filtering on that field, not no filtering on
all the fields.  Originally I did not know I could generate a single
query that did that. So I was trying to come up with a way to generate
a list of all the permutations and was going to issue a query for each
individually.  Clearly that would become very inefficient if the lists
were long or there were a lot of lists. I then found that I could
specify a list with the "$in" clause, hence my solution.


def query_lfixer(query):
 for k, v in query.items():
 if type(v)==list:
 query[k] = {"$in": v}
 return query

self._db_conn[collection_name].find(query_lfixer(query))


So why did so many of us bother?

Indeed - so why did you bother?
You started with a request for help that did not say what you actually 
wanted.
When people took the time and trouble to give you answers to the 
question **as posed**, you repeatedly rejected them while still being 
unclear about what you actually wanted.

Now you seem to be being rude to Avi.
There are plenty of people willing to help on this list, and plenty of 
goodwill to those that need help - but goodwill can be used up if it is 
abused.

Respectfully,
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Dan Stromberg]

On Thu, Mar 3, 2022 at 5:24 AM computermaster360 <
computermaster...@gmail.com> wrote:

> I want to make a little survey here.
>
> Do you find the for-else construct useful? Have you used it in
> practice? Do you even know how it works, or that there is such a thing
> in Python?
>
> I have used it maybe once. My issue with this construct is that
> calling the second block `else` doesn't make sense; a much more
> sensible name would be `then`.
>

I use it and like it.

You need break's to make it useful - then it cuts down on unnecessary
booleans.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 00:25, computermaster360
 wrote:
>
> I want to make a little survey here.
>
> Do you find the for-else construct useful? Have you used it in
> practice? Do you even know how it works, or that there is such a thing
> in Python?

Yes, yes, and yes-yes. It's extremely useful.

> I have used it maybe once. My issue with this construct is that
> calling the second block `else` doesn't make sense; a much more
> sensible name would be `then`.

Ehh, I think "finally" would be a better keyword, but that has very
close connections with exception handling.

> Now, imagine a parallel universe, where the for-else construct would
> have a different behavior:
>
> for elem in iterable:
> process(elem)
> else:
> # executed only when the iterable was initially empty
> print('Nothing to process')
>
> Wouldn't this be more natural? I think so. Also, I face this case much
> more often than having detect whether I broke out of a loop early
> (which is what the current for-else construct is for).

This also has value, but not as much.

> Now someone may argue that it's easy to check whether the iterable is
> empty beforehand. But is it really? What if it's an iterator?
> Then one would have to resort to using a flag variable and set it in
> each iteration of the loop. An ugly alternative would be trying to
> retrieve
> the first element of the iterable separately, in a try block before
> the for-loop, to find out whether the iterable is empty. This would of
> course
> require making an iterator of the iterable first (since we can't be
> sure it is already an iterator), and then -- if there are any elements
> -- processing
> the first element separately before the for-loop, which means
> duplicating the loop body. You can see the whole thing gets really
> ugly really quickly...
>
> What are your thoughts? Do you agree? Or am I just not Dutch enough...?

Both forms have value, and only one of them can be called for-else.
Maybe if the current one had been called for-finally, then what you're
proposing could have been for-else, and we could theoretically have
had for-else-finally (where it goes into the for block once for each
element, but if there aren't any, it goes into the else block instead,
and either way, if you never break, it goes into the finally before
moving on). That ship has sailed, though, and given that people would
be confused very greatly by for-finally, I'm not overly sorry with the
current state of affairs.

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

Re: Behavior of the for-else construct

[Barry Scott]

> On 3 Mar 2022, at 13:24, computermaster360  
> wrote:
> 
> I want to make a little survey here.
> 
> Do you find the for-else construct useful?

No. I always have to look up what condition the else fires on.

> Have you used it in
> practice?

No.

> Do you even know how it works, or that there is such a thing
> in Python?

Yes (when I read the docs) and yes.

> I have used it maybe once. My issue with this construct is that
> calling the second block `else` doesn't make sense; a much more
> sensible name would be `then`.

There was a thread on this list asking for alternative syntax for the
for: else: that was not taken up. Something like nobreak: instead of else: 

> 
> Now, imagine a parallel universe, where the for-else construct would
> have a different behavior:
> 
>for elem in iterable:
>process(elem)
>else:
># executed only when the iterable was initially empty
>print('Nothing to process')
> 
> Wouldn't this be more natural? I think so. Also, I face this case much
> more often than having detect whether I broke out of a loop early
> (which is what the current for-else construct is for).

> 
> Now someone may argue that it's easy to check whether the iterable is
> empty beforehand. But is it really? What if it's an iterator?
> Then one would have to resort to using a flag variable and set it in
> each iteration of the loop. An ugly alternative would be trying to
> retrieve
> the first element of the iterable separately, in a try block before
> the for-loop, to find out whether the iterable is empty. This would of
> course
> require making an iterator of the iterable first (since we can't be
> sure it is already an iterator), and then -- if there are any elements
> -- processing
> the first element separately before the for-loop, which means
> duplicating the loop body. You can see the whole thing gets really
> ugly really quickly...
> 
> What are your thoughts? Do you agree? Or am I just not Dutch enough...?

Barry

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

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

Re: Timezone jokes (was: All permutations from 2 lists)

[Tim Chase]

On 2022-03-03 06:27, Grant Edwards wrote:
> On 2022-03-03, Chris Angelico  wrote:
> > Awww, I was going to make a really bad joke about timezones :)  
> 
> As opposed to all the really good jokes about timezones... ;)

And here I thought you were just Trolling with timezones...

https://en.wikipedia.org/wiki/Troll_(research_station)#cite_ref-1

;-)

-tkc




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

Re: Behavior of the for-else construct

[Tim Chase]

On 2022-03-04 02:02, Chris Angelico wrote:
>> I want to make a little survey here.
>>
>> Do you find the for-else construct useful? Have you used it in
>> practice? Do you even know how it works, or that there is such a
>> thing in Python?  
> 
> Yes, yes, and yes-yes. It's extremely useful.

Just adding another data-point, my answer is the same as above.

I use it regularly and frequently wish for it (or a similar "didn't
trigger a break-condition in the loop" functionality) when using
other programming languages.

-tkc



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

Re: Behavior of the for-else construct

[Grant Edwards]

On 2022-03-03, computermaster360  wrote:

> Do you find the for-else construct useful?

Yes.

> Have you used it in practice?

Yes.

I don't use it often, but I do use it occasionally.

However, I always have to look it up the docs to confirm the logic. I
always feel like the else should be executed if the for loop does
_not_ terminate naturally, but it's the opposite.

> Now, imagine a parallel universe, where the for-else construct would
> have a different behavior:
>
> for elem in iterable:
> process(elem)
> else:
> # executed only when the iterable was initially empty
> print('Nothing to process')
>
> Wouldn't this be more natural?

That also make sense.

> I think so. Also, I face this case much more often than having
> detect whether I broke out of a loop early (which is what the
> current for-else construct is for).


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

Re: All permutations from 2 lists

[Avi Gross via Python-list]

Larry,

That explanation made more sense and provided context.

I fully agree with you that generating the cross product of multiple lists can 
be messy and large and best avoided.

As an example, someone on an R forum presented their version of a way to see 
what are potential solutions to the game WORDLE at any given time, given the 
current constraints. The details are not important except that their process 
makes multiple vectors of the characters that can be allowed for letters "one" 
through "five" and then generates a data.frame of all combinations. Early in 
the game you know little and the number of combinations can be as high as 
26*26*26*26*26 in the English version. Within a few moves, you may know more 
but even 15*18*... can be large. So you have data.frames with sometimes 
millions of rows that are then converted rowwise to five letter words to make a 
long vector than you query a huge dictionary for each word and produce a list 
of possible words. Now imagine the same game looking instead for 6 letter words 
and 7 letter words ...

I looked at it and decided it was the wrong approach and in, brief, made a much 
smaller dictionary containing only the five letter words, and made a regular 
expression that looked like"

"^[letters][^letters]S[more][^this]$"

The above has 5 matches that may be for a specific letter you know is there 
(the S in position 3) or a sequence of letters in square brackets saying any 
one of those match, or the same with a leading caret saying anything except 
those. You then simply use the R grep() function to search the list of valid 
5-letter words using that pattern and in one sweep get them all without 
creating humongous data structures.

What you describe has some similarities as you searched for an alternate way to 
do something and it is now clearer why you did not immediately vocalize exactly 
what you anticipated. But your solution was not a solution to what anyone 
trying to help was working on. It was a solution to a different problem and 
what people would have had to know about how you were using a dictionary to 
pass to a mysterious function was not stated, till now. I would have 
appreciated it if you had simply stated you decided to use a different way and 
if anyone is curious, here it is.

For the rest of us, I think what we got from the exchange may vary. Some saw it 
as a natural fit with using something like a nested comprehension, albeit empty 
lists might need to be dealt with. Others saw a module designed to do such 
things as an answer. I saw other modules in numpy/pandas as reasonable. Some 
thought iterators were a part of a solution. The reality is that making 
permutations and combinations is a fairly common occurance in computer science 
and it can be expected that many implement one solution or another. 

But looking at your code, I am amused that you seem to already have not 
individual lists but a dictionary of named lists. Code similar to what you show 
now could trivially have removed dictionary items that held only an empty list. 
And as I pointed out, some of the solutions we came up with that could 
generalize to any number of lists, happily would accept such a dictionary and 
generate all combinations. 

My frustration was not about you asking how to solve a very reasonable problem 
in Python. It was about the process and what was disclosed and then the 
expectation that we should have known about things not shared. Certainly 
sharing too much is a problem too. Your title alone was very concrete asking 
about 2 lists. It is clear that was not quite your real need.





-Original Message-
From: Larry Martell 
To: Avi Gross 
Cc: python-list@python.org 
Sent: Thu, Mar 3, 2022 9:07 am
Subject: Re: All permutations from 2 lists


On Wed, Mar 2, 2022 at 9:42 PM Avi Gross via Python-list
 wrote:
>
> Larry,
>
> i waited patiently to see what others will write and perhaps see if you 
> explain better what you need. You seem to gleefully swat down anything 
> offered. So I am not tempted to engage.

But then you gave in to the temptation.

> And it is hard to guess as it is not clear what you will do with this.

In the interests of presenting a minimal example I clearly
oversimplified. This is my use case: I get a dict from an outside
source. The dict contains key/value pairs that I need to use to query
a mongodb database. When the values in the dict are all scalar I can
pass the dict directly into the query, e.g.:
self._db_conn[collection_name].find(query). But if any of the values
are lists that does not work. I need to query with something like the
cross product of all the lists. It's not a true product since if a
list is empty it means no filtering on that field, not no filtering on
all the fields.  Originally I did not know I could generate a single
query that did that. So I was trying to come up with a way to generate
a list of all the permutations and was going to issue a query for each
individually.  Clearly that would b

Re: Behavior of the for-else construct

[Roel Schroeven]

Op 3/03/2022 om 14:24 schreef computermaster360:

I want to make a little survey here.

Do you find the for-else construct useful? Have you used it in
practice? Do you even know how it works, or that there is such a thing
in Python?
- No, or at least not when balanced against the drawbacks as I perceive 
them.
- I have a hard time remembering how it works, which is the major 
drawback for me. I simply can't seem to wrap my head around it.

- Yes

I have used it maybe once. My issue with this construct is that
calling the second block `else` doesn't make sense; a much more
sensible name would be `then`.
There have been multiple proposals for a better name, but they all have 
their own drawbacks. There doesn't seem to be a clear winner.


Maybe a bit of an explanation of my dislike for the for-else construct. 
I can't remember what exactly it does and doesn't do, maybe because of 
the IMHO unfortunate naming or maybe because it's just an unusal 
construct, I don't know. While coding I never feel the need for for-else.
I like coding in a way where "every line expresses a single thought", as 
much as possible. That means that I don't mine creating short functions 
for things that in my mind otherwise break the flow of my code. So I 
often have short functions with a for loop and early returns. I have 
never seen an example of for-else that wouldn't be at least as clear 
with a little helper function (granted I haven't looked all that hard).


I'm googling for an example, but all I find are tutorial-type things 
that don't necessarily compare to real code. But it's the best I can do, 
so let's dive in. What they all seem to have in common is that they mix 
business logic and user interface (maybe precisely because of their 
tutorial nature), which I strive to avoid. For example, on 
https://www.geeksforgeeks.org/using-else-conditional-statement-with-for-loop-in-python/ 
I found this example:


    # Python 3.x program to check if an array consists
    # of even number
    def contains_even_number(l):
  for ele in l:
    if ele % 2 == 0:
  print ("list contains an even number")
  break

  # This else executes only if break is NEVER
  # reached and loop terminated after all iterations.
  else:
    print ("list does not contain an even number")

    # Driver code
    print ("For List 1:")
    contains_even_number([1, 9, 8])
    print (" \nFor List 2:")
    contains_even_number([1, 3, 5])

I would always refactor this even just for that mixing of business logic 
and printing stuff. Perhaps like this:


    def contains_even_number(lst):
    for element in lst:
    if element % 2 == 0:
    return True
    return False

    def print_contains_even_number(lst):
    if contains_even_number(lst):
    print("list contains an even number")
    else:
    print("list does not contain an even number")

    print("For List 1:")
    print_contains_even_number([1, 9, 8])
    print()
    print("For List 2:")
    print_contains_even_number([1, 3, 5])

Even without consciously avoiding for-else, it automatically disappears.
(In real code I would actually use any(element % 2 == 0 for element in 
lst) for something simple like this)



Now, imagine a parallel universe, where the for-else construct would
have a different behavior:

 for elem in iterable:
 process(elem)
 else:
 # executed only when the iterable was initially empty
 print('Nothing to process')

Wouldn't this be more natural? I think so. Also, I face this case much
more often than having detect whether I broke out of a loop early
(which is what the current for-else construct is for).
That's a different construct, also possibly useful. I think this would 
be more useful to me than the existing for-else.


--
"Man had always assumed that he was more intelligent than dolphins because
he had achieved so much — the wheel, New York, wars and so on — whilst all
the dolphins had ever done was muck about in the water having a good time.
But conversely, the dolphins had always believed that they were far more
intelligent than man — for precisely the same reasons."
-- Douglas Adams

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

Re: Behavior of the for-else construct

[Rob Cliffe via Python-list]

It has occasional uses (I THINK I've used it myself) but spelling it 
`else` is very confusing.  So there have been proposals for an 
alternative spelling, e.g. `nobreak`.

There have also been suggestions for adding other suites after `for', e.g.
    if the loop WAS exited with `break`
    if the loop was executed zero times
but these have not been accepted.
Best wishes
Rob Cliffe

On 03/03/2022 13:24, computermaster360 wrote:

I want to make a little survey here.

Do you find the for-else construct useful? Have you used it in
practice? Do you even know how it works, or that there is such a thing
in Python?

I have used it maybe once. My issue with this construct is that
calling the second block `else` doesn't make sense; a much more
sensible name would be `then`.

Now, imagine a parallel universe, where the for-else construct would
have a different behavior:

 for elem in iterable:
 process(elem)
 else:
 # executed only when the iterable was initially empty
 print('Nothing to process')

Wouldn't this be more natural? I think so. Also, I face this case much
more often than having detect whether I broke out of a loop early
(which is what the current for-else construct is for).

Now someone may argue that it's easy to check whether the iterable is
empty beforehand. But is it really? What if it's an iterator?
Then one would have to resort to using a flag variable and set it in
each iteration of the loop. An ugly alternative would be trying to
retrieve
the first element of the iterable separately, in a try block before
the for-loop, to find out whether the iterable is empty. This would of
course
require making an iterator of the iterable first (since we can't be
sure it is already an iterator), and then -- if there are any elements
-- processing
the first element separately before the for-loop, which means
duplicating the loop body. You can see the whole thing gets really
ugly really quickly...

What are your thoughts? Do you agree? Or am I just not Dutch enough...?


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

Re: Behavior of the for-else construct

[Dieter Maurer]

computermaster360 wrote at 2022-3-3 14:24 +0100:
>Do you find the for-else construct useful?

Yes.

>Have you used it in practice?

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

RE: Behavior of the for-else construct

[Schachner, Joseph]

Useful:  On rare occasions (when a loop has a "break" in it)
Used: Yes
Know how it works:  Yes
Even is such a thing: Yes
Your suggestion:   Also useful.  Will require a different keyword.   I don't 
know what that would be. "finally" is available 😊  Write up a feature request.

--- Joseph S.


Teledyne Confidential; Commercially Sensitive Business Data

-Original Message-
From: computermaster360  
Sent: Thursday, March 3, 2022 8:24 AM
To: python-list@python.org
Subject: Behavior of the for-else construct

I want to make a little survey here.

Do you find the for-else construct useful? Have you used it in practice? Do you 
even know how it works, or that there is such a thing in Python?

I have used it maybe once. My issue with this construct is that calling the 
second block `else` doesn't make sense; a much more sensible name would be 
`then`.

Now, imagine a parallel universe, where the for-else construct would have a 
different behavior:

for elem in iterable:
process(elem)
else:
# executed only when the iterable was initially empty
print('Nothing to process')

Wouldn't this be more natural? I think so. Also, I face this case much more 
often than having detect whether I broke out of a loop early (which is what the 
current for-else construct is for).

Now someone may argue that it's easy to check whether the iterable is empty 
beforehand. But is it really? What if it's an iterator?
Then one would have to resort to using a flag variable and set it in each 
iteration of the loop. An ugly alternative would be trying to retrieve the 
first element of the iterable separately, in a try block before the for-loop, 
to find out whether the iterable is empty. This would of course require making 
an iterator of the iterable first (since we can't be sure it is already an 
iterator), and then -- if there are any elements
-- processing
the first element separately before the for-loop, which means duplicating the 
loop body. You can see the whole thing gets really ugly really quickly...

What are your thoughts? Do you agree? Or am I just not Dutch enough...?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Timezone jokes (was: All permutations from 2 lists)

[Chris Angelico]

On Fri, 4 Mar 2022 at 03:29, Tim Chase  wrote:
>
> On 2022-03-03 06:27, Grant Edwards wrote:
> > On 2022-03-03, Chris Angelico  wrote:
> > > Awww, I was going to make a really bad joke about timezones :)
> >
> > As opposed to all the really good jokes about timezones... ;)
>
> And here I thought you were just Trolling with timezones...
>
> https://en.wikipedia.org/wiki/Troll_(research_station)#cite_ref-1
>
> ;-)
>

Best-named research station. It's the only place in the world where,
as they move into winter, the clocks move forwards.

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

Re: Timezone jokes (was: All permutations from 2 lists)

[Avi Gross via Python-list]

Chris and others,

This is a bit off-topic, but for anyone who saw the recent remake of Around The 
World in 80 days (and of course earlier versions including the book) will see 
that it too is a sort of timezone joke!

The timezone taketh away and then giveth.


-Original Message-
From: Chris Angelico 
To: python-list@python.org
Sent: Thu, Mar 3, 2022 12:40 pm
Subject: Re: Timezone jokes (was: All permutations from 2 lists)


On Fri, 4 Mar 2022 at 03:29, Tim Chase  wrote:
>
> On 2022-03-03 06:27, Grant Edwards wrote:
> > On 2022-03-03, Chris Angelico  wrote:
> > > Awww, I was going to make a really bad joke about timezones :)
> >
> > As opposed to all the really good jokes about timezones... ;)
>
> And here I thought you were just Trolling with timezones...
>
> https://en.wikipedia.org/wiki/Troll_(research_station)#cite_ref-1
>
> ;-)
>

Best-named research station. It's the only place in the world where,
as they move into winter, the clocks move forwards.


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

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

Re: Getting Syslog working on OSX Monterey

[Barry Scott]

> On 3 Mar 2022, at 03:01, Philip Bloom  wrote:
> 
> I'm probably asking on the wrong list, and probably should bother wherever 
> apple's ASL experts live for changes in monterey.   Guess nobody else is 
> seeing this?
> 
> The same exact code is working just fine on OSX Big Sur, but on OSX Monterey 
> it doesn't work at all.  Users that haven't updated are having the program 
> produce logs as it has for years through logging.handlers.SysLogHandler.  Mac 
> OSX definitely has a listening socket at '/var/run/syslog' which shows up in 
> Console.app.
> 
> Apologies, Barry.  I'm not quite understanding your responses.  

This works:

syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_USER)
syslog.syslog(syslog.LOG_NOTICE, 'QQQ test log')

I see the "QQQ test log" when I run syslog command.

And I can reproduce that logging.handlers.SysLogHandler does not work.
I added debug to the SysLogHandler() code and see that it does indeed write 
into the /var/run/syslog socket.
I suspect that macOS /var/run/syslog does not implement the RFC that this code 
depends on, but that a wild guess.

I suggest that you write your own handler that uses syslog.syslog() and use 
that.

Barry

> 
> When we say OSX has no listener for Syslog, what is the Apple System Log and 
> the general output to Console.app then?  I thought that was the local syslog 
> on OSX and had, for years, been behaving as such when using 
> logging.handlers.SysLogHandler with a config in /etc/asl/ to define how it 
> should be routed and the rollover/cleanup frequency.  
> 
> Thanks for replying, just having trouble understanding.
> 
> 
> On Mon, Feb 28, 2022 at 2:07 PM Barry Scott  > wrote:
> 
> 
> > On 28 Feb 2022, at 21:41, Peter J. Holzer  > > wrote:
> > 
> > On 2022-02-27 22:16:54 +, Barry wrote:
> >> If you look at the code of the logging modules syslog handle you will see 
> >> that
> >> it does not use syslog. It’s assuming that it can network to a syslog 
> >> listener.
> >> Such a listener is not running on my systems as far as I know.
> >> 
> >> I have always assumed that if I want a logger syslog handler that I would 
> >> have
> >> to implement it myself. So far I have code that uses syslog directly and 
> >> have
> >> not written that code yet.
> > 
> > What do you mean by using syslog directly? The syslog(3) library
> > function also just sends messages to a "syslog listener" (more commonly
> > called a syslog daemon) - at least on any unix-like system I'm familiar
> > with (which doesn't include MacOS). It will, however, always use the
> > *local* syslog daemon - AFAIK there is no standard way to open a remote
> > connection (many syslog daemons can be configured to forward messages to
> > a remote server, however).
> 
> I'm re-reading the code to check on what I'm seeing. (Its been a long
> time since I last look deeply at this code).
> 
> You can write to /dev/log if you pass that to
> SysLogHandler(address='/dev/log'), but the default is to use a socket
> to talk to a network listener on localhost:514. There are no deamons
> listening on port 514 on my Fedora systems or mac OS.
> 
> That is not what you would expect as the default if you are using the C
> API.
> 
> What you do not see used in the SyslogHandler() is the import syslog
> and hence its nor using openlog() etc from syslog API.
> 
> Barry
> 
> 
> 
> >hp
> > 
> > -- 
> >   _  | Peter J. Holzer| Story must make more sense than reality.
> > |_|_) ||
> > | |   | h...@hjp.at  |-- Charles Stross, 
> > "Creative writing
> > __/   | http://www.hjp.at/  |   challenge!"
> > -- 
> > https://mail.python.org/mailman/listinfo/python-list 
> > 
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 
> 
> 
> -- 
> Philip Bloom
> Director, Services Engineering
> AppLovin Corporation
> M: (786)-338-1439   
>      
>   
>  
> 
> 
> 

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

Re: Getting Syslog working on OSX Monterey

[Philip Bloom via Python-list]

Grabbing latest python that does work.  Good we're about to get out of the
stone ages a bit here.

So findings:
Syslog - works in 3.10, broken against monterey in 3.6.
Logging.Handlers.Sysloghandler - is broken in both against Monterey.

Will bug it for the tracker.  Thanks for the feedback.




On Thu, Mar 3, 2022 at 10:32 AM Barry Scott  wrote:

>
>
> On 3 Mar 2022, at 03:01, Philip Bloom  wrote:
>
> I'm probably asking on the wrong list, and probably should bother wherever
> apple's ASL experts live for changes in monterey.   Guess nobody else is
> seeing this?
>
> The same exact code is working just fine on OSX Big Sur, but on OSX
> Monterey it doesn't work at all.  Users that haven't updated are having the
> program produce logs as it has for years through
> logging.handlers.SysLogHandler.  Mac OSX definitely has a listening socket
> at '/var/run/syslog' which shows up in Console.app.
>
> Apologies, Barry.  I'm not quite understanding your responses.
>
>
> This works:
>
> syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_USER)
> syslog.syslog(syslog.LOG_NOTICE, 'QQQ test log')
>
> I see the "QQQ test log" when I run syslog command.
>
> And I can reproduce that logging.handlers.SysLogHandler does not work.
> I added debug to the SysLogHandler() code and see that it does indeed
> write into the /var/run/syslog socket.
> I suspect that macOS /var/run/syslog does not implement the RFC that this
> code depends on, but that a wild guess.
>
> I suggest that you write your own handler that uses syslog.syslog() and
> use that.
>
> Barry
>
>
> When we say OSX has no listener for Syslog, what is the Apple System Log
> and the general output to Console.app then?  I thought that was the local
> syslog on OSX and had, for years, been behaving as such when using
> logging.handlers.SysLogHandler with a config in /etc/asl/ to define how it
> should be routed and the rollover/cleanup frequency.
>
> Thanks for replying, just having trouble understanding.
>
>
> On Mon, Feb 28, 2022 at 2:07 PM Barry Scott 
> wrote:
>
>>
>>
>> > On 28 Feb 2022, at 21:41, Peter J. Holzer  wrote:
>> >
>> > On 2022-02-27 22:16:54 +, Barry wrote:
>> >> If you look at the code of the logging modules syslog handle you will
>> see that
>> >> it does not use syslog. It’s assuming that it can network to a syslog
>> listener.
>> >> Such a listener is not running on my systems as far as I know.
>> >>
>> >> I have always assumed that if I want a logger syslog handler that I
>> would have
>> >> to implement it myself. So far I have code that uses syslog directly
>> and have
>> >> not written that code yet.
>> >
>> > What do you mean by using syslog directly? The syslog(3) library
>> > function also just sends messages to a "syslog listener" (more commonly
>> > called a syslog daemon) - at least on any unix-like system I'm familiar
>> > with (which doesn't include MacOS). It will, however, always use the
>> > *local* syslog daemon - AFAIK there is no standard way to open a remote
>> > connection (many syslog daemons can be configured to forward messages to
>> > a remote server, however).
>>
>> I'm re-reading the code to check on what I'm seeing. (Its been a long
>> time since I last look deeply at this code).
>>
>> You can write to /dev/log if you pass that to
>> SysLogHandler(address='/dev/log'), but the default is to use a socket
>> to talk to a network listener on localhost:514. There are no deamons
>> listening on port 514 on my Fedora systems or mac OS.
>>
>> That is not what you would expect as the default if you are using the C
>> API.
>>
>> What you do not see used in the SyslogHandler() is the import syslog
>> and hence its nor using openlog() etc from syslog API.
>>
>> Barry
>>
>>
>>
>> >hp
>> >
>> > --
>> >   _  | Peter J. Holzer| Story must make more sense than reality.
>> > |_|_) ||
>> > | |   | h...@hjp.at |-- Charles Stross, "Creative writing
>> > __/   | http://www.hjp.at/ |   challenge!"
>> > --
>> > https://mail.python.org/mailman/listinfo/python-list
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
> --
> Philip Bloom
> Director, Services Engineering
> *AppLovin Corporation*
> M: (786)-338-1439 <786-338-1439>
> [image: LinkedIn]  [image:
> Twitter]  [image: Facebook]
>  [image: Instagram]
> 
> [image: AppLovin] 
>
>
>
>
>
>

-- 
Philip Bloom
Director, Services Engineering
*AppLovin Corporation*
M: (786)-338-1439 <786-338-1439>
[image: LinkedIn]  [image:
Twitter]  [image: Facebook]
 [image: Instagram]

[image: AppLovin] 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[computermaster360]

On Thu, 3 Mar 2022 at 18:25, Schachner, Joseph
 wrote:
>  I don't know what that would be. "finally" is available 😊  Write up a 
> feature request.

Not sure if you mean `finally` seriously but I think that would about
as confusing as the current `else`, if not even more 😅

Meanwhile, I found another solution which is somewhat neater than
using a boolean flag:

item = sentinel = object()
for item in iterable:
do_stuff(item)

if item is sentinel:
print('No items in iterable!')
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Michael F. Stemper]

On 03/03/2022 07.24, computermaster360 wrote:

I want to make a little survey here.

Do you find the for-else construct useful? Have you used it in
practice? Do you even know how it works, or that there is such a thing
in Python?


I only found out about it within the last year or so. I've used it
probably half-a-dozen times. It seems quite elegant to me.


--
Michael F. Stemper
A preposition is something you should never end a sentence with.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Jon Ribbens via Python-list]

On 2022-03-03, computermaster360  wrote:
> Do you find the for-else construct useful? Have you used it in
> practice?

Yes, I use it frequently.

> I have used it maybe once. My issue with this construct is that
> calling the second block `else` doesn't make sense; a much more
> sensible name would be `then`.

You are not the only person with this opinion, although personally
I have the opposite opinion. I think of 'for...else' as being
a search for something that matches a condition, and the 'else'
block is if no item is found that matches. If you think of it like
that, the syntax makes perfect sense.

> Now, imagine a parallel universe, where the for-else construct would
> have a different behavior:
>
> for elem in iterable:
> process(elem)
> else:
> # executed only when the iterable was initially empty
> print('Nothing to process')
>
> Wouldn't this be more natural? I think so. Also, I face this case much
> more often than having detect whether I broke out of a loop early
> (which is what the current for-else construct is for).

I guess peoples' needs vary. I can't even remember the last time
I've needed something as you suggest above - certainly far less
often than I need 'for...else' as it is now.

> What are your thoughts? Do you agree?

I don't agree. But it doesn't really matter if anyone agrees or not,
since there is no chance whatsoever that a valid Python syntax is
suddenly going to change to mean something completely different, not
even in "Python 4000" or whatever far-future version we might imagine.

This exact topic was discussd in November 2017 by the way, under the
subject heading "Re: replacing `else` with `then` in `for` and `try`".
I'm not sure any particular conclusion was reached though except that
some people think 'else' is more intuitive and some people think
'then' would be more intuitive.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python

[Dan Ciprus (dciprus) via Python-list]

if OP formulates question the way he/she did, it's not worth to respond to it. 
There is plenty of similar questions in the archive.


On Tue, Feb 22, 2022 at 07:07:54AM -0700, Mats Wichmann wrote:

On 2/21/22 23:17, SASI KANTH REDDY GUJJULA wrote:

Pip files are not installing after the python 3.10.2 version installing in my 
devise. Please solve this for me.


Please ask a clearer question.

Can you tell us what "are not installing" means? Are you getting
permission errors?  Are you installing and then unable to import what
you have installed?  Something else?

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


--
Daniel Ciprus  .:|:.:|:.
CONSULTING ENGINEER.CUSTOMER DELIVERY   Cisco Systems Inc.

[ curl -L http://git.io/unix ]


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Akkana Peck]

computermaster360 writes:
> I want to make a little survey here.
> 
> Do you find the for-else construct useful? 

No.

> Have you used it in practice?

Once or twice, but ended up removing it, see below.

> Do you even know how it works, or that there is such a thing in Python?

I always have to look it up, because to my mind, "else" implies
it does something quite different from what it actually does.

Which means that even if I worked hard at memorizing what it does,
so I didn't have to look it up, I still wouldn't use it in code,
because I want my code to be easily readable (including by future-me).
for..else makes code difficult to understand by anyone who doesn't
use for..else frequently: they might be misled into misunderstanding
the control flow.

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

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

The drumbeat I keep hearing is that some people hear/see the same word as 
implying something else. ELSE is ambiguous in the context it is used.

And naturally, since nobody desperately wants to use non-reserved keywords, 
nobody seems ready to use a word like INSTEAD instead.

Ideally, a language should be extendable and some languages like R allow you to 
place all kinds of things inside percent signs to make new operators like %*% 
or %PIPE% ...

Just because some feature may be wanted is not a good reason to overly 
complicate a language. Can you imagine how hard it would be both to implement 
and read something like:

...
ELSE:
   ...
OK:
   ...
FINALLY:
   ...
ULTIMATELY:
   ...

What if multiple of things like the above example need to be triggered in some 
particular order?

I have to wonder if some new form of wrapper might have made as much sense as 
in you wrap your loop in something that sets up and traps various signals that 
are then produced under conditions specified such as the loop not being entered 
as the starting condition is sort of null, or an exit due to a break or simply 
because the code itself throws that signal to be caught ...

This reminds me a bit of how some programs add so much functionality because 
someone thought of it without wondering if anyone (including the ones who 
sponsored it) would ever want to use it or remember it is there or how. I 
recall how a version of emacs had a transpose-letter function so after typing 
"teh" you could hit control-t and a little mock LISP macro would go back and co 
a cut and go forward and do a paste and leave the cursor where it was. That was 
sometimes useful, but often just as easy to backspace and retype. But I recall 
gleefully adding a transpose for words, sentences, paragraphs and was going to 
add more but I was running out of keystrokes to bind them to and besides it can 
be fairly easy to select items and yank them and move to where you want them 
and replace them.

To make changes in a language is sometimes really expensive but also dangerous. 
A "free" language must be added to sparingly and with so many requests, perhaps 
only a few non bug-fixes can seriously be considered.



-Original Message-
From: Akkana Peck 
To: python-list@python.org
Sent: Thu, Mar 3, 2022 5:33 pm
Subject: Re: Behavior of the for-else construct

computermaster360 writes:
> I want to make a little survey here.
> 
> Do you find the for-else construct useful? 

No.

> Have you used it in practice?

Once or twice, but ended up removing it, see below.

> Do you even know how it works, or that there is such a thing in Python?

I always have to look it up, because to my mind, "else" implies
it does something quite different from what it actually does.

Which means that even if I worked hard at memorizing what it does,
so I didn't have to look it up, I still wouldn't use it in code,
because I want my code to be easily readable (including by future-me).
for..else makes code difficult to understand by anyone who doesn't
use for..else frequently: they might be misled into misunderstanding
the control flow.

        ...Akkana

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

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

Re: Behavior of the for-else construct

[Rob Cliffe via Python-list]

I find it so hard to remember what `for ... else` means that on the very 
few occasions I have used it, I ALWAYS put a comment alongside/below the 
`else` to remind myself (and anyone else unfortunate enough to read my 
code) what triggers it, e.g.


    for item in search_list:
        ...
        ... break
    else: # if no item in search_list matched the criteria

You get the idea.
If I really want to remember what this construct means, I remind myself 
that `else` here really means `no break`.  Would have been better if it 
had been spelt `nobreak` or similar in the first place.

Rob Cliffe

On 03/03/2022 23:07, Avi Gross via Python-list wrote:

The drumbeat I keep hearing is that some people hear/see the same word as 
implying something else. ELSE is ambiguous in the context it is used.

And naturally, since nobody desperately wants to use non-reserved keywords, 
nobody seems ready to use a word like INSTEAD instead.

Ideally, a language should be extendable and some languages like R allow you to 
place all kinds of things inside percent signs to make new operators like %*% 
or %PIPE% ...

Just because some feature may be wanted is not a good reason to overly 
complicate a language. Can you imagine how hard it would be both to implement 
and read something like:

...
ELSE:
...
OK:
...
FINALLY:
...
ULTIMATELY:
...

What if multiple of things like the above example need to be triggered in some 
particular order?

I have to wonder if some new form of wrapper might have made as much sense as 
in you wrap your loop in something that sets up and traps various signals that 
are then produced under conditions specified such as the loop not being entered 
as the starting condition is sort of null, or an exit due to a break or simply 
because the code itself throws that signal to be caught ...

This reminds me a bit of how some programs add so much functionality because someone 
thought of it without wondering if anyone (including the ones who sponsored it) would 
ever want to use it or remember it is there or how. I recall how a version of emacs had a 
transpose-letter function so after typing "teh" you could hit control-t and a 
little mock LISP macro would go back and co a cut and go forward and do a paste and leave 
the cursor where it was. That was sometimes useful, but often just as easy to backspace 
and retype. But I recall gleefully adding a transpose for words, sentences, paragraphs 
and was going to add more but I was running out of keystrokes to bind them to and besides 
it can be fairly easy to select items and yank them and move to where you want them and 
replace them.

To make changes in a language is sometimes really expensive but also dangerous. A 
"free" language must be added to sparingly and with so many requests, perhaps 
only a few non bug-fixes can seriously be considered.



-Original Message-
From: Akkana Peck 
To: python-list@python.org
Sent: Thu, Mar 3, 2022 5:33 pm
Subject: Re: Behavior of the for-else construct

computermaster360 writes:

I want to make a little survey here.

Do you find the for-else construct useful?

No.


Have you used it in practice?

Once or twice, but ended up removing it, see below.


Do you even know how it works, or that there is such a thing in Python?

I always have to look it up, because to my mind, "else" implies
it does something quite different from what it actually does.

Which means that even if I worked hard at memorizing what it does,
so I didn't have to look it up, I still wouldn't use it in code,
because I want my code to be easily readable (including by future-me).
for..else makes code difficult to understand by anyone who doesn't
use for..else frequently: they might be misled into misunderstanding
the control flow.

         ...Akkana



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

Re: Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list
 wrote:
>
> The drumbeat I keep hearing is that some people hear/see the same word as 
> implying something else. ELSE is ambiguous in the context it is used.
>

What I'm hearing is that there are, broadly speaking, two types of
programmers [1]:

1) Those who think about "for-else" as a search tool and perfectly
understand how it behaves
2) Those who have an incorrect idea about what for-else is supposed to
do, don't understand it, and don't like it.

You could easily make a similar point about a lot of other advanced
constructs. Some people don't understand threading, and either dislike
it or are scared of it. Some people never get their heads around
asyncio and the way that yield points work. Some people can't grok
operator precedence, so they parenthesize everything "just to be
safe". And some people dislike exceptions so much that they warp all
their functions into returning a (value,True) or (error,False) tuple
instead. Does this mean that all these features are bad? No.

There's no way to make every feature perfectly intuitive to every
programmer. Those features are still incredibly useful to the
programmers that DO use them.

Maybe, with hindsight, for-finally would have been a slightly better
spelling than for-else. Who knows. But people simply need to
understand it, just like people need to understand how binary
floating-point works, and claiming that it's "ambiguous' is simply
wrong. It has one meaning in the language, and then if programmers
have an incorrect expectation, they need to learn (or to not use the
feature, which isn't really a problem, it's just not taking advantage
of it).

> And naturally, since nobody desperately wants to use non-reserved keywords, 
> nobody seems ready to use a word like INSTEAD instead.
>
> Ideally, a language should be extendable and some languages like R allow you 
> to place all kinds of things inside percent signs to make new operators like 
> %*% or %PIPE% ...
>

I don't know what you mean by "extendable", but if you mean that
different people should be able to change the language syntax in
different ways, then absolutely not. When two different files can be
completely different languages based on a few directives, it's
extremely difficult to read.

(Import hooks, and tools like MacroPy, can be used for this sort of
effect. I do not think that we should be using them on a regular basis
to change core syntax.)

> Just because some feature may be wanted is not a good reason to overly 
> complicate a language. Can you imagine how hard it would be both to implement 
> and read something like:
>
> ...
> ELSE:
>...
> OK:
>...
> FINALLY:
>...
> ULTIMATELY:
>...
>
> What if multiple of things like the above example need to be triggered in 
> some particular order?

I don't know what they'd all mean, but if they were all in the core
language, they would have to be supported in arbitrary combinations.
It's possible to have a "try-except-else-finally" block in Python, for
instance. But if you mean that they should all do what "else" does
now, then this is a terrible idea. One way of spelling it is just
fine.

> This reminds me a bit of how some programs add so much functionality because 
> someone thought of it without wondering if anyone (including the ones who 
> sponsored it) would ever want to use it or remember it is there or how. I 
> recall how a version of emacs had a transpose-letter function so after typing 
> "teh" you could hit control-t and a little mock LISP macro would go back and 
> co a cut and go forward and do a paste and leave the cursor where it was. 
> That was sometimes useful, but often just as easy to backspace and retype. 
> But I recall gleefully adding a transpose for words, sentences, paragraphs 
> and was going to add more but I was running out of keystrokes to bind them to 
> and besides it can be fairly easy to select items and yank them and move to 
> where you want them and replace them.
>

SciTE has a "transpose lines" feature. I use it frequently. But editor
features are quite different from language features.

ChrisA

[1] Something tells me I've heard this before
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

Rob,

I regularly code with lots of comments like the one you describe, or mark the 
end of a region that started on an earlier screen such as a deeply nested 
construct.

I have had problems though when I have shared such code and the recipient 
strips my comments and then later wants me to make changes or even just explain 
it! My reply tends to be unprintable as in, well, never mind!

This leads to a question I constantly ask. If you were free to design a brand 
new language now, what would you do different that existing languages have had 
to deal with the hard way?

I recall when filenames and extensions had a limited number of characters 
allowed and embedded spaces were verboten. This regularity made lots of code 
possible but then some bright people insisted on allowing spaces and you can no 
longer easily do things like expand *.c into a long line of text and then 
unambiguously work on one file name at a time. You can often now create a name 
like "was file1.c and now is file2.c" and it seems acceptable. Yes, you can 
work around things and get a vector or list of strings and not a command line 
of text and all things considered, people can get as much or more work done. 

I have seen major struggles to get other character sets into languages. Any new 
language typically should have this built in from scratch and should consider 
adding non-ASCII characters into the mix. Mathematicians often use lots of 
weird braces/brackets as an example while normal programs are limited to [{( 
and maybe < and their counterparts. This leads to odd Python behavior (other 
languages too) where symbols are re-used ad nauseam. { can mean set or 
dictionary or simply some other way to group code.

So I would love to see some key that allows you to do something like L* to mean 
the combination is a left bracket and should be treated as the beginning of a 
sequence expected to end in R* or perhaps *R. That would allow many other 
symbols to be viewed as balanced entities. Think of how Python expanded using 
single and double quotes (which arguably might work better if balanced this 
way) to sometimes using triple quotes to putting letters like "b" or "f" in 
front to make it a special kind of string. 

But I suspect programming might just get harder for those who would not 
appreciate a language that used (many) hundreds of symbols. I do work in many 
alphabets and many of them pronounce and use letters that look familiar in very 
different ways and sound them differently and invent new ones. Every time I 
learn another human language, I have to both incorporate the new symbols and 
rules and also segregate them a bit from identical or similar things in the 
languages I already speak. It can be quite a chore. But still, I suspect many 
people are already familiar with symbols such as from set Theory such as subset 
and superset that could be used as another pair of parentheses of some type 
Having a way to enter them using keyboards is a challenge.

Back to the topic, I was thinking wickedly of a way to extend the FOR loop with 
existing keywords while sounding a tad ominous is not with  an ELSE but a FOR 
... OR ELSE ...


-Original Message-
From: Rob Cliffe via Python-list 
To: python-list@python.org
Sent: Thu, Mar 3, 2022 7:13 pm
Subject: Re: Behavior of the for-else construct


I find it so hard to remember what `for ... else` means that on the very 
few occasions I have used it, I ALWAYS put a comment alongside/below the 
`else` to remind myself (and anyone else unfortunate enough to read my 
code) what triggers it, e.g.

     for item in search_list:
         ...
         ... break
     else: # if no item in search_list matched the criteria

You get the idea.
If I really want to remember what this construct means, I remind myself 
that `else` here really means `no break`.  Would have been better if it 
had been spelt `nobreak` or similar in the first place.
Rob Cliffe


On 03/03/2022 23:07, Avi Gross via Python-list wrote:
> The drumbeat I keep hearing is that some people hear/see the same word as 
> implying something else. ELSE is ambiguous in the context it is used.
>
> And naturally, since nobody desperately wants to use non-reserved keywords, 
> nobody seems ready to use a word like INSTEAD instead.
>
> Ideally, a language should be extendable and some languages like R allow you 
> to place all kinds of things inside percent signs to make new operators like 
> %*% or %PIPE% ...
>
> Just because some feature may be wanted is not a good reason to overly 
> complicate a language. Can you imagine how hard it would be both to implement 
> and read something like:
>
> ...
> ELSE:
>     ...
> OK:
>     ...
> FINALLY:
>     ...
> ULTIMATELY:
>     ...
>
> What if multiple of things like the above example need to be triggered in 
> some particular order?
>
> I have to wonder if some new form of wrapper might have made as much sense as 
> in you wrap your loop in something that sets up and traps various sign

Re: Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 11:14, Rob Cliffe via Python-list
 wrote:
>
> I find it so hard to remember what `for ... else` means that on the very
> few occasions I have used it, I ALWAYS put a comment alongside/below the
> `else` to remind myself (and anyone else unfortunate enough to read my
> code) what triggers it, e.g.
>
>  for item in search_list:
>  ...
>  ... break
>  else: # if no item in search_list matched the criteria

A "break" statement always takes you to the line following the current
loop construct. The "else" block is part of the current loop
construct. It's no more a "no-break" block than the body of the for
loop is a "no-break" body here:

for item in stuff:
if condition: break
frobnicate(item) # if no previous item matched the condition

> You get the idea.
> If I really want to remember what this construct means, I remind myself
> that `else` here really means `no break`.  Would have been better if it
> had been spelt `nobreak` or similar in the first place.

Maybe, but I think that obscures the meaning of it; "finally" isn't
quite right either (in a try block, you'd hit a finally block whether
you raise an exception or not), but I think it's closer. Creating a
new language keyword is an incredibly high cost.

Think of it like this:

for item in search_list:
if condition: pass
else:
print("Condition not true for this item")

for item in search_list:
if condition: break
else:
print("Condition not true for any item")

There's a parallel here. Since a for-else loop is basically useless
without an if-break construct inside it, the else clause can be
thought of as the else on a massive if/elif chain:

if stuff[0].is_good:
print("This item is good", stuff[0])
elif stuff[1].is_good:
print("This item is good", stuff[1])
...
...
elif stuff[n].is_good:
print("This item is good", stuff[n])
else:
print("All items are bad")

As a loop, this looks like this:

for item in stuff:
if item.is_good:
print("This item is good", item)
break
else:
print("All items are bad")

The else is attached to the for so that it compasses ALL the if
statements, but it's still broadly saying "do this when we don't hit
the 'if' condition".

Whether that's a sufficient mnemonic, I don't know, but it doesn't
really matter; the construct is useful to those of us who want it, and
if other people ignore it, that's fine. Nobody ever said you had to
use or understand every single feature of the language you're using.

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

Re: Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 11:39, Avi Gross via Python-list
 wrote:
>
> Rob,
>
> I regularly code with lots of comments like the one you describe, or mark the 
> end of a region that started on an earlier screen such as a deeply nested 
> construct.
>
> I have had problems though when I have shared such code and the recipient 
> strips my comments and then later wants me to make changes or even just 
> explain it! My reply tends to be unprintable as in, well, never mind!
>

If they strip out the comments, you can be confident that the comments
were unhelpful :)

> This leads to a question I constantly ask. If you were free to design a brand 
> new language now, what would you do different that existing languages have 
> had to deal with the hard way?
>

Very good way to start thinking. In fact, I'd recommend going further,
and actually designing the entire language. (Don't bother actually
writing an implementation, but fully lay out the syntax and
semantics.) It's a great exercise, and you'll learn why things are the
way they are.

> I recall when filenames and extensions had a limited number of characters 
> allowed and embedded spaces were verboten. This regularity made lots of code 
> possible but then some bright people insisted on allowing spaces and you can 
> no longer easily do things like expand *.c into a long line of text and then 
> unambiguously work on one file name at a time. You can often now create a 
> name like "was file1.c and now is file2.c" and it seems acceptable. Yes, you 
> can work around things and get a vector or list of strings and not a command 
> line of text and all things considered, people can get as much or more work 
> done.
>

I don't remember when embedded spaces were verboten, so I'm guessing
you're talking about 1970s or earlier, on mainframes? In MS-DOS, it
was perfectly possible to have spaces in file names, and OS/2 also had
that flexibility (and used it for special files like "EA DATA. SF" on
a FAT disk). Windows forbade a bunch of characters in file names, but
other systems have always been fine with them.

It's not only file names that can be multiple words in a single
logical argument. The Windows "start" command has a bizarreness where
it takes a quoted string as a title, but a second quoted string as a
file name, so <> will open that directory, <> opens a shell with a title of "c:\some_dir", and
<> opens the directory, even if it has spaces
in it. It's much better to treat arguments as a vector of strings
rather than a single string, as the start command tries to.

> I have seen major struggles to get other character sets into languages. Any 
> new language typically should have this built in from scratch and should 
> consider adding non-ASCII characters into the mix. Mathematicians often use 
> lots of weird braces/brackets as an example while normal programs are limited 
> to [{( and maybe < and their counterparts. This leads to odd Python behavior 
> (other languages too) where symbols are re-used ad nauseam. { can mean set or 
> dictionary or simply some other way to group code.
>

Tell me, which is more important: the way the code looks, or the way
it is typed? Because your *editor* can control both of these.

> So I would love to see some key that allows you to do something like L* to 
> mean the combination is a left bracket and should be treated as the beginning 
> of a sequence expected to end in R* or perhaps *R. That would allow many 
> other symbols to be viewed as balanced entities. Think of how Python expanded 
> using single and double quotes (which arguably might work better if balanced 
> this way) to sometimes using triple quotes to putting letters like "b" or "f" 
> in front to make it a special kind of string.
>

Okay. Design that in an editor and see if it catches on.

I've seen a wide variety of bracket-matching tools (like color-coding
all types of bracket according to what they pair with), but none of
them really get popular. Baking it into the language means that
everyone who uses the language has to be able to work with this.

Flesh out this "L*" idea, and explain how it solves the problem. What
does it do to the asterisk?

> But I suspect programming might just get harder for those who would not 
> appreciate a language that used (many) hundreds of symbols. I do work in many 
> alphabets and many of them pronounce and use letters that look familiar in 
> very different ways and sound them differently and invent new ones. Every 
> time I learn another human language, I have to both incorporate the new 
> symbols and rules and also segregate them a bit from identical or similar 
> things in the languages I already speak. It can be quite a chore. But still, 
> I suspect many people are already familiar with symbols such as from set 
> Theory such as subset and superset that could be used as another pair of 
> parentheses of some type Having a way to enter them using keyboards is a 
> challenge.
>

Exactly.

> Back to the topic, I was thin

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

Chris,

Much of what I intended is similar to what you say. I am simply saying the 
existing group of programmers seems to include people who will not see every 
thing the same way. There is no way to make them all happy and you have other 
constraints like not suddenly adding new reserved words, so you do the best you 
can and hope people can get educated.

I have seen lots of otherwise bright people drop out of math classes not 
because they could not understand the concepts, but because they have trouble 
handling all the symbols being used, such as Greek letters. Often they get 
stuck simply because nobody tells them how to pronounce the letter as in 
epsilon or zeta or aleph. Or consider the many ways various people denote a 
derivative. For some f'(x) and f''(x) feel right but dy/dx and d^2y/dx^2 
(assume since this is plain next, I meant a small superscript 2 representing 
squared) makes no sense. Others like it the other way and still others like a 
dot on top of something like an s or two dots. I can mix and match many such 
representations because I know they are just representations of an underlying 
thing that I do understand. I have seen people then get stuck at partial 
derivatives which use a new symbol instead of the d, whose name they do not 
know like ∂ 

Teaching APL also drove some students crazy with all the overprinted symbols.

So, yes, using ELSE in what seems to them like multiple and incompatible ways 
can lead to frustration but is rather unavoidable.

Which leads to a point you misunderstood. I was saying R reserved a namespace 
of sorts so that adding new keywords could be done safely. Users are not 
expected to make variable names like %in% so you can write code like if (var 
%in% listing) and you can even change the definition in a sort of overloading 
to do something different. YES this can lead to others puzzling over your code. 
But if you need a new keyword, perhaps you could expand into such a reserved 
corner of the namespace and avoid having to reuse existing key words in 
possibly incompatible, or at least for some non-intuitive, ways. It does not 
need to use percent signs, just some notation users would normally not already 
be using. I am not here to say R is better, just some ideas are very different 
and thus many things chosen now are not inevitable. It gives me some 
flexibility in say calling a function as `[`(args) instead of [args] and 
rewriting it. Python plays lots of similar games, such as the decorators you 
like to use. In many places, Python makes it easier for me to do things.

There really are more like three kinds of Programmers. Some see the world one 
way and some another way and some are switch hitters. The fourth kind tend not 
to be programmers! The ones who are adaptable and simply acknowledge that a 
decision has been made and use the functionality as it is done, do best. No 
need to complain, just adapt. And, of course, you can just not use anything 
that does not appeal to you but do not be shocked if you encounter code by 
others who are using it and be ready to understand it enough for the purpose at 
hand.

If Python was being designed TODAY, I wonder if a larger set of key words would 
be marked as RESERVED for future expansion including ORELSE and even 
NEVERTHELESS.




-Original Message-
From: Chris Angelico 
To: python-list@python.org 
Sent: Thu, Mar 3, 2022 7:34 pm
Subject: Re: Behavior of the for-else construct


On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list
 wrote:
>
> The drumbeat I keep hearing is that some people hear/see the same word as 
> implying something else. ELSE is ambiguous in the context it is used.
>

What I'm hearing is that there are, broadly speaking, two types of
programmers [1]:

1) Those who think about "for-else" as a search tool and perfectly
understand how it behaves
2) Those who have an incorrect idea about what for-else is supposed to
do, don't understand it, and don't like it.

You could easily make a similar point about a lot of other advanced
constructs. Some people don't understand threading, and either dislike
it or are scared of it. Some people never get their heads around
asyncio and the way that yield points work. Some people can't grok
operator precedence, so they parenthesize everything "just to be
safe". And some people dislike exceptions so much that they warp all
their functions into returning a (value,True) or (error,False) tuple
instead. Does this mean that all these features are bad? No.

There's no way to make every feature perfectly intuitive to every
programmer. Those features are still incredibly useful to the
programmers that DO use them.

Maybe, with hindsight, for-finally would have been a slightly better
spelling than for-else. Who knows. But people simply need to
understand it, just like people need to understand how binary
floating-point works, and claiming that it's "ambiguous' is simply
wrong. It has one meaning in the language, and then if programmers
have a

Re: Behavior of the for-else construct

[Rob Cliffe via Python-list]

On 04/03/2022 00:34, Chris Angelico wrote:

On Fri, 4 Mar 2022 at 10:09, Avi Gross via Python-list
 wrote:

The drumbeat I keep hearing is that some people hear/see the same word as 
implying something else. ELSE is ambiguous in the context it is used.


What I'm hearing is that there are, broadly speaking, two types of
programmers [1]:

1) Those who think about "for-else" as a search tool and perfectly
understand how it behaves
2) Those who have an incorrect idea about what for-else is supposed to
do, don't understand it, and don't like it.
Or those who have a vague fuzzy idea about it and have trouble 
remembering what it does.


You could easily make a similar point about a lot of other advanced
constructs. Some people don't understand threading, and either dislike
it or are scared of it. Some people never get their heads around
asyncio and the way that yield points work. Some people can't grok
operator precedence, so they parenthesize everything "just to be
safe". And some people dislike exceptions so much that they warp all
their functions into returning a (value,True) or (error,False) tuple
instead. Does this mean that all these features are bad? No.
You could add examples ad nauseam.  I submit that for-else is a special 
case.  As evidenced by the number of people (including me) who say they 
have trouble grokking it.


There's no way to make every feature perfectly intuitive to every
programmer. Those features are still incredibly useful to the
programmers that DO use them.

Maybe, with hindsight, for-finally would have been a slightly better
spelling than for-else.
No.  "finally" suggests (as analogy to try...finally) that the "finally" 
suit body is always executed.  Presumably even if an untrapped exception 
occurs in the for-loop body (or even in the for-loop iterator).  A 
for-loop can be terminated with "break" for many  conceptually different 
reasons e.g.

    A search for a suitable item has found one.
    Something unexpected has happened.
    A pre-set allowed execution time has been exceeded.
"nobreak"/"no_break" etc. is explicit and conceptually neutral.

  Who knows. But people simply need to
understand it, just like people need to understand how binary
floating-point works, and claiming that it's "ambiguous' is simply
wrong. It has one meaning in the language, and then if programmers
have an incorrect expectation, they need to learn (or to not use the
feature, which isn't really a problem, it's just not taking advantage
of it).


And naturally, since nobody desperately wants to use non-reserved keywords, 
nobody seems ready to use a word like INSTEAD instead.

Ideally, a language should be extendable and some languages like R allow you to 
place all kinds of things inside percent signs to make new operators like %*% 
or %PIPE% ...


I don't know what you mean by "extendable", but if you mean that
different people should be able to change the language syntax in
different ways, then absolutely not. When two different files can be
completely different languages based on a few directives, it's
extremely difficult to read.
+0.9, although I do sometimes wish for a macro feature in Python. Like, 
say, one that would translate "nobreak" into "else". 😁


(Import hooks, and tools like MacroPy, can be used for this sort of
effect.

I haven't tried MacroPy yet, maybe someday I will.

  I do not think that we should be using them on a regular basis
to change core syntax.)


Just because some feature may be wanted is not a good reason to overly 
complicate a language. Can you imagine how hard it would be both to implement 
and read something like:

...
ELSE:
...
OK:
...
FINALLY:
...
ULTIMATELY:
...

What if multiple of things like the above example need to be triggered in some 
particular order?

It would be easy to read if they were spelt sensibly, e.g.
    if_no_iterations:
    if_one_iteration:
    if_multiple_iterations:
    if_any_iterations:
    if_break:
    if_no_break:
(I'm not saying that all of these are desirable, just conveying the idea.)
If multiple clauses were triggered, they should be executed in the order 
in which they occur in the code.

I don't know what they'd all mean, but if they were all in the core
language, they would have to be supported in arbitrary combinations.
It's possible to have a "try-except-else-finally" block in Python, for
instance. But if you mean that they should all do what "else" does
now, then this is a terrible idea. One way of spelling it is just
fine.


This reminds me a bit of how some programs add so much functionality because someone 
thought of it without wondering if anyone (including the ones who sponsored it) would 
ever want to use it or remember it is there or how. I recall how a version of emacs had a 
transpose-letter function so after typing "teh" you could hit control-t and a 
little mock LISP macro would go back and co a cut and go forward and do a paste and leave 
the cursor where it was. That was sometimes useful, bu

Re: Behavior of the for-else construct

[Rob Cliffe via Python-list]

On 04/03/2022 00:38, Avi Gross via Python-list wrote:

Rob,

I regularly code with lots of comments like the one you describe, or mark the 
end of a region that started on an earlier screen such as a deeply nested 
construct.

So do I (and not just in Python).  It's good practice.


I have had problems though when I have shared such code and the recipient 
strips my comments and then later wants me to make changes or even just explain 
it! My reply tends to be unprintable as in, well, never mind!
Quite justified.  But why not make changes to/explain from *your* 
version, not his?


This leads to a question I constantly ask. If you were free to design a brand 
new language now, what would you do different that existing languages have had 
to deal with the hard way?

That's such a big question that I can't give an adequate answer.


I recall when filenames and extensions had a limited number of characters allowed and 
embedded spaces were verboten. This regularity made lots of code possible but then some 
bright people insisted on allowing spaces and you can no longer easily do things like 
expand *.c into a long line of text and then unambiguously work on one file name at a 
time. You can often now create a name like "was file1.c and now is file2.c" and 
it seems acceptable. Yes, you can work around things and get a vector or list of strings 
and not a command line of text and all things considered, people can get as much or more 
work done.

I have seen major struggles to get other character sets into languages. Any new 
language typically should have this built in from scratch and should consider 
adding non-ASCII characters into the mix. Mathematicians often use lots of weird 
braces/brackets as an example while normal programs are limited to [{( and maybe 
< and their counterparts. This leads to odd Python behavior (other languages 
too) where symbols are re-used ad nauseam. { can mean set or dictionary or simply 
some other way to group code.

So I would love to see some key that allows you to do something like L* to mean the combination is 
a left bracket and should be treated as the beginning of a sequence expected to end in R* or 
perhaps *R. That would allow many other symbols to be viewed as balanced entities. Think of how 
Python expanded using single and double quotes (which arguably might work better if balanced this 
way) to sometimes using triple quotes to putting letters like "b" or "f" in 
front to make it a special kind of string.

But I suspect programming might just get harder for those who would not 
appreciate a language that used (many) hundreds of symbols.

+1.  Just remembering how to type them all would be a burden.

  I do work in many alphabets and many of them pronounce and use letters that 
look familiar in very different ways and sound them differently and invent new 
ones. Every time I learn another human language, I have to both incorporate the 
new symbols and rules and also segregate them a bit from identical or similar 
things in the languages I already speak. It can be quite a chore. But still, I 
suspect many people are already familiar with symbols such as from set Theory 
such as subset and superset that could be used as another pair of parentheses 
of some type Having a way to enter them using keyboards is a challenge.

Back to the topic, I was thinking wickedly of a way to extend the FOR loop with 
existing keywords while sounding a tad ominous is not with  an ELSE but a FOR 
... OR ELSE ...


-Original Message-
From: Rob Cliffe via Python-list 
To: python-list@python.org
Sent: Thu, Mar 3, 2022 7:13 pm
Subject: Re: Behavior of the for-else construct


I find it so hard to remember what `for ... else` means that on the very
few occasions I have used it, I ALWAYS put a comment alongside/below the
`else` to remind myself (and anyone else unfortunate enough to read my
code) what triggers it, e.g.

      for item in search_list:
          ...
          ... break
      else: # if no item in search_list matched the criteria

You get the idea.
If I really want to remember what this construct means, I remind myself
that `else` here really means `no break`.  Would have been better if it
had been spelt `nobreak` or similar in the first place.
Rob Cliffe


On 03/03/2022 23:07, Avi Gross via Python-list wrote:

The drumbeat I keep hearing is that some people hear/see the same word as 
implying something else. ELSE is ambiguous in the context it is used.

And naturally, since nobody desperately wants to use non-reserved keywords, 
nobody seems ready to use a word like INSTEAD instead.

Ideally, a language should be extendable and some languages like R allow you to 
place all kinds of things inside percent signs to make new operators like %*% 
or %PIPE% ...

Just because some feature may be wanted is not a good reason to overly 
complicate a language. Can you imagine how hard it would be both to implement 
and read something like:

...
ELSE:
      ...
OK:
      ...
FINA

Re: Behavior of the for-else construct

[Rob Cliffe via Python-list]

On 04/03/2022 00:43, Chris Angelico wrote:

On Fri, 4 Mar 2022 at 11:14, Rob Cliffe via Python-list
 wrote:

I find it so hard to remember what `for ... else` means that on the very
few occasions I have used it, I ALWAYS put a comment alongside/below the
`else` to remind myself (and anyone else unfortunate enough to read my
code) what triggers it, e.g.

  for item in search_list:
  ...
  ... break
  else: # if no item in search_list matched the criteria

A "break" statement always takes you to the line following the current
loop construct. The "else" block is part of the current loop
construct. It's no more a "no-break" block than the body of the for
loop is a "no-break" body here:

for item in stuff:
 if condition: break
 frobnicate(item) # if no previous item matched the condition


You get the idea.
If I really want to remember what this construct means, I remind myself
that `else` here really means `no break`.  Would have been better if it
had been spelt `nobreak` or similar in the first place.

Maybe, but I think that obscures the meaning of it; "finally" isn't
quite right either (in a try block, you'd hit a finally block whether
you raise an exception or not), but I think it's closer. Creating a
new language keyword is an incredibly high cost.

Think of it like this:

for item in search_list:
 if condition: pass
 else:
 print("Condition not true for this item")

for item in search_list:
 if condition: break
else:
 print("Condition not true for any item")

There's a parallel here. Since a for-else loop is basically useless
without an if-break construct inside it,

Yes but you have to remember what for-else means even to grasp that point.

  the else clause can be
thought of as the else on a massive if/elif chain:

if stuff[0].is_good:
 print("This item is good", stuff[0])
elif stuff[1].is_good:
 print("This item is good", stuff[1])
...
...
elif stuff[n].is_good:
 print("This item is good", stuff[n])
else:
 print("All items are bad")

As a loop, this looks like this:

for item in stuff:
 if item.is_good:
 print("This item is good", item)
 break
else:
 print("All items are bad")

The else is attached to the for so that it compasses ALL the if
statements, but it's still broadly saying "do this when we don't hit
the 'if' condition".

Whether that's a sufficient mnemonic, I don't know,

Not for me, I'm afraid.

  but it doesn't
really matter; the construct is useful to those of us who want it, and
if other people ignore it, that's fine. Nobody ever said you had to
use or understand every single feature of the language you're using.

ChrisA


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

Re: Behavior of the for-else construct

[Ethan Furman]

On 3/3/22 5:32 PM, Rob Cliffe via Python-list wrote:

> There are three types of programmer: those that can count, and those that 
can't.

Actually, there are 10 types of programmer:  those that can count in binary, 
and those that can't.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Greg Ewing]

On 4/03/22 1:55 pm, Chris Angelico wrote:

It's much better to treat arguments as a vector of strings
rather than a single string, as the start command tries to.


It would be nice if you could, but as I understand it, Windows always
passes arguments to a program as a single string, and then it's up to
the program to split it up how it wants. Different programs do that in
different ways, hence the inconsistencies in how quoting and whitespace
is handled.

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

Re: Behavior of the for-else construct

[Rob Cliffe via Python-list]

On 04/03/2022 01:44, Ethan Furman wrote:

On 3/3/22 5:32 PM, Rob Cliffe via Python-list wrote:

> There are three types of programmer: those that can count, and those 
that can't.


Actually, there are 10 types of programmer:  those that can count in 
binary, and those that can't.

1, 10, many.
No problem.


--
~Ethan~


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

Re: Behavior of the for-else construct

[Rob Cliffe via Python-list]

On 04/03/2022 00:55, Chris Angelico wrote:


for victim in debtors:
 if victim.pay(up): continue
 if victim.late(): break
or else:
 victim.sleep_with(fishes)
If you mean "or else" to be synonymous with "else", then only the last 
debtor is killed, whether he has paid up or not, which seems a tad 
unfair (except that if there are no debtors either you will crash with a 
NameError or some random victim will be killed, which seems consistent 
with Mafia modus operandi while also being a trifle unfair.
If (as I suspect) you mean "or else" to mean 'if a break occurred', then 
at least only one debtor is killed, as an example to the others, and no 
Exception will occur in the unlikely event of "debtors" being empty.

Happy fund-raising!
Rob Cliffe


There's something in this.

ChrisA


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

Re: Behavior of the for-else construct

[Jach Feng]

I never feel confused by "else" because I always think it in "break...else", 
not "for...else". For those who always think in "for...else" deserves this 
confusion and it can't be just escaped by replacing with another magic word 
such as "then" or "finally" etc:-)

--Jach

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

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

Rob,

I consider my comments in code I write to be a (silent) part of the code, or 
worse, some code I commented out but want to be able to look at.

I often have code like:

# NOTE you can turn on one of the following that applies to your situation
# and comment out the others but leave them in place.
FILENAME = "C: ..."
#FILENAME = "I: ...

The second line is uncommented if this is run on another machine where the file 
is on the I: drive. Often code I write is sent to someone who has to make it 
work on their machine or selectively has regions turned off.

# Decide if the next section should be run by selecting the line that 
represents your needed.
NORMALIZE = True
# NORMALIZE = False

if (NORMALIZE):
...

In cases like the above, which are not the majority of how I use comments, 
keeping it as I defined it makes sense even if some of the commented code is 
not running. It makes it easier to make customizations. I often have requests 
for example to read in a .CSV and depending on the situation, make multiple 
transformations to it that can include removing columns or filtering out rows, 
normalizing one or more columns, dealing with outliers beyond some designated 
level, creating new derived columns based on existing ones, or a Boolean 
reflecting some complex condition, or grouping it some way or merging it with 
other data and so on. If writing for myself, I might do it all in one pipeline. 
But if writing it for someone who plays games and tries this versus that, then 
something like the above, with suitable comments, lets them experiment by 
turning sections on and off and other forms of customization. I consider the 
presence of comments a serious part of what i deliver. 

Yes, the interpreter (and sometimes compiler) strips them but leaving them in 
the source file does not strike me as expensive.  Once removed, I consider the 
person who did it suspect and am less inclined to work with them. Consider code 
with an embedded copyright of some sort (or apparently GNU has a copyleft) and 
whether it is valid to separate that from the code?

And note that some code we write may be quite elegant but also rather 
mysterious and seeing it again a year later it may not be easy to see why we 
did that and whether some other way might not work as well. Decent comments 
explaining the algorithm and why choices were made may make all the difference. 
Or, they may make it easy to see how to convert the code to deal with one more 
or one less variable by changing it in the right places consistently.

To answer something Chris said and was also mentioned here, I do not consider 
language design to be easy let alone implementing it. Not at all. BUT I think 
some changes can be straightforward. Having a symbol like a curly brace mean 
three new things may be tough to implement. Allowing a new symbol in an 
expanded set of characters seems more straightforward. 

Consider an arrow symbol → pointing to the right and another pointing the other 
way. Could we add the symbol to the language as a single character, albeit 
implemented using multiple bytes? If my editor let me insert the darn thing, it 
might then  be a reasonable use for some construct in the language unique and 
new. Maybe the language would use the notation to hold objects holding a set 
and not confuse the notations for sets and dictionaries as Python ended up 
doing. (Yes, I know it is NOT confusing in some ways as one holds key:value 
pairs and the other just value, but making an empty set now requires the 
notation of set() while an empty dictionary is {} right?

So how hard is it for a newly designed language to recognize any use of one 
arrow and expect everything up to the next arrow (pointing back) to be the 
contents of a set? It sounds a tad easier than now when Python interpreters 
have to pause when they see an open bracket and read what follows to see if 
everything beyond uses dictionary notation before it decides.

But NO, I am not volunteering to do any of that. A language with too many 
symbols may be far worse. We cannot give every single object type their own 
symbols. But a few more than we have now might make it easier to create objects 
Python omitted  and numpy and pandas and other modules had to add back the hard 
way.  

The only reason this is coming up is teh discussion of how various people react 
to the exact choice of how to add a new feature. I doubt people will like many 
choices in a new language created sort of like I describe, either. And nobody 
wants a new keyboard with a thousand keys, even if their language is Chinese. 
But there are days I want one a bit like that as I often write, as mentioned, 
in languages with additional characters or entirely other alphabets. Sigh.

Life is complicated, then you die and it simplifies.


-Original Message-
From: Rob Cliffe via Python-list 
To: python-list@python.org
Sent: Thu, Mar 3, 2022 8:41 pm
Subject: Re: Behavior of the for-else construct




On 04/03/2022

Re: Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 14:05, Avi Gross via Python-list
 wrote:
> To answer something Chris said and was also mentioned here, I do not consider 
> language design to be easy let alone implementing it. Not at all. BUT I think 
> some changes can be straightforward. Having a symbol like a curly brace mean 
> three new things may be tough to implement. Allowing a new symbol in an 
> expanded set of characters seems more straightforward.
>
> Consider an arrow symbol → pointing to the right and another pointing the 
> other way. Could we add the symbol to the language as a single character, 
> albeit implemented using multiple bytes? If my editor let me insert the darn 
> thing, it might then  be a reasonable use for some construct in the language 
> unique and new. Maybe the language would use the notation to hold objects 
> holding a set and not confuse the notations for sets and dictionaries as 
> Python ended up doing. (Yes, I know it is NOT confusing in some ways as one 
> holds key:value pairs and the other just value, but making an empty set now 
> requires the notation of set() while an empty dictionary is {} right?
>
> So how hard is it for a newly designed language to recognize any use of one 
> arrow and expect everything up to the next arrow (pointing back) to be the 
> contents of a set? It sounds a tad easier than now when Python interpreters 
> have to pause when they see an open bracket and read what follows to see if 
> everything beyond uses dictionary notation before it decides.
>
> But NO, I am not volunteering to do any of that.

That is exactly why (well, one of the reasons why) I recommended going
the whole way and designing a language in full. You will know exactly
how hard it actually is. In fact, "pause when they see an open
bracket" is the least of your worries :)

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

Re: Behavior of the for-else construct

[Avi Gross via Python-list]

That is one way to look at it, Jach. Of course, a particular loop may have 
multiple break statements each meaning something else. The current 
implementation makes all of them jump to the same ELSE statement so in one 
sense, I consider the ELSE to be associated with the loop as a whole. Sometimes 
the loop may not even have a break statement and yet the dangling ELSE seems to 
be accepted anyway.

Some languages allow you to break out of deeply nested loops by jumping up two 
or more levels, perhaps to a label and are more of a goto. I shudder to think 
how that would work if each loop had an ELSE dangling. 


-Original Message-
From: Jach Feng 
To: python-list@python.org
Sent: Thu, Mar 3, 2022 9:22 pm
Subject: Re: Behavior of the for-else construct


I never feel confused by "else" because I always think it in "break...else", 
not "for...else". For those who always think in "for...else" deserves this 
confusion and it can't be just escaped by replacing with another magic word 
such as "then" or "finally" etc:-)



--Jach



-- 

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

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

Re: Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 14:37, Avi Gross via Python-list
 wrote:
>
> That is one way to look at it, Jach. Of course, a particular loop may have 
> multiple break statements each meaning something else. The current 
> implementation makes all of them jump to the same ELSE statement so in one 
> sense, I consider the ELSE to be associated with the loop as a whole. 
> Sometimes the loop may not even have a break statement and yet the dangling 
> ELSE seems to be accepted anyway.
>
> Some languages allow you to break out of deeply nested loops by jumping up 
> two or more levels, perhaps to a label and are more of a goto. I shudder to 
> think how that would work if each loop had an ELSE dangling.
>

It would happen exactly the same way. I don't know why you're so
afraid of the else clause. It's simply part of the loop body, and if
you break out of the loop body, you skip it. If Python had a way to
break out of multiple loop bodies at once, it would skip the else
clauses of any that you break out of.

This is not complicated. You can argue that it could be better named
(but honestly, I'm not a fan of any of the other proposed names
either), but the concept, at its heart, is a simple one.

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

Re: Python

[Dan Stromberg]

Whatever happened to sending a URL to a specific answer in a FAQ list?

On Thu, Mar 3, 2022 at 12:52 PM Dan Ciprus (dciprus) via Python-list <
python-list@python.org> wrote:

> if OP formulates question the way he/she did, it's not worth to respond to
> it.
> There is plenty of similar questions in the archive.
>
> On Tue, Feb 22, 2022 at 07:07:54AM -0700, Mats Wichmann wrote:
> >On 2/21/22 23:17, SASI KANTH REDDY GUJJULA wrote:
> >> Pip files are not installing after the python 3.10.2 version installing
> in my devise. Please solve this for me.
> >
> >Please ask a clearer question.
> >
> >Can you tell us what "are not installing" means? Are you getting
> >permission errors?  Are you installing and then unable to import what
> >you have installed?  Something else?
> >
> >--
> >https://mail.python.org/mailman/listinfo/python-list
>
> --
> Daniel Ciprus  .:|:.:|:.
> CONSULTING ENGINEER.CUSTOMER DELIVERY   Cisco Systems Inc.
>
> [ curl -L http://git.io/unix ]
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Dieter Maurer]

Rob Cliffe wrote at 2022-3-4 00:13 +:
>I find it so hard to remember what `for ... else` means that on the very
>few occasions I have used it, I ALWAYS put a comment alongside/below the
>`else` to remind myself (and anyone else unfortunate enough to read my
>code) what triggers it, e.g.
>
>     for item in search_list:
>         ...
>         ... break
>     else: # if no item in search_list matched the criteria
>
>You get the idea.
>If I really want to remember what this construct means, I remind myself
>that `else` here really means `no break`.  Would have been better if it
>had been spelt `nobreak` or similar in the first place.

One of my use cases for `for - else` does not involve a `break`:
the initialization of the loop variable when the sequence is empty.
It is demonstrated by the following transscript:

```pycon
>>> for i in range(0):
...   pass
...
>>> i
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'i' is not defined
>>> for i in range(0):
...   pass
... else: i = None
...
>>> i
>>>
```

For this use case, `else` is perfectly named.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Behavior of the for-else construct

[Chris Angelico]

On Fri, 4 Mar 2022 at 18:13, Dieter Maurer  wrote:
>
> Rob Cliffe wrote at 2022-3-4 00:13 +:
> >I find it so hard to remember what `for ... else` means that on the very
> >few occasions I have used it, I ALWAYS put a comment alongside/below the
> >`else` to remind myself (and anyone else unfortunate enough to read my
> >code) what triggers it, e.g.
> >
> > for item in search_list:
> > ...
> > ... break
> > else: # if no item in search_list matched the criteria
> >
> >You get the idea.
> >If I really want to remember what this construct means, I remind myself
> >that `else` here really means `no break`.  Would have been better if it
> >had been spelt `nobreak` or similar in the first place.
>
> One of my use cases for `for - else` does not involve a `break`:
> the initialization of the loop variable when the sequence is empty.
> It is demonstrated by the following transscript:
>
> ```pycon
> >>> for i in range(0):
> ...   pass
> ...
> >>> i
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'i' is not defined
> >>> for i in range(0):
> ...   pass
> ... else: i = None
> ...
> >>> i
> >>>
> ```
>
> For this use case, `else` is perfectly named.

What's the point of this? Why not just put "i = None" after the loop?

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