[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[Christian Heimes]

Christian Heimes  added the comment:

I don't agree with GH-31673. Did you try defining NO_MISALIGNED_ACCESSES 
instead?

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

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

[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work

[Vinay Sajip]

Vinay Sajip  added the comment:

> If so, then it probably good to adjust ... since it still talks about it 
> being expected.

Do you mean just adding a note to the effect that SysLogHandler won't work on 
macOS 12.2 because of changes to the syslog daemon on that platform?

IIRC using the syslog module was not an option at the time SysLogHandler was 
added, I think because of both thread-safety and lack-of-functionality issues.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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: 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: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

[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work

[Philip Bloom]

Philip Bloom  added the comment:

I could certainly understand that.  It's a weird apple choice.  

If so, then it probably good to adjust 
https://docs.python.org/3/library/logging.handlers.html#sysloghandler since it 
still talks about it being expected.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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 

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

[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()

[Eryk Sun]

Eryk Sun  added the comment:

> e = Path(r'F:\ceven\test2')

Using forward slashes in the string literal is preferred, e.g. 
Path('F:/ceven/test2'). This avoids the problem of backslash escapes in string 
literals. The Path constructor parses the path and stores it internally as 
component parts. When the path object is needed as a string, os.fspath() 
returns the path using the platform's preferred path separator. A WindowsPath 
or PureWindowsPath uses backslash as the path separator. For example:

>>> os.fspath(pathlib.PureWindowsPath('F:/ceven/test2'))
'F:\\ceven\\test2'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()

[Eryk Sun]

Eryk Sun  added the comment:

> FileNotFoundError: [WinError 3] The system cannot find 
> the path specified: 'F:\\ceven\\test2'

The Windows error code, ERROR_PATH_NOT_FOUND (3), indicates that the parent 
path, r"F:\ceven", does not exist. Try e.mkdir(parents=True) [1].

[1] https://docs.python.org/3/library/pathlib.html#pathlib.Path.mkdir

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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

[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

[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

[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:
      ...

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, 

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 

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 

[issue46744] installers on ARM64 suggest wrong folders

[Steve Dower]

Steve Dower  added the comment:


New changeset 8f31bf46980956c735dd18f9914f3e7144e87c77 by Steve Dower in branch 
'main':
bpo-46744: Move Windows ARM64 installation directory to correct ProgramFiles 
(GH-31677)
https://github.com/python/cpython/commit/8f31bf46980956c735dd18f9914f3e7144e87c77


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[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 

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

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 6a14330318c9c7aedf3e9841c3dfea337064d8e6 by Victor Stinner in 
branch '3.9':
bpo-46913: Fix test_ctypes, test_hashlib, test_faulthandler on UBSan (GH-31675) 
(GH-31676)
https://github.com/python/cpython/commit/6a14330318c9c7aedf3e9841c3dfea337064d8e6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46744] installers on ARM64 suggest wrong folders

[Steve Dower]

Steve Dower  added the comment:

Posted half a PR for this, which is worth taking in itself, but doesn't 
completely address the whole change. It will install to the correct 
ProgramFiles folder on ARM64 now, but still with the suffix.

If we are to take the rest of the change (use "-amd64" for AMD64 builds on 
ARM64 OS), it has to be ready for beta 1. There's still time, but absent a 
major issue from *not* doing it, we want to avoid changing on-disk layout 
during beta/RC.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46744] installers on ARM64 suggest wrong folders

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +29797
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31677

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29796
pull_request: https://github.com/python/cpython/pull/31676

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7b5b429adab4fe0fe81858fe3831f06adc2e2141 by Victor Stinner in 
branch '3.10':
[3.10] bpo-46913: Fix test_ctypes, test_hashlib, test_faulthandler on UBSan 
(GH-31675)
https://github.com/python/cpython/commit/7b5b429adab4fe0fe81858fe3831f06adc2e2141


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42337] Skip building web installers on Windows

[Steve Dower]

Steve Dower  added the comment:

Forget exactly when I did this, but I did it.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:

I pushed changes just to turn back the buildbot back to green, but undefined 
behaviors in test_ctypes.test_shorts() and _sha3 (tested by test_hashlib) must 
be fixed.

Previously, test_ctypes, test_hashlib and test_faulthandler were fully skipped 
on UBSan. Now only 1 test_ctypes test and a few test_hashlib tests are skipped 
on the UBSan buildbot (test_faulthandler now pass on UBSan).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29795
pull_request: https://github.com/python/cpython/pull/31675

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:


New changeset ec4a580f7cada002441ae5611b909d56e3b5b613 by Victor Stinner in 
branch 'main':
bpo-46355: Update pythoncapi_compat project URL (GH-31670)
https://github.com/python/cpython/commit/ec4a580f7cada002441ae5611b909d56e3b5b613


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:


New changeset ad1b04451d3aca2c6fa6dbe2891676a4e0baac49 by Victor Stinner in 
branch 'main':
bpo-46913: Skip test_ctypes.test_shorts() on UBSan (GH-31674)
https://github.com/python/cpython/commit/ad1b04451d3aca2c6fa6dbe2891676a4e0baac49


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 6d0d7d2b8c1e04fd51c6cb29cc09a41b60b97b7b by Victor Stinner in 
branch 'main':
bpo-46913: test_hashlib skips _sha3 tests on UBSan (GH-31673)
https://github.com/python/cpython/commit/6d0d7d2b8c1e04fd51c6cb29cc09a41b60b97b7b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46852] Remove the float.__set_format__() method

[STINNER Victor]

STINNER Victor  added the comment:

I created a follow-up issue: bpo-46917 "Require IEEE 754 floating point to 
build Python 3.11". I close this one: float.__set_format__() has been removed.

--
resolution:  -> fixed
status: open -> closed
title: Remove the float.__setformat__() method -> Remove the 
float.__set_format__() method

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:

The initial issue "Python leaks one reference at exit on Windows" is now fixed.

If someone wants to investigate the remaining leak of 1 memory block or the 
negative ref count of PYTHONDUMPREFS=1, please open a separated issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-46887: ./Programs/_freeze_module fails with MSAN: Uninitialized 
value was created by an allocation of 'stat.i'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46841] Inline bytecode caches

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset 05a8bc1c944709e7468f157bd1b6032f368e43bf by Brandt Bucher in 
branch 'main':
bpo-46841: Use inline caching for attribute accesses (GH-31640)
https://github.com/python/cpython/commit/05a8bc1c944709e7468f157bd1b6032f368e43bf


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 65b92ccdec2ee4a99e54aaf7ae2d9bbc2ebfe549 by Victor Stinner in 
branch 'main':
bpo-46913: Fix test_faulthandler.test_read_null() on UBSan (GH31672)
https://github.com/python/cpython/commit/65b92ccdec2ee4a99e54aaf7ae2d9bbc2ebfe549


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29794
pull_request: https://github.com/python/cpython/pull/31674

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29793
pull_request: https://github.com/python/cpython/pull/31673

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue46915] Build with Py_LIMITED_API fails unknown type name ‘PyModuleDef_Slot’

[Christian Heimes]

Christian Heimes  added the comment:

Please add a blurb entry.

--
assignee: christian.heimes -> vstinner
priority:  -> normal
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()

[Vincent FUNG]

Vincent FUNG  added the comment:

This problem occurs when the directory starts with 't', but works with 
os.makedirs(e) or macOS.

>>> e = Path(r'F:\ceven\test2')
>>> e.mkdir()
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program Files\Python310\lib\pathlib.py", line 1173, in mkdir
self._accessor.mkdir(self, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 
'F:\\ceven\\test2'
>>> os.makedirs(e)



Another question about \t:

If a directory is passed as a parameter it will not be possible to use the 
parameter as a raw string. os.makedirs gives the same error whether it's r'%s' 
or repr().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29792
pull_request: https://github.com/python/cpython/pull/31672

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:

> https://github.com/python/buildmaster-config/commit/0fd1e3e49e4b688d5767501484cccea5fa35d3fc

Previously, 4 tests were skipped on the UBSAN buildbot

* test_faulthandler
* test_hashlib
* test_concurrent_futures
* test_ctypes

It's not a regression, it's just that I made the buildbot stricter. I'm 
planning to attempt to fix the 3 failing tests, or at least skip them in 
Python, rather than skipping them in the buildbot configuration.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46917] Require IEEE 754 floating point to build Python 3.11

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46917] Require IEEE 754 floating point to build Python 3.11

[STINNER Victor]

New submission from STINNER Victor :

See "[Python-Dev] Should we require IEEE 754 floating-point for CPython?" 
thread:
https://mail.python.org/archives/list/python-...@python.org/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/

I propose to require IEEE 754 floating-point to build Python 3.11. I propose 
the following build:

* Mention the new build requirement in What's New in Python 3.11.
* Modify configure script to make it fail if the IEEE 754 support is missing.
* Remove code handling missing NAN and infinity: float("nan"), float("inf"), 
math.nan and math.inf are always available.
* Remove @requires_IEEE_754 decorator of test.support and tests.
* Remove "unknown_format" code path of pack/unpack functions like 
_PyFloat_Pack8() (see bpo-46906 which proposes to make these functions public).


The _PY_SHORT_FLOAT_REPR==0 code path is kept. For now, platforms with float 
larger than 64-bit but without HAVE_PY_SET_53BIT_PRECISION are still supported 
(but don't get "short float repr"). See GH-31592 for details.


I prepared this requirement with these two changes:

commit 1b2611eb0283055835e5df632a7a735db8c894b8
Author: Victor Stinner 
Date:   Fri Feb 25 01:32:57 2022 +0100

bpo-46656: Remove Py_NO_NAN macro (GH-31160)

Building Python now requires support for floating point Not-a-Number
(NaN): remove the Py_NO_NAN macro.

commit 5ab745fc51e159ead28b523414e52f0bcc1ef353
Author: Victor Stinner 
Date:   Sat Feb 26 00:53:27 2022 +0100

bpo-46852: Remove the float.__set_format__() method (GH-31585)

Remove the undocumented private float.__set_format__() method,
previously known as float.__set_format__() in Python 3.7. Its
docstring said: "You probably don't want to use this function. It
exists mainly to be used in Python's test suite."


By the way, building Python 3.11 now requires a C11 compiler.

--
components: Build
messages: 414485
nosy: vstinner
priority: normal
severity: normal
status: open
title: Require IEEE 754 floating point to build Python 3.11
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46841] Inline bytecode caches

[Brandt Bucher]

Change by Brandt Bucher :


--
pull_requests: +29791
pull_request: https://github.com/python/cpython/pull/31671

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25415] [io doc] Reword "there is no public constructor"

[Irit Katriel]

Irit Katriel  added the comment:

> I think that the fix should be to delete the original incorrect statement and 
> not replace it with another incorrect statement.


I agree with this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()

[Vincent FUNG]

New submission from Vincent FUNG :

This problem occurs when the directory starts with 't', but works with 
os.makedirs(e) or macOS.

>>> e = Path(r'F:\ceven\test2')
>>> e.mkdir()
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program Files\Python310\lib\pathlib.py", line 1173, in mkdir
self._accessor.mkdir(self, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 
'F:\\ceven\\test2'
>>> os.makedirs(e)

--
components: Windows
messages: 414483
nosy: paul.moore, steve.dower, tim.golden, vincent.fung, zach.ware
priority: normal
severity: normal
status: open
title: There is a problem with escape characters in the path passed in by 
pathlib.Path.mkdir()
type: behavior
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45711] Simplify the interpreter's (type, val, tb) exception representation

[STINNER Victor]

STINNER Victor  added the comment:

lxml does crash on the current Cython 0.29.x development branch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46355] [C API] Document PyFrameObject and PyThreadState changes and explain how to port code to Python 3.11

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29789
pull_request: https://github.com/python/cpython/pull/31670

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45459] Limited API support for Py_buffer

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 32f0c8271706550096c454eb512450b85fbfc320 by Victor Stinner in 
branch 'main':
bpo-45459: Use type names in the internal C API (GH-31669)
https://github.com/python/cpython/commit/32f0c8271706550096c454eb512450b85fbfc320


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46915] Build with Py_LIMITED_API fails unknown type name ‘PyModuleDef_Slot’

[STINNER Victor]

STINNER Victor  added the comment:

Fixed by 
https://github.com/python/cpython/commit/0b63215bb152c06404cecbd5303b1a50969a9f9f

--
priority: release blocker -> 
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'

[William Woodruff]

William Woodruff  added the comment:

Nosying myself; this affects 3.9 and 3.10 as well.

--
nosy: +yossarian
versions: +Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45459] Limited API support for Py_buffer

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 0b63215bb152c06404cecbd5303b1a50969a9f9f by Victor Stinner in 
branch 'main':
bpo-45459: Fix PyModuleDef_Slot type in the limited C API (GH-31668)
https://github.com/python/cpython/commit/0b63215bb152c06404cecbd5303b1a50969a9f9f


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:

Reproducer of test_ctypes undefined behavior:
---
from ctypes import *

class BITS(Structure):
_fields_ = [("A", c_int, 1),
("B", c_int, 2),
("C", c_int, 3),
("D", c_int, 4),
("E", c_int, 5),
("F", c_int, 6),
("G", c_int, 7),
("H", c_int, 8),
("I", c_int, 9),

("M", c_short, 1),
("N", c_short, 2),
("O", c_short, 3),
("P", c_short, 4),
("Q", c_short, 5),
("R", c_short, 6),
("S", c_short, 7)]

b = BITS()
a = getattr(b, "M")
---

> GET_BITFIELD(val, size); // < HERE

I expanded the macro:
---
if (NUM_BITS(size)) {
size_t s = sizeof(val)*8;
Py_ssize_t low = LOW_BIT(size);
Py_ssize_t nbits = NUM_BITS(size);
// val=0, size=65553 = (1 << 16) + 17
// s=16, low=17, nbits=1
// s - low - nbits = (size_t)-2
val <<= (s - low - nbits);
val >>= (s - nbits);
}
---

The problem is that (s - low - nbits) is negative (-2), but becomes a very 
large number since it's unsigned (s is unsigned: "sizeof(v)*8" in the macro).

C code:
---
#include 

int main()
{
short s = 0x7fff;
size_t z = (size_t)-2;
s <<= z;
printf("s = %hi\n", s);
return 0;
}
---

GCC and clang disagree :-D
---
$ gcc x.c -o x -O3 -Wall -Wextra -Wconversion && ./x
s = 0

$ clang x.c -o x -O3 -Wall -Wextra -Wconversion && ./x
s = -5784
---

Moreover, runtime the binary built by clang produces a different result at each 
run...
---
$ ./x
s = -4824
$ ./x
s = 4120
$ ./x
s = -22344
$ ./x
s = -26744
$ ./x
s = -18184
---

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45459] Limited API support for Py_buffer

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29788
pull_request: https://github.com/python/cpython/pull/31669

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46915] Build with Py_LIMITED_API fails unknown type name ‘PyModuleDef_Slot’

[STINNER Victor]

STINNER Victor  added the comment:

I proposed a fix: https://github.com/python/cpython/pull/31668

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46915] Build with Py_LIMITED_API fails unknown type name ‘PyModuleDef_Slot’

[Christian Heimes]

Christian Heimes  added the comment:

With fix:

$ /tmp/python311/bin/pip3 install --no-binary :all: cryptography
Collecting cryptography
  Using cached cryptography-36.0.1.tar.gz (572 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
Preparing wheel metadata ... done
Requirement already satisfied: cffi>=1.12 in 
/tmp/python311/lib/python3.11/site-packages (from cryptography) (1.15.0)
Requirement already satisfied: pycparser in 
/tmp/python311/lib/python3.11/site-packages (from cffi>=1.12->cryptography) 
(2.21)
Building wheels for collected packages: cryptography
  Building wheel for cryptography (PEP 517) ... done
  Created wheel for cryptography: 
filename=cryptography-36.0.1-cp311-cp311-linux_x86_64.whl size=2628351 
sha256=fb3cc21f8eaa546cd2c0123ea01a98bf92a9824fcdca36cfcf765b2c044bd186
  Stored in directory: 
/home/heimes/.cache/pip/wheels/6c/77/a9/3c4762d4e65bef5f742a304c507f9723ca3563a38d108618ad
Successfully built cryptography
Installing collected packages: cryptography
Successfully installed cryptography-36.0.1


Without fix:

  gcc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC 
-I/tmp/python311/include/python3.11 -c build/temp.linux-x86_64-3.11/_openssl.c 
-o build/temp.linux-x86_64-3.11/build/temp.linux-x86_64-3.11/_openssl.o 
-Wconversion -Wno-error=sign-conversion
  In file included from /tmp/python311/include/python3.11/Python.h:66,
   from build/temp.linux-x86_64-3.11/_openssl.c:57:
  /tmp/python311/include/python3.11/moduleobject.h:82:3: error: unknown type 
name ‘PyModuleDef_Slot’
 82 |   PyModuleDef_Slot *m_slots;
|   ^~~~

--
keywords:  -patch
stage: patch review -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45459] Limited API support for Py_buffer

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29787
pull_request: https://github.com/python/cpython/pull/31668

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46915] Build with Py_LIMITED_API fails unknown type name ‘PyModuleDef_Slot’

[Christian Heimes]

Change by Christian Heimes :


--
keywords: +patch
pull_requests: +29786
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31667

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46915] Build with Py_LIMITED_API fails unknown type name ‘PyModuleDef_Slot’

[Christian Heimes]

Christian Heimes  added the comment:

The problem was first reported to PyCA cryptography project in bug 
https://github.com/pyca/cryptography/issues/6929

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46915] Build with Py_LIMITED_API fails unknown type name ‘PyModuleDef_Slot’

[Christian Heimes]

New submission from Christian Heimes :

Extension modules with bare "#define Py_LIMITED_API" without version fail to 
build with error:

   moduleobject.h:82:3: error: unknown type name ‘PyModuleDef_Slot’

The issue was introduced in PR GH-31528 and bpo-45459. The type 
PyModuleDef_Slot is only defined when Py_LIMITED_API is set to Python 3.5.0 or 
higher.

--
assignee: christian.heimes
components: Build, Interpreter Core
keywords: 3.11regression
messages: 414473
nosy: christian.heimes, pablogsal, vstinner
priority: release blocker
severity: normal
status: open
title: Build with Py_LIMITED_API fails unknown type name ‘PyModuleDef_Slot’
type: compile error
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46894] make install DESTDIR= uses /lib/python3.10/lib-dynload out of DESTDIR

[Ned Deily]

Ned Deily  added the comment:

My apologies: I'm not sure where I got the idea you were building on macOS!

In any case, this problem has come up a few times in the past, no doubt for a 
similar reason, most recently in open issue Issue31114. I'm closing this issue 
as a duplicate of that. But be aware that Distutils is now deprecated in 
general and in the upcoming 3.11 feature release, there are major changes to 
getpath and also to begin the process of eliminating the use of Distutils when 
building Python itself, so it is unlikely that any bug fixes for this minor 
wart will be forthcoming for current releases.

But a very simple workaround should be to use --prefix=/usr/local or some other 
path within your chroot environment rather than trying to install in / of the 
chroot.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> 'make install' fails when the configure 'prefix' is '/' and 
DESTDIR is used

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[miss-islington]

Change by miss-islington :


--
pull_requests: +29785
pull_request: https://github.com/python/cpython/pull/31666

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +29784
pull_request: https://github.com/python/cpython/pull/31665

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46913] UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 4173d677a1d7c72bb32d292fbff1b4cf073d615c by Victor Stinner in 
branch 'main':
bpo-46913: Fix test_faulthandler.test_sigfpe() on UBSAN (GH-31662)
https://github.com/python/cpython/commit/4173d677a1d7c72bb32d292fbff1b4cf073d615c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46896] add support for watching writes to selected dictionaries

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Per interpreter seems best.

If someone using this feature writes a buggy implementation of a callback that 
doesn't chain reliably, that is a bug in their code and all of the fallout from 
that is "just" a bug to be fixed in said code.

Think of it like a C signal handler, the OS doesn't chain for you - it is the 
signal handler installer's responsibility to chain to the previous one.  Not an 
unusual pattern for callback hooks in C.

We already have such global C callback hooks in SetProfile and SetTrace. 
https://docs.python.org/3/c-api/init.html#profiling-and-tracing

Those don't even provide for chaining.  We could do the same here and not let a 
hook be set more than once instead of providing a Get API to allow for manual 
chaining.  That seems less useful.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is probably not a bug in python, but a change in system behaviour.

In particular, I've used the lsof command to check the open files for the 
syslogd proces on a macOS 10.13 and 12.2 system. On the former syslogd has 
/var/run/syslog open, on the latter it doesn't.

The feature to listen on this socket has been removed entirely, the 12.2 system 
no longer lists a "-bsd_in" option for syslogd in the manual page whereas it is 
both available and enabled by default on 10.13.

It might be possible to change the SyslogHandler to optionally use the syslog 
module to log, but I'm not sure it is worth doing this and that would 
definitely be a new feature.

--
resolution:  -> third party
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46841] Inline bytecode caches

[Brandt Bucher]

Change by Brandt Bucher :


--
pull_requests: +29783
pull_request: https://github.com/python/cpython/pull/31664

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46896] add support for watching writes to selected dictionaries

[Carl Meyer]

Carl Meyer  added the comment:

> Could we (or others) end up with unguarded stale caches if some buggy 
> extension forgets to chain the calls correctly?

Yes. I can really go either way on this. I initially opted for simplicity in 
the core support at the cost of asking a bit more of clients, on the theory 
that a) there are lots of ways for a buggy C extension to cause crashes with 
bad use of the C API, and b) I don't expect there to be very many extensions 
using this API. But it's also true that the consequences of a mistake here 
could be hard to debug (and easily blamed to the wrong place), and there might 
turn out to be more clients for dict-watching than I expect! If the consensus 
is to prefer CPython tracking an array of callbacks instead, we can try that.

> when you say "only one global callback": does that mean per-interpreter, or 
> per-process?

Good question! The currently proposed API suggests per-process, but it's not a 
question I've given a lot of thought to yet; open to suggestions. It seems like 
in general the preference is to avoid global state and instead tie things to an 
interpreter instance? I'll need to do a bit of research to understand exactly 
how that would affect the implementation. Doesn't seem like it should be a 
problem, though it might make the lookup at write time to see if we have a 
callback a bit slower.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44800] Code readability: rename InterpreterFrame to `_Py_framedata`

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46896] add support for watching writes to selected dictionaries

[Brandt Bucher]

Brandt Bucher  added the comment:

Also, when you say "only one global callback": does that mean per-interpreter, 
or per-process?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46896] add support for watching writes to selected dictionaries

[Brandt Bucher]

Brandt Bucher  added the comment:

> CPython will track only one global callback; it is a well-behaved client’s 
> responsibility to check if a callback is already set when setting a new one, 
> and daisy-chain to the previous callback if so.

Hm, this is a bit scary. Could we (or others) end up with unguarded stale 
caches if some buggy extension forgets to chain the calls correctly?

Core CPython seems most at risk of this, since we would most likely be 
registered first.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46756] Incorrect authorization check in urllib.request

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Pablo, we are good. The PRs were merged in open branches a while ago, and this 
was tracking security releases backports.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46896] add support for watching writes to selected dictionaries

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy: +Mark.Shannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46896] add support for watching writes to selected dictionaries

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work

[Ned Deily]

Change by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work

[Philip Bloom]

New submission from Philip Bloom :

Hello, don't file these often so apologies for any mistakes, trying to be good 
python citizen here.

Checked this on the python-list first, and others reported it as reproducible.

The issue is:
On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work.  It won't 
throw any error but the ASL/Console.App does not see any messages from it.  On 
OSX Big Sur (11.x) this works just fine with the exact same code.

I think I've cut this into a small example proof that can be run to demonstrate 
the issue.  If this is run and any of the substrings are searched for in 
Console.App when it is checking events, only the QQQ message from SysLog will 
show up.

Gonna work around it likely on our end, but hope this helps it get fixed for a 
future version.

---

import logging
from logging.handlers import SysLogHandler

root_logger = logging.getLogger()
root_logger.setLevel(logging.DEBUG)
basic_datefmt = '%m/%d/%Y %I:%M:%S %p'

syslog_format = logging.Formatter(fmt='SetupCDNGUI: %(message)s', 
datefmt=basic_datefmt)

sys_handler = SysLogHandler(address='/var/run/syslog')
#sys_handler.encodePriority(SysLogHandler.LOG_USER, SysLogHandler.LOG_ALERT)
# Tried with the above, but didn't make a difference.  Neither did not defining 
the address and letting it go to local host.
sys_handler.setFormatter(syslog_format)
root_logger.addHandler(sys_handler)


# None of these will show up.
logging.critical("CCC This is a test critical")
logging.error("EEE This is a test error")
logging.info("III Still a test")


# Comparatively this sends a message received just fine
import syslog

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

--
components: macOS
messages: 414464
nosy: ned.deily, pbloom, ronaldoussoren
priority: normal
severity: normal
status: open
title: On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46823] Add LOAD_FAST__LOAD_ATTR_INSTANCE_VALUE combined opcode

[Brandt Bucher]

Brandt Bucher  added the comment:

Reopening since this needed to be removed for 
https://github.com/python/cpython/pull/31640.

--
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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: 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

[issue46896] add support for watching writes to selected dictionaries

[Carl Meyer]

Carl Meyer  added the comment:

Thanks gps! Working on a PR and will collect pyperformance data as well.

We haven't observed any issues in Cinder with the callback just being called at 
shutdown, too, but if there are problems with that it should be possible to 
just have CPython clear the callback at shutdown time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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: 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

[issue46841] Inline bytecode caches

[Brandt Bucher]

Brandt Bucher  added the comment:


New changeset 127797f572cc7374192e415c44ea2e95b009d5ab by Brandt Bucher in 
branch 'main':
bpo-46841: Improve the failure stats for COMPARE_OP (GH-31663)
https://github.com/python/cpython/commit/127797f572cc7374192e415c44ea2e95b009d5ab


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46908] Debugger jumps to a wrong instruction in for loop

[Vedran Čačić]

Vedran Čačić  added the comment:

pdb on Py3.10.2 works fine with that code.

--
nosy: +veky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46908] Debugger jumps to a wrong instruction in for loop

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46841] Inline bytecode caches

[Brandt Bucher]

Change by Brandt Bucher :


--
pull_requests: +29782
pull_request: https://github.com/python/cpython/pull/31663

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46877] [doc] unittest.doModuleCleanups() does not exist

[Guido van Rossum]

Change by Guido van Rossum :


--
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46877] [doc] unittest.doModuleCleanups() does not exist

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset cc400585fab02994255f21ae8183d5f147236815 by Kumar Aditya in 
branch 'main':
bpo-46877: export unittest.doModuleCleanups in unittest package (#31613)
https://github.com/python/cpython/commit/cc400585fab02994255f21ae8183d5f147236815


--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com