[issue42652] recursive in finally clause cause Python interpreter crash.

[Xinmeng Xia]

Xinmeng Xia  added the comment:

Thanks for fixing this, looking forward to the new version.

Could you please kindly change the resolution into fixed and close this report?

--

___
Python tracker 

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

[issue42651] Recursive traceback crashes Python Interpreter

[Xinmeng Xia]

Xinmeng Xia  added the comment:

Thank you very much, looking forward to the new Python version.

Could you please kindly change the resolution into fixed and close this issue?

--

___
Python tracker 

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

[issue42651] Recursive traceback crashes Python Interpreter

[Ronald Oussoren]

Change by Ronald Oussoren :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> crash with unbounded recursion in except statement

___
Python tracker 

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

[issue42652] recursive in finally clause cause Python interpreter crash.

[Ronald Oussoren]

Change by Ronald Oussoren :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> crash with unbounded recursion in except statement

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I just noticed that "while True:" is now compiled to NOP. It is clearly a 
regression which affects performance.

--

___
Python tracker 

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

[issue19733] Setting image parameter of a button crashes with Cocoa Tk

[Ronald Oussoren]

Change by Ronald Oussoren :


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

[issue41443] some test cases in test_posix.py fail if some os attributes are not supported

[Peixing Xin]

Change by Peixing Xin :


--
pull_requests: +22745
pull_request: https://github.com/python/cpython/pull/23886

___
Python tracker 

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

[issue31904] Python should support VxWorks RTOS

[Peixing Xin]

Change by Peixing Xin :


--
pull_requests: +22746
pull_request: https://github.com/python/cpython/pull/23886

___
Python tracker 

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

[issue42712] Segmentation fault in running ast.literal_eval() with large expression size.

[Xinmeng Xia]

New submission from Xinmeng Xia :

Calling function ast.literal_eval() with large size can cause a segmentation 
fault in Python 3.5 -3.10. Please check the following two examples. The example 
1 works as expected, while the second one triggers segmentation fault on Python 
3.5,3.6,3.7,3.8,3.9,3.10. The primary difference between these two examples lay 
on the value of "n".


Example 1: 
= 
import ast
mylist = []
n = 10
print(ast.literal_eval("mylist"+"+mylist"*n))
==

The actual output: value Error on Python 3.5,3.7,3.8,3.9,3.10, Recursive Error 
on Python 3.6 (as expected)



Example 2:
===
import ast
mylist = []
n = 100
print(ast.literal_eval("mylist"+"+mylist"*n))
===

The actual output: segmentation fault on Python 3.5 - 3.10 (not as expected)


My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

--
components: Interpreter Core
messages: 383577
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running ast.literal_eval() with large expression 
size.
type: crash
versions: Python 3.10, Python 3.6, 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

[issue42713] Segmentation fault in running eval() with large expression size.

[Xinmeng Xia]

New submission from Xinmeng Xia :

Calling function eval() with large size can cause a segmentation fault in 
Python 3.7 -3.10. Please check the following two examples. The example 1 works 
as expected, while the second one triggers segmentation fault on Python 
3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the 
value of "n".

Example 1:
=
mylist = []
n = 10
print(eval("mylist"+"+mylist"*n))
==

The actual output: Recursion Error on Python 3.5-3.10 (as expected)




Example 2:
===
mylist = []
n = 100
print(eval("mylist"+"+mylist"*n))
===

The actual output: Recursive Error on Python 3.5, 3.6 (as expected),  
segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected)



My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

--
components: Interpreter Core
messages: 383578
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running eval() with large expression size.
type: crash
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

[issue42714] Segmentation fault in running compile() with large expression size.

[Xinmeng Xia]

New submission from Xinmeng Xia :

Calling function compile() with large size can cause a segmentation fault in 
Python 3.7 -3.10. Please check the following two examples. The example 1 works 
as expected, while the second one triggers segmentation fault on Python 
3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the 
value of "n".   


Example 1:
=
mylist = []
n = 10
print(compile("mylist"+"+mylist"*n,'','single'))
==

The actual output: Recursion Error on Python 3.5-3.10 (as expected)




Example 2:
=
mylist = []
n = 100
print(compile("mylist"+"+mylist"*n,'','single'))
===

The actual output: Recursive Error on Python 3.5, 3.6 (as expected),  
segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected)




My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

--
components: Interpreter Core
messages: 383579
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running compile() with large expression size.
type: crash
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

[issue42715] Segmentation fault in running exec() with large expression size.

[Xinmeng Xia]

New submission from Xinmeng Xia :

Calling function exec() with large size can cause a segmentation fault in 
Python 3.7 -3.10. Please check the following two examples. The example 1 works 
as expected, while the second one triggers segmentation fault on Python 
3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the 
value of "n".   




Example 1:
=
mylist = []
n = 10
print(exec("mylist"+"+mylist"*n))
==

The actual output: Recursion Error on Python 3.5-3.10 (as expected)



Example 2:
===
mylist = []
n = 100
print(exec("mylist"+"+mylist"*n))
===

The actual output: Recursive Error on Python 3.5, 3.6 (as expected),  
segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected)


My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

--
components: Interpreter Core
messages: 383580
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running exec() with large expression size.
type: crash
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

[issue42716] Segmentation fault in running ast.parse() with large expression size.

[Xinmeng Xia]

New submission from Xinmeng Xia :

Calling function ast.parse() with large size can cause a segmentation fault in 
Python 3.5 -3.10. Please check the following two examples. The example 1 works 
as expected, while the second one triggers segmentation fault on Python 
3.5,3.6,3.7,3.8,3.9,3.10. The primary difference between these two examples lay 
on the value of "n".



Example 1:
=
import ast
mylist = []
n = 10
print(ast.parse("mylist"+"+mylist"*n))
==

The actual output: AST nodes on Python 3.5-3.10 (as expected)
# <_ast.Module object at 0x7f78d7b672e8>
 


Example 2:
===
import ast
mylist = []
n = 100
print(ast.parse("mylist"+"+mylist"*n))
# <_ast.Module object at 0x7f78d7b672e8>
===

The actual output: segmentation fault on Python 3.5 - 3.10 (not as expected)




My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

--
components: Interpreter Core
messages: 383581
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running ast.parse() with large expression size.
type: crash
versions: Python 3.10, Python 3.6, 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

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

[Xinmeng Xia]

New submission from Xinmeng Xia :

The following program can work well in Python 2. However it crashes in Python 
3( 3.6-3.10 ) with the following error messages.
Program:

import sys,time, threading

class test:
def test(self):
pass


class test1:
def run(self):
for i in range(0,1000):
connection = test()
sys.stderr.write(' =_= ')


def testrun():
client = test1()
thread = threading.Thread(target=client.run, args=())
thread.setDaemon(True)
thread.start()

time.sleep(0.1)

testrun()


Error message:
--

=_=  =_=  =_=  =_=  =_=  ..  =_=  =_=  =_=  =_= 
Fatal Python error: _enter_buffered_busy: could not acquire lock for 
<_io.BufferedWriter name=''> at interpreter shutdown, possibly due to 
daemon threads
Python runtime state: finalizing (tstate=0xd0c180)

Current thread 0x7f08a638f700 (most recent call first):

Aborted (core dumped)
--

When I remove "time.sleep(0.1)" or  "thread.setDaemon(True)" or 
"sys.stderr.write(' =_= ')" or "for i in range(0,1000)":, the python 
interpreter seems to work well.

--
components: Interpreter Core
messages: 383582
nosy: xxm
priority: normal
severity: normal
status: open
title: The python interpreter crashed with "_enter_buffered_busy"
type: crash
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

[issue42688] ctypes memory error on Apple Silicon with external libffi

[miss-islington]

miss-islington  added the comment:


New changeset b3c77ecbbe0ad3e3cc6dbd885792203e9e6ec858 by erykoff in branch 
'master':
bpo-42688: Fix ffi alloc/free when using external libffi on macos (GH-23868)
https://github.com/python/cpython/commit/b3c77ecbbe0ad3e3cc6dbd885792203e9e6ec858


--
nosy: +miss-islington

___
Python tracker 

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

[issue42688] ctypes memory error on Apple Silicon with external libffi

[miss-islington]

Change by miss-islington :


--
pull_requests: +22747
pull_request: https://github.com/python/cpython/pull/23888

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Mark Shannon]

Mark Shannon  added the comment:

What is the problem with NOPs?
If there are performance regressions in real code, then that needs to be 
addressed. 
If only in a few toy examples, then that is (IMO) a price worth paying for 
predictable debugging and profiling.

Raymond:
   Effectively it does cease to exist. A NOP in the bytecode, except maybe in 
the tightest of loops, is going to be impossible to detect without inspecting 
the bytecode.

Serhiy:
   The NOP is outside of the loop, so won't slow down the loop.

--

___
Python tracker 

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

[issue42718] Allow zero-width entries in code.co_lines()

[Mark Shannon]

New submission from Mark Shannon :

While the impact of making `if 0` and `while True` appear when tracing can be 
mitigated, the impact of `continue` is more of a concern.

The following loop:

while True:
if test:
continue
rest

PEP 626 requires that the `continue` is traced, and continue can occur once per 
iteration. So inserting a NOP for a continue will have a measurable impact on 
performance.

In some cases the NOP can be folded into the preceding or following bytecode, 
but often it cannot because the code is both branchy and spread across several 
lines.

If PEP 626 allowed zero-width entries in the line number table, then any 
remaining NOPs could be eliminated in the assembler, at the cost of a little 
additional complexity in `maybe_call_line_trace()`

--
assignee: Mark.Shannon
components: Interpreter Core
messages: 383585
nosy: Mark.Shannon, pablogsal, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow zero-width entries in code.co_lines()
type: performance
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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Ned Batchelder]

Ned Batchelder  added the comment:

Mark said:

> An optimization (CS not math) is a change to the program such that it has the 
> same effect, according to the language spec, but improves some aspect of the 
> behavior, such as run time or memory use.
> 
> Any transformation that changes the effect of the program is not an 
> optimization.
> 
> You shouldn't be able to tell, without timing the program (or measuring 
> memory use, observing race conditions, etc.) whether optimizations are turned 
> on or not.

It's not that simple. Many aspects of the program can be observed, and 
coverage.py observes them and reports on them.

Coverage.py reports on branch coverage by tracking pairs of line numbers: in 
the trace function, the last line number is remembered, then paired with the 
current line number to note how execution moved from line to line.  This is an 
observable behavior of the program.  The optimization of removing jumps to 
jumps changes this observable behavior.

Here is a bug report against coverage.py that relates to this: 
https://github.com/nedbat/coveragepy/issues/1025

To reproduce this in the small, here is bug1025.py:

nums = [1,2,3,4,5,6,7,8]# line 1
for num in nums:# line 2
if num % 2 == 0:# line 3
if num % 4 == 0:# line 4
print(num)  # line 5
continue# line 6
print(-num) # line 7

Here is branch_trace.py:

import sys

pairs = set()
last = -1

def trace(frame, event, arg):
global last
if event == "line":
this = frame.f_lineno
pairs.add((last, this))
last = this
return trace

code = open(sys.argv[1]).read()
sys.settrace(trace)
exec(code)
print(sorted(pairs))

Running "python branch_trace.py bug1025.py" produces:

-1
-3
4
-5
-7
8
[(-1, 1), (1, 2), (2, 3), (3, 4), (3, 7), (4, 2), (4, 5), (5, 6), (6, 2), 
(7, 2)]

Conceptually, executing bug1025.py should sometimes jump from line 4 to line 6. 
When line 4 is false, execution moves to the continue and then to the top of 
the for loop.  But CPython optimizes away the jump to a jump, so the pair (4, 
6) never appears in our trace output.  The result is that coverage.py thinks 
there is a branch that could have occurred, but was never observed during the 
run.  It reports this as a missed branch.

Coverage.py currently deals with these sorts of issues by understanding the 
kinds of optimizations that can occur, and taking them into account when 
figuring "what could have happened during execution". Currently, it does not 
understand the jump-to-jump optimizations, which is why bug 1025 happens.

This pairing of line numbers doesn't relate specifically to the  "if 0:" 
optimizations that this issue is about, but this is where the observability 
point was raised, so I thought I would discuss it here.  As I said earlier, 
this probably should be worked out in a better forum.

This is already long, so I'm not sure what else to say.  Optimizations 
complicate things for tools that want to analyze code and help people reason 
about code.  You can't simply say, "optimizations should not be observable."  
They are observable.

--

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Ned Batchelder]

Change by Ned Batchelder :


--
nosy: +pablogsal

___
Python tracker 

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

[issue28964] AST literal_eval exceptions provide no information about line number

[Batuhan Taskaya]

Batuhan Taskaya  added the comment:

I'm +0 on this (even though we only had 2 users wanting this, the 
implementation seems very trivial). @serhiy.storchaka, @pablogsal any opinions?

--
keywords: +gsoc -patch
nosy: +pablogsal

___
Python tracker 

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

[issue28964] AST literal_eval exceptions provide no information about line number

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
keywords: +patch -gsoc

___
Python tracker 

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

[issue42707] Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP

[Eryk Sun]

Eryk Sun  added the comment:

> I understand Python should be using reading the current CP (from 
> GetConsoleOutputCP
> or using the default OEM CP, and not assuming ANSI CP for stdio

A while ago I analyzed text encodings used by many of the legacy CLI programs 
in Windows. Some programs hard code using either the ANSI or OEM code page, and 
others use either the console's current input code page or its current output 
code page. In light of the inconsistencies, I think defaulting to ANSI for 
non-console standard I/O is fine.

> There's an IO codepage set on Windows consoles (`chcp` for cmd, 
> `[Console]::InputEncoding; [Console]::OutputEncoding` for PowerShell ;

The CMD shell is a Unicode (UTF-16) application, i.e. it calls wide-character 
system and console I/O functions such as ReadConsoleW() and WriteConsoleW(). It 
still uses the console output code page, but as a kind of locale encoding. For 
example, CMD uses the *output* code page when reading a batch file as well as 
when reading output from an external command in a `FOR /F` loop. If Python were 
only concerned with satisfying a `FOR /F` loop in CMD, then it would be 
reasonable to make stdout default to the console output code page. But 
"more.com" and "find.exe" are commonly used as well, and they decode piped 
input using the console *input* code page. Other commands such as "findstr.exe" 
use OEM.

PowerShell adds a spin to this problem. In CMD, piping bytes between two 
processes doesn't actively involve the shell. It just creates an anonymous 
pipe, with each process connected to either end. In contrast, PowerShell 
injects itself as a middle man. For example, piping between "python.exe" and 
"more.com" is implemented as a pipe from "python.exe" to PowerShell and a 
separate pipe from PowerShell to "more.com". In between, PowerShell decodes the 
output from "python.exe" using its current output encoding and then re-encodes 
it using its current input encoding before writing to "more.com".

> # If we adjust cmd CP, it's fine too:
> L:\Cop>chcp 1252
> Page de codes active : 1252
> L:\Cop>py testcp.py | more
> é

In this case, the ANSI code-page encoded output from Python is written to a 
pipe that's read directly by "more.com". In turn, "more.com" decodes the input 
bytes using the console input code page before writing UTF-16 text to the 
console via WriteConsoleW(). 

To make Python use the console input code page for standard I/O, query the code 
page via "chcp.com", and set PYTHONIOENCODING. For example:

C:\>chcp
Active code page: 437
C:\>set PYTHONIOENCODING=cp437
C:\>py -c "print('é')" | more
é

It would be convenient to support encodings that are based on the current 
console code pages, maybe named "conin" and "conout", based on GetConsoleCP() 
and GetConsoleOutputCP(). For example:

C:\>set PYTHONIOENCODING=conin

They could default to the process active code page from GetACP() when there's 
no console. "ansi" and "oem" are already supported, so all four of the common 
encoding abstractions would be supported.

> when there's redirection or piping, encoding falls back to ANSI CP 
> (from config_get_locale_encoding).

The default encoding for files is locale.getpreferredencoding(), unless UTF-8 
mode is enabled. In Windows, this is the process active code page, as returned 
by WinAPI GetACP(). By default, this is the system ANSI code page.

Standard I/O isn't excepted from this, unless either PYTHONIOENCODING is set or 
it's a console device file. The default, non-legacy behavior for console files 
is to use UTF-8 at the buffer and raw I/O level. Internally, Python uses the 
wide-character console I/O functions ReadConsoleW() and WriteConsoleW(), with 
UTF-16 encoded text.

Windows 10 allows setting the system ANSI code page to UTF-8. It also allows an 
application to override its active code page to UTF-8, but that's not easy to 
change. It requires adding an "activeCodePage" setting to the manifest that's 
embedded in the executable, which can be done using the manifest tool, "mt.exe".

--
nosy: +eryksun

___
Python tracker 

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

[issue42718] Allow zero-width entries in code.co_lines()

[Mark Shannon]

Change by Mark Shannon :


--
resolution:  -> fixed
stage: needs patch -> 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

[issue28964] AST literal_eval exceptions provide no information about line number

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

This is a recurring feature request (I have heard people asking for this a 
couple of times) and is simple enough to do, so I am fine with this. Unless 
Serhiy has some concern, I would go forward :)

--

___
Python tracker 

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

[issue42719] Eliminate NOPs in the assembler, by emitting zero-width entries in the line number table

[Mark Shannon]

New submission from Mark Shannon :

This will require a change to the internal line number table format.

PEP 626 requires all lines are traced, which makes handling of 'continue' and 
other jump-to-jumps inefficient if spread across multiple lines.

In 3.9 many jump-to-jumps were eliminated, but PEP 626 requires that many are 
converted to a NOP. Zero-width line number table entries will allow us to 
eliminate most, if not all, remaining NOPs in the assembler.

--
assignee: Mark.Shannon
components: Interpreter Core
messages: 383590
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate NOPs in the assembler, by emitting zero-width entries in the 
line number table
type: performance
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

[issue38946] IDLE on macOS 10.15 Catalina does not open double-clicked files if app already launched

[Alfie Stoppani]

Alfie Stoppani  added the comment:

Yep, me too. It's very annoying indeed.

--
nosy: +alftheelf

___
Python tracker 

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

[issue42712] Segmentation fault in running ast.literal_eval() with large expression size.

[Steve Stagg]

Steve Stagg  added the comment:

Likely duplicate of Issue42609, Probably fixed by bpo-42609

--
nosy: +stestagg

___
Python tracker 

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

[issue27820] Possible bug in smtplib when initial_response_ok=False

[Rahul Kumaresan]

Change by Rahul Kumaresan :


--
nosy: +rahul-kumi

___
Python tracker 

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

[issue29860] smtplib.py doesn't capitalize EHLO.

[Rahul Kumaresan]

Change by Rahul Kumaresan :


--
nosy: +rahul-kumi

___
Python tracker 

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

[issue38946] IDLE on macOS 10.15 Catalina does not open double-clicked files if app already launched

[Terry J. Reedy]

Change by Terry J. Reedy :


--
components: +Tkinter

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Mark Shannon]

Mark Shannon  added the comment:

Ned, I agree that up until 3.9, it is wasn't that simple.
But from 3.10 onward, it should be that simple.
That's the point of PEP 626.

If a transformation changes observable behavior within the scope of language 
specification, then it is not an optimization but a bug.

Up to 3.9, the language did not specify the behavior of sys.settrace w.r.t. 
line numbers, so coverage.py had to second guess what the bytecode optimizer 
was doing. 

In 3.10 onwards, the behavior of sys.settrace w.r.t. line numbers is part of 
the language spec. The optimizer cannot change it, and coverage.py should not 
need care what the optimizer does.

If you can observe the effect of the optimizer, w.r.t. line numbers, then it's 
a bug.

(According to that definition, there are still bugs in the optimizer relating 
to jumps-to-jumps. I plan to fix them)

--

___
Python tracker 

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

[issue35783] incorrect example of fetching messages in imaplib documentation

[Rahul Kumaresan]

Change by Rahul Kumaresan :


--
nosy: +rahul-kumi

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Ned Batchelder]

Ned Batchelder  added the comment:

> According to that definition, there are still bugs in the optimizer relating 
> to jumps-to-jumps. I plan to fix them

Can you say more about that? What is the bug? How will you fix it?

--

___
Python tracker 

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

[issue19561] request to reopen Issue837046 - pyport.h redeclares gethostname() if SOLARIS is defined

[Jakub Kulik]

Change by Jakub Kulik :


--
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3

___
Python tracker 

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

[issue41843] Reenable sendfile in shutil.copyfile() on Solaris

[Jakub Kulik]

Change by Jakub Kulik :


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

___
Python tracker 

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

[issue29030] argparse: choices override default metavar

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56 by Raymond Hettinger in 
branch 'master':
bpo-29030: Document interaction between *choices* and *metavar*. (GH-23884)
https://github.com/python/cpython/commit/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56


--

___
Python tracker 

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

[issue29030] argparse: choices override default metavar

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +22749
pull_request: https://github.com/python/cpython/pull/23894

___
Python tracker 

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

[issue42711] lru_cache and NotImplemented

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> has the potential to fill the LRU cache with calls that
> will in ultimately result in errors

How would a call result in an error?  The worst that can happen is a cache miss 
and the underlying function gets called.


> Change `functools.lru_cache` not cache calls that 
> result in `NotImplemented`.

That would be a backwards incompatible change.


> Allow a user to easily extend `functools.lru_cache`

The implementation is intentionally closed off to support thread-safety, having 
a C implementation, ease of use, and making it performant.  

We've provided OrderedDict to make it relatively easy to roll your own cache 
variants.  Essentially the only algorithmically interesting part of the 
lru_cache is the linked list. OrderedDict has that logic already built in (the 
move_to_end() method does the equivalent of the linked list update).


> Add the ability to *throw* `NotImplemented` in binary dunder
> methods so the function call does not complete. This would 
> work exactly like returning `NotImplemented` and be handled 
> by the runtime.

Deep changes to the language would require a PEP.

> And my current solution...
> 4. Copy-paste `functools.lru_cache` 

The usual technique is to cache only what you want cached.  

Consider factoring-out the expensive logic rather than caching the 
NotImplemented logic:

def __add__(self, other):
if not isinstance(other, type(self)):
return NotImplemented
self._expensive_method(other)

@lru_cache
def _expensive_method(self, other):
...

--
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low
type: performance -> behavior
versions:  -Python 3.6, 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

[issue29030] argparse: choices override default metavar

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 4ec2149708c7c06ebeccc27e28e2bbc51c4abeca by Miss Islington (bot) 
in branch '3.9':
bpo-29030: Document interaction between *choices* and *metavar*. (GH-23884) 
(GH-23894)
https://github.com/python/cpython/commit/4ec2149708c7c06ebeccc27e28e2bbc51c4abeca


--

___
Python tracker 

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

[issue29030] argparse: choices override default metavar

[Raymond Hettinger]

Change by Raymond Hettinger :


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

[issue42696] Duplicated unused bytecodes at end of function

[Ned Batchelder]

Ned Batchelder  added the comment:

This isn't a problem for me.  I noticed it and figured I'd mention it.

--

___
Python tracker 

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

[issue42720] << operator has a bug

[Nandish]

New submission from Nandish :

I verified the following on both Python 2.7 and Python 3.8

I did print(100<<3) Converting 100 to Binary gives 1100100. What I did is I 
droped the first 3 bits and added 3 bits with the value '0' at the end. So it 
should result as 010, and I converted this to Decimal and the answer was 32.

For my suprise when I executed print(100<<3) the answer was 800. I was puzzled. 
I converted 800 to Binary to check whats going on. And this is what I got 
110010.

If you see how 800 was Python answer, they did not shift or drop the first 3 
bits but they added value '0' to last 3 bits.

Where as print(100>>3) , worked perfect. I did manual calculation and cheked 
the print result from python. It worked correctly. Dropped last 3 bits and 
added value '0' to first 3 bits.

Looks like (100<<3) , left shift operator has a bug on Python.

--
messages: 383599
nosy: Nandish
priority: normal
severity: normal
status: open
title: << operator has a bug
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue25246] Alternative algorithm for deque_remove()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Am closing this one because it isn't worth an API change.  The remove() method 
is little used and to the extent people do use it, they expect it to work like 
list.remove().  The latter never raises a RuntimeError.

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

[issue42712] Segmentation fault in running ast.literal_eval() with large expression size.

[Steve Stagg]

Steve Stagg  added the comment:

Confirmed fixed by https://github.com/python/cpython/pull/23744:

Traceback (most recent call last):
  File "/home/sstagg/tmp/fuzztest/cpython/../test.py", line 4, in 
print(ast.literal_eval("mylist"+"+mylist"*n))
  File "/home/sstagg/tmp/fuzztest/prefix/lib/python3.10/ast.py", line 62, in 
literal_eval
node_or_string = parse(node_or_string.lstrip(" \t"), mode='eval')
  File "/home/sstagg/tmp/fuzztest/prefix/lib/python3.10/ast.py", line 50, in 
parse
return compile(source, filename, mode, flags,
RecursionError: maximum recursion depth exceeded during compilation

--

___
Python tracker 

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

[issue42696] Duplicated unused bytecodes at end of function

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Is this a problem in practice?

It's just a hint that code generation has imperfections.

>From a teacher's or author's point of view, it is something we have to explain 
>away when demonstrating dis().  It leaves the impression that Python is kludgy.

--

___
Python tracker 

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

[issue42716] Segmentation fault in running ast.parse() with large expression size.

[Steve Stagg]

Steve Stagg  added the comment:

PR: https://github.com/python/cpython/pull/23744 stops this from segfaulting.  
It does however raise a RecursionError:

RecursionError: maximum recursion depth exceeded during compilation

As per https://bugs.python.org/issue42609#msg382910, Serhiy implies that the 
new recursion error is probably expected and acceptable.

--
nosy: +serhiy.storchaka, stestagg

___
Python tracker 

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

[issue42715] Segmentation fault in running exec() with large expression size.

[Steve Stagg]

Steve Stagg  added the comment:

As with the other issues, the underlying segfault is fixed in
PR: https://github.com/python/cpython/pull/23744. It does however raise a 
RecursionError:

RecursionError: maximum recursion depth exceeded during compilation

As per https://bugs.python.org/issue42609#msg382910, Serhiy implies that the 
new recursion error is probably expected and acceptable.

--
nosy: +stestagg

___
Python tracker 

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

[issue42720] << operator has a bug

[Eric V. Smith]

Eric V. Smith  added the comment:

Why do you think the first 3 bits should be dropped? That's not the documented 
behavior of <<.

--
nosy: +eric.smith

___
Python tracker 

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

[issue42714] Segmentation fault in running compile() with large expression size.

[Steve Stagg]

Steve Stagg  added the comment:

As with the other ones, 
PR: https://github.com/python/cpython/pull/23744 stops this from segfaulting.  
It does however raise a RecursionError:

RecursionError: maximum recursion depth exceeded during compilation

As per https://bugs.python.org/issue42609#msg382910, Serhiy implies that the 
new recursion error is probably expected and acceptable.

--
nosy: +stestagg

___
Python tracker 

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

[issue42720] << operator has a bug

[Nandish]

Nandish  added the comment:

I took print(100>>3), I dropped last 3 bits and added value ‘0’ to first 3
bits. Both manual calculation and python result was correct.

How can << shit operator and >> shit operator work differently , with
different logic ?

Thanks
Nandish

On Wed, Dec 23, 2020 at 12:54 AM Eric V. Smith 
wrote:

>
> Eric V. Smith  added the comment:
>
> Why do you think the first 3 bits should be dropped? That's not the
> documented behavior of <<.
>
> --
> nosy: +eric.smith
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue42720] << operator has a bug

[Eric V. Smith]

Eric V. Smith  added the comment:

That's not how they're defined. From 
https://docs.python.org/3/reference/expressions.html?highlight=left%20shift#shifting-operations

"A right shift by n bits is defined as floor division by pow(2,n). A left shift 
by n bits is defined as multiplication with pow(2,n)."

Perhaps you are assuming that Python operates on fixed width integers, such as 
8 bit bytes? That's not true. You can think of Python integers as infinitely 
large, up to the limit of how memory you have.

Since it's working as documented, I'm going to close this.

--
resolution:  -> not a bug
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

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

[Steve Stagg]

Steve Stagg  added the comment:

Minimal test case:


import sys, threading

def run():
for i in range(1000):
sys.stderr.write(' =.= ')

if __name__ == '__main__':
threading.Thread(target=run, daemon=True).start()
===

I think this is expected behaviour.  My knowledge isn't complete here, but 
something similar to:

* During shutdown, the daemon threads are aborted
* In your example, the thread is very likely to be busy doing IO, so holding 
the io lock.
* The abort you're seeing is an explicit check/abort to avoid a deadlock 
(https://bugs.python.org/issue23309).

--
nosy: +stestagg

___
Python tracker 

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

[issue34463] Discrepancy between traceback.print_exception and sys.__excepthook__

[Tal Einat]

Tal Einat  added the comment:


New changeset 069560b1171eb6385121ff3b6331e8814a4e7454 by Irit Katriel in 
branch 'master':
bpo-34463: Make python tracebacks identical to C tracebacks for SyntaxErrors 
without a lineno (GH-23427)
https://github.com/python/cpython/commit/069560b1171eb6385121ff3b6331e8814a4e7454


--
nosy: +taleinat

___
Python tracker 

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

[issue34463] Discrepancy between traceback.print_exception and sys.__excepthook__

[miss-islington]

Change by miss-islington :


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

___
Python tracker 

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

[issue42716] Segmentation fault in running ast.parse() with large expression size.

[Steve Stagg]

Steve Stagg  added the comment:

fyi, Issue42712, Issue42712, Issue42714, Issue42715, Issue42716 all seem to be 
variants of the same underlying problem

--

___
Python tracker 

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

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

[Mark Shannon]

Change by Mark Shannon :


--
pull_requests: +22751
pull_request: https://github.com/python/cpython/pull/23896

___
Python tracker 

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

[issue42721] Using of simple dialogs without default root window

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Currently, standard message boxes in tkinter.messagebox (like showinfo() or 
askyesnocancel()) can be called without master or default root window. If 
arguments master or parent are not specified and there is no default root 
window is still created, the root window is created and set as the default root 
window. It is kept visible after closing a message box. It was done for testing 
from REPL. It affects also tkinter.colorchooser.askcolor().

The drawback is that the root window is kept visible and that it is set as the 
default root window (so following explicit calls of Tk(), with possible 
different arguments does not set the default root window).

Simple query dialogs in tkinter (like askinteger()) initially had the same 
behavior. But later it was broken, and currently they do not work if master and 
parent are not specified and the default root window is not set.

Proposed PR improves behavior of message boxes and colorchooser and restore the 
lost feature for query dialogs. Now if master and parent are not specified and 
the default root window is not set, the new temporary hidden root window is 
created, but is not set as the default root window. It will be destroyed right 
after closing the dialog, so it will not affect other widgets.

--
components: Tkinter
messages: 383612
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Using of simple dialogs without default root window
type: enhancement
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

[issue42696] Duplicated unused bytecodes at end of function

[Mark Shannon]

Mark Shannon  added the comment:

In what way is it "kludgy"?
There is a mathematical theorem that states that generated code will be 
imperfect, 
so we will have to live with that :)
https://en.wikipedia.org/wiki/Full_employment_theorem

3.10a produces more efficient bytecode than 3.9.

3.9:

  2   0 LOAD_GLOBAL  0 (range)
  2 LOAD_CONST   1 (10)
  4 CALL_FUNCTION1
  6 GET_ITER
>>8 FOR_ITER 8 (to 18)
 10 STORE_FAST   0 (i)

  3  12 POP_TOP
 14 JUMP_ABSOLUTE   18
 16 JUMP_ABSOLUTE8

  4 >>   18 LOAD_CONST   2 (17)
 20 RETURN_VALUE

3.10a:

  2   0 LOAD_GLOBAL  0 (range)
  2 LOAD_CONST   1 (10)
  4 CALL_FUNCTION1
  6 GET_ITER
  8 FOR_ITER 8 (to 18)
 10 STORE_FAST   0 (i)

  3  12 POP_TOP

  4  14 LOAD_CONST   2 (17)
 16 RETURN_VALUE
>>   18 LOAD_CONST   2 (17)
 20 RETURN_VALUE

--

___
Python tracker 

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

[issue42721] Using of simple dialogs without default root window

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Mark Shannon]

Mark Shannon  added the comment:

The fix, which explains the bug:
https://github.com/python/cpython/pull/23896

--

___
Python tracker 

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

[issue2506] Add mechanism to disable optimizations

[Mark Shannon]

Mark Shannon  added the comment:

I think this can finally be closed.
A mere 12 years after it was opened :)

PEP 626 specifies what the correct behavior is, regardless of whether 
optimizations are turned on or off, so there is no point in a no-optimize 
option.
The compiler is fast enough that it is never worth turning off, even for 
iterate development.

If the bytecode optimizer produces incorrect or inefficient code for a 
particular example, please file a bug report for that case, and assign me.

--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Ned Batchelder]

Ned Batchelder  added the comment:

Mark, I'm trying to follow along with your ideas, but it's hard to piece 
together the implications.  Is there a way to have a discussion about where you 
are headed?

https://github.com/python/cpython/pull/23896 "fixes" the jump to jump problems 
by no longer optimizing away jumps to jumps.  
https://bugs.python.org/issue42719 mentions creating zero-width entries in the 
line number table.  Does that let us get rid of jumps to jumps but still 
produce two trace events?  I'd like to understand more.

--

___
Python tracker 

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

[issue25246] Alternative algorithm for deque_remove()

[Raymond Hettinger]

Change by Raymond Hettinger :


--
pull_requests: +22753
pull_request: https://github.com/python/cpython/pull/23898

___
Python tracker 

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

[issue9694] argparse required arguments displayed under "optional arguments"

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Since this change will break tests that rely matching help output exactly, I  
would like to hear if there are any objections to replacing "optional 
arguments" with "options".

The words "switch" or "flag" don't work as well because they imply on/off and 
don't encompass option that take arguments.

--

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Mark Shannon]

Mark Shannon  added the comment:

Are you interested in the "what" or the "how"?

The "what":
PEP 626 defines what CPython must do in terms of tracing lines executed.

The "how":
Obviously, we want to execute Python as efficiently as possible.
To do so, we use a series of "peephole" optimizations that make the bytecode 
more efficient but preserve PEP 626 semantics.

The front-end of the compiler produces code that conforms to PEP 626.
The optimizer should make the bytecode faster, while still conforming to PEP 
626. Since the optimizer is inherited from 3.9, it doesn't always respect PEP 
626. I am in the process of fixing that.

If you need to know what the optimizer does, in order to correctly implement 
coverage.py, then that is a bug in the optimizer.

Zero-width entries will, in theory, allow some additional optimizations.
But probably not that much, in practice.

--

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Ned Batchelder]

Ned Batchelder  added the comment:

Specifically, for jumps to jumps, what is the plan?

--

___
Python tracker 

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

[issue34463] Discrepancy between traceback.print_exception and sys.__excepthook__

[miss-islington]

miss-islington  added the comment:


New changeset 8e5c61a075f3a60272a7dcdc48db200090d76309 by Miss Islington (bot) 
in branch '3.9':
bpo-34463: Make python tracebacks identical to C tracebacks for SyntaxErrors 
without a lineno (GH-23427)
https://github.com/python/cpython/commit/8e5c61a075f3a60272a7dcdc48db200090d76309


--

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Mark Shannon]

Mark Shannon  added the comment:

There isn't much of a plan.

https://github.com/python/cpython/pull/23896 makes the optimizer respect PEP 
626 w.r.t. jumps-to-jumps. 

>From the point of view of optimization, there is nothing special about 
>jumps-to-jumps.
Any optimization that offers a speed up is good, regardless of which language 
feature it relates to.

To be honest, bytecode optimizations are going to win us a few percent max, 
whereas speeding up the interpreter could gain us 50-100%. So I'm not going to 
worry about trivial differences.

--

___
Python tracker 

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

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Ned Batchelder]

Ned Batchelder  added the comment:

This seems like a perspective that needs a wider audience.  PEP 626 says there 
will be no performance slowdown:

> Performance Implications
> 
> In general, there should be no change in performance. When tracing,
> programs should run a little faster as the new table format can be
> designed with line number calculation speed in mind. Code with long
> sequences of pass statements will probably become a bit slower.

Now you are saying that is fine to take a small performance hit in order to 
conform to PEP 626.  

I am usually on the side of good tracing, but I imagine other people feel 
differently, that it is unacceptable to slow down all execution for sake of 
accurate tracing.  I would love to have a clear agreement before moving forward 
so that we don't have to backtrack.

--

___
Python tracker 

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

[issue34463] Discrepancy between traceback.print_exception and sys.__excepthook__

[Irit Katriel]

Change by Irit Katriel :


--
pull_requests: +22754
pull_request: https://github.com/python/cpython/pull/23899

___
Python tracker 

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

[issue42707] Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP

[Inada Naoki]

Inada Naoki  added the comment:

I think using Console codepage for stdio is better. But I am afraid about 
breaking existing code.
How about treating only UTF-8 and leave legacy environment as-is?

* When GetConsoleCP() returns CP_UTF8, use UTF-8 for stdin. Otherwise, use ANSI.
* When GetConsoleOutputCP() returns CP_UTF8, use UTF-8 for stdout. Otherwise, 
use ANSI.

This will work nice with PowerShell or cmd with `chcp 65001` in most simple 
cases.

--
nosy: +methane

___
Python tracker 

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

[issue42722] Add --debug command line option to unittest to enable post-mortem debugging

[Dominik V.]

New submission from Dominik V. :

Currently there is no option to use post-mortem debugging via `pdb`
on a `unittest` test case which fails due to an exception being leaked.

Consider the following example:

```
import unittest

def foo():
for x in [1, 2, 'oops', 4]:
print(x + 100)

class TestFoo(unittest.TestCase):
def test_foo(self):
self.assertIs(foo(), None)

if __name__ == '__main__':
unittest.main()
```

If we were calling `foo` directly we could enter post-mortem debugging via
`python -m pdb test.py`.
However since `foo` is wrapped in a test case, `unittest` eats the
exception and thus prevents post-mortem debugging.

So I propose adding a
command-line option `--debug` to unittest for running
test cases in debug mode so that post-mortem debugging can be used.

I see that some third-party distributions enable this, but since both
`unittest` and `pdb` are part of the standard library, it would
be nice if they played well together.
Plus the required methods are already in place (`TestCase.debug`
and `TestSuite.debug`).

There is also a popular StackOverflow question on this topic:
https://stackoverflow.com/questions/4398967/python-unit-testing-automatically-running-the-debugger-when-a-test-fails

--
messages: 383624
nosy: Dominik V.
priority: normal
severity: normal
status: open
title: Add --debug command line option to unittest to enable post-mortem 
debugging
type: enhancement

___
Python tracker 

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

[issue42722] Add --debug command line option to unittest to enable post-mortem debugging

[Dominik V.]

Change by Dominik V. :


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

___
Python tracker 

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

[issue42367] Restore os.makedirs ability to apply mode to all directories created

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +22756
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23901

___
Python tracker 

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

[issue42707] Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP

[Eryk Sun]

Eryk Sun  added the comment:

> How about treating only UTF-8 and leave legacy environment as-is?
> * When GetConsoleCP() returns CP_UTF8, use UTF-8 for stdin. 
> Otherwise, use ANSI.

Okay, and also when GetConsoleCP() fails because there's no console (e.g. 
python.exe w/ DETACHED_PROCESS creation flag, or pythonw.exe). 

However, using UTF-8 for the input code page is currently broken in many cases, 
so it should not be promoted as a recommended solution until Microsoft fixes 
their broken code (which should have been fixed 20 years ago; it's ridiculous). 
Legacy console applications rely on ReadFile and ReadConsoleA. Setting the 
input code page to UTF-8 is limited to reading 7-bit ASCII (ordinals 0-127). 
Other characters get converted to null bytes. For example:

>>> kernel32.SetConsoleCP(65001)
1
>>> os.read(0, 10)
ab¡¢£¤cd
b'ab\x00\x00\x00\x00cd\r\n'

--

___
Python tracker 

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

[issue42707] Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP

[Inada Naoki]

Inada Naoki  added the comment:

> Okay, and also when GetConsoleCP() fails because there's no console (e.g. 
> python.exe w/ DETACHED_PROCESS creation flag, or pythonw.exe). 

When there is no console, stdio should use the default textio encoding that is 
ANSI for now.

> However, using UTF-8 for the input code page is currently broken in many 
> cases, so it should not be promoted as a recommended solution until Microsoft 
> fixes their broken code (which should have been fixed 20 years ago; it's 
> ridiculous). Legacy console applications rely on ReadFile and ReadConsoleA. 
> Setting the input code page to UTF-8 is limited to reading 7-bit ASCII 
> (ordinals 0-127). Other characters get converted to null bytes.

Regardless when we promote it, people use `chcp 65001` in cmd and 
`[Console]::OutputEncoding = [Text.Encoding]::UTF8` in Power Shell.
In such situation, UTF-8 is the best encoding for pipes and redirected files.

--

___
Python tracker 

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

[issue9694] argparse required arguments displayed under "optional arguments"

[Eric V. Smith]

Eric V. Smith  added the comment:

I wouldn't let breaking these tests deter you from improving the output. I 
think using "options" is an improvement.

--

___
Python tracker 

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

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

[Xinmeng Xia]

Xinmeng Xia  added the comment:

Thanks for your kind explanation! Now, I have understand the causes of this 
core dump. Considering it will not cause core dump in Python 2.x, I am 
wondering should we suggest an exception to catch it rather than "core dump"?

--

___
Python tracker 

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

[issue39465] [subinterpreters] Design a subinterpreter friendly alternative to _Py_IDENTIFIER

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 52a327c1cbb86c7f2f5c460645889b23615261bf by Victor Stinner in 
branch 'master':
bpo-39465: Add pycore_atomic_funcs.h header (GH-20766)
https://github.com/python/cpython/commit/52a327c1cbb86c7f2f5c460645889b23615261bf


--

___
Python tracker 

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

[issue42707] Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP

[Eryk Sun]

Eryk Sun  added the comment:

> When there is no console, stdio should use the default textio 
> encoding that is ANSI for now.

stdin, stdout, and stderr are special and can be special cased because they're 
used implicitly for IPC. They've always been acknowledged as special by the 
existence of PYTHONIOENCODING. I think if Python is going to change its policy 
for standard I/O, along the lines of what I think you've been arguing in favor 
of for months now, it should commit to (almost) consistently using the console 
input and output code pages for the standard I/O encoding in Windows, with 
UTF-8 as the default when there is no console session, and with the exception 
that UTF-8 is used for console files. To get legacy behavior, set 
PYTHONLEGACYWINDOWSSTDIO, which will use the console code pages for console 
standard I/O and otherwise use the process active code page for standard I/O.

The default encoding for open() would still be the process active code page 
from GetACP(), and the recommendation should be for scripts to use an explicit 
`encoding`.

--

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Maybe sys.settrace() is not ultimately the best tool for coverage reporting? If 
the bytecode compiler natively supported coverage instrumentation, source 
semantics would be easier to respect. A nice implementation could use Knuth & 
Stevenson "Optimal measurement of points for program frequency counts".

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue42035] [C API] PyType_GetSlot cannot get tp_name

[hai shi]

Change by hai shi :


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

___
Python tracker 

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

[issue42693] "if 0:" lines are traced; they didn't use to be

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

If the NOP is outside of the loop, then what is the reason of adding it? You 
cannot set a breakpoint on "while True:" which stops on every iteration.

The goal "tracing every line of code" is incompatible with code optimization. 
It would be better to add a special option to produce slower bytecode for 
tracing if you want to trace every line.

--

___
Python tracker 

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

[issue15303] Minor revision to the method in Tkinter

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +22758
pull_request: https://github.com/python/cpython/pull/23904

___
Python tracker 

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

[issue42620] documentation on `getsockname()` wrong for AF_INET6

[miss-islington]

miss-islington  added the comment:


New changeset cf3565ca9a7ed0f7decd000e41fa3de400986e4d by Christian Heimes in 
branch 'master':
bpo-42620: Improve socket.getsockname doc string (GH-23742)
https://github.com/python/cpython/commit/cf3565ca9a7ed0f7decd000e41fa3de400986e4d


--
nosy: +miss-islington

___
Python tracker 

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

[issue42620] documentation on `getsockname()` wrong for AF_INET6

[miss-islington]

Change by miss-islington :


--
pull_requests: +22759
pull_request: https://github.com/python/cpython/pull/23906

___
Python tracker 

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

[issue42620] documentation on `getsockname()` wrong for AF_INET6

[miss-islington]

Change by miss-islington :


--
pull_requests: +22760
pull_request: https://github.com/python/cpython/pull/23907

___
Python tracker 

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

[issue42620] documentation on `getsockname()` wrong for AF_INET6

[miss-islington]

miss-islington  added the comment:


New changeset b20494618c6ac6ebcd354e0b16a6645fe47acbee by Miss Islington (bot) 
in branch '3.8':
bpo-42620: Improve socket.getsockname doc string (GH-23742)
https://github.com/python/cpython/commit/b20494618c6ac6ebcd354e0b16a6645fe47acbee


--

___
Python tracker 

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

[issue42620] documentation on `getsockname()` wrong for AF_INET6

[miss-islington]

miss-islington  added the comment:


New changeset 7fe7d83c26b02c8a65c8a9633cc4251f5cd97ebf by Miss Islington (bot) 
in branch '3.9':
bpo-42620: Improve socket.getsockname doc string (GH-23742)
https://github.com/python/cpython/commit/7fe7d83c26b02c8a65c8a9633cc4251f5cd97ebf


--

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[Christian Heimes]

Christian Heimes  added the comment:


New changeset 6d9ec8bbfa07161431dc6190dd0772a6fbaf7ebd by Christian Heimes in 
branch 'master':
bpo-1635741: Port resource extension module to module state (GH-23462)
https://github.com/python/cpython/commit/6d9ec8bbfa07161431dc6190dd0772a6fbaf7ebd


--

___
Python tracker 

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