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

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

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

Change by miss-islington : -- pull_requests: +22747 pull_request: https://github.com/python/cpython/pull/23888 ___ Python tracker ___

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

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

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

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,

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

Steve Stagg added the comment: Likely duplicate of Issue42609, Probably fixed by bpo-42609 -- nosy: +stestagg ___ Python tracker ___

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

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

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

Change by Ned Batchelder : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

Change by Mark Shannon : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___

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

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,

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

Alfie Stoppani added the comment: Yep, me too. It's very annoying indeed. -- nosy: +alftheelf ___ Python tracker ___ ___

[issue27820] Possible bug in smtplib when initial_response_ok=False

Change by Rahul Kumaresan : -- nosy: +rahul-kumi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

Change by Batuhan Taskaya : -- keywords: +patch -gsoc ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

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

[issue42651] Recursive traceback crashes Python Interpreter

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

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

Change by Peixing Xin : -- pull_requests: +22745 pull_request: https://github.com/python/cpython/pull/23886 ___ Python tracker ___

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

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

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

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

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

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.

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

Change by Ronald Oussoren : -- resolution: -> fixed stage: -> resolved status: open -> closed superseder: -> crash with unbounded recursion in except statement ___ Python tracker

[issue42651] Recursive traceback crashes Python Interpreter

Change by Ronald Oussoren : -- resolution: -> fixed stage: -> resolved status: open -> closed superseder: -> crash with unbounded recursion in except statement ___ Python tracker

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

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

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

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 ___

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

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

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

Change by Ronald Oussoren : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue31904] Python should support VxWorks RTOS

Change by Peixing Xin : -- pull_requests: +22746 pull_request: https://github.com/python/cpython/pull/23886 ___ Python tracker ___

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

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

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

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

[issue29030] argparse: choices override default metavar

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

[issue29030] argparse: choices override default metavar

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)

[issue29030] argparse: choices override default metavar

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

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

Change by Rahul Kumaresan : -- nosy: +rahul-kumi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35783] incorrect example of fetching messages in imaplib documentation

Change by Rahul Kumaresan : -- nosy: +rahul-kumi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Jakub Kulik : -- keywords: +patch pull_requests: +22748 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23893 ___ Python tracker ___

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

Change by Jakub Kulik : -- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3 ___ Python tracker ___ ___

[issue29030] argparse: choices override default metavar

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

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

Change by Terry J. Reedy : -- components: +Tkinter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

[issue42711] lru_cache and NotImplemented

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

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

Change by Mark Shannon : -- pull_requests: +22751 pull_request: https://github.com/python/cpython/pull/23896 ___ Python tracker ___

[issue42721] Using of simple dialogs without default root window

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

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

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

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

Ned Batchelder added the comment: Specifically, for jumps to jumps, what is the plan? -- ___ Python tracker ___ ___

[issue42696] Duplicated unused bytecodes at end of function

Ned Batchelder added the comment: This isn't a problem for me. I noticed it and figured I'd mention it. -- ___ Python tracker ___

[issue25246] Alternative algorithm for deque_remove()

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

[issue42696] Duplicated unused bytecodes at end of function

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.

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

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

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

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

[issue42696] Duplicated unused bytecodes at end of function

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:

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

Mark Shannon added the comment: The fix, which explains the bug: https://github.com/python/cpython/pull/23896 -- ___ Python tracker ___

[issue25246] Alternative algorithm for deque_remove()

Change by Raymond Hettinger : -- pull_requests: +22753 pull_request: https://github.com/python/cpython/pull/23898 ___ Python tracker ___

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

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

[issue42720] << operator has a bug

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

[issue42721] Using of simple dialogs without default root window

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +22752 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23897 ___ Python tracker

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

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

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

[issue42720] << operator has a bug

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 ___

[issue42720] << operator has a bug

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

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

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

[issue42720] << operator has a bug

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

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

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)

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

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

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

Steve Stagg added the comment: fyi, Issue42712, Issue42712, Issue42714, Issue42715, Issue42716 all seem to be variants of the same underlying problem -- ___ Python tracker

[issue2506] Add mechanism to disable optimizations

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

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

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"

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

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)

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

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

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

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

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

Change by Dominik V. : -- keywords: +patch pull_requests: +22755 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23900 ___ Python tracker ___

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

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Irit Katriel : -- pull_requests: +22754 pull_request: https://github.com/python/cpython/pull/23899 ___ Python tracker ___

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

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

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

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

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

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)

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

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

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

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

[issue42717] The python interpreter crashed with "_enter_buffered_busy"

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

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

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 ___

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

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

[issue42035] [C API] PyType_GetSlot cannot get tp_name

Change by hai shi : -- keywords: +patch pull_requests: +22757 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23903 ___ Python tracker ___

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

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

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

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

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

Change by miss-islington : -- pull_requests: +22759 pull_request: https://github.com/python/cpython/pull/23906 ___ Python tracker ___

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

Change by miss-islington : -- pull_requests: +22760 pull_request: https://github.com/python/cpython/pull/23907 ___ Python tracker ___

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

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

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

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

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

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

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

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

[issue15303] Minor revision to the method in Tkinter

Change by Serhiy Storchaka : -- pull_requests: +22758 pull_request: https://github.com/python/cpython/pull/23904 ___ Python tracker ___

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

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: