[issue45289] test_dbm and test_dbm_ndbm segfaults in M1 Mac

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> Typing `import sys; sys.exit()` every time I want to test something 
> quick on the REPL is awful UX.

It truly is awful. So why do you do it that way?

There are at least four other ways to cleanly exit the REPL.

1. raise SystemExit

2. exit()

3. quit()

4. Ctrl-D (posix systems) or Ctrl-Z ENTER (Windows systems)

Even if you are running the REPL without the site module (so that exit 
and quit are not available) the import sys solution is surely the worst 
of the lot, UX-wise.

--

___
Python tracker 

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

[issue45290] test_multiprocessing_pool_circular_import fails in M1 mac

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Seems that the issue went away when configuring the maxfiles with

$ launchctl limit maxfiles

instead of with "ulimit -n"

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

___
Python tracker 

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

[issue45290] test_multiprocessing_pool_circular_import fails in M1 mac

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> ulimit -n 1000

If i do this, the test hangs some times instead of crashing

--

___
Python tracker 

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

[issue45249] Update doctect SyntaxErrors for location range

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Terry: I got it mostly working using your 2nd suggestion, I will do some 
testing and should be able to put up a PR in the next couple of days. Thanks 
for looking at this and explaining!

--

___
Python tracker 

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

[issue45290] test_multiprocessing_pool_circular_import fails in M1 mac

[Ned Deily]

Ned Deily  added the comment:

As a first step, try adding:

ulimit -n 1000

to the buildbot test step.

--

___
Python tracker 

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

[issue45290] test_multiprocessing_pool_circular_import fails in M1 mac

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

The same test sometimes hangs forever

--

___
Python tracker 

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

[issue45026] More compact range iterator

[Dennis Sweeney]

Dennis Sweeney  added the comment:

I did more benchmarks on my Windows laptop, and it seems the difference goes 
away after using PGO.

The benchmarking program:

#

from pyperf import Runner

runner = Runner()

for n in [10, 100, 1000, 10_000, 100_000]:
runner.timeit(f"for i in range({n}): pass",
stmt=f"for i in range({n}): pass")

runner.timeit(f"for i in it_{n}: pass",
setup=f"it = iter(range({n}))",
stmt="for i in it: pass")

runner.timeit(f"deque(it_{n})",
  setup=(f"from collections import deque; "
 f"it = iter(range({n}))"),
  stmt="deque(it, maxlen=0)")

runner.timeit(f"list(iter(range({n})))",
  stmt=f"list(iter(range({n})))")

###

The results (without PGO):

PS C:\Users\sween\Source\Repos\cpython2\cpython> .\python.bat -m pyperf 
compare_to .\20e3149c175a24466c7d1c352f8ff2c11effc489.json 
.\cffa90a8b0057d7e7456571045f2fb7b9ceb426f.json -G
Running Release|x64 interpreter...
Slower (15):
- list(iter(range(100))): 741 ns +- 13 ns -> 836 ns +- 11 ns: 1.13x slower
- for i in range(10): pass: 2.05 ms +- 0.05 ms -> 2.26 ms +- 0.06 ms: 1.10x 
slower
- list(iter(range(1000))): 12.2 us +- 0.1 us -> 13.2 us +- 0.2 us: 1.08x slower
- for i in range(1): pass: 203 us +- 4 us -> 219 us +- 4 us: 1.08x slower
- for i in range(100): pass: 1.18 us +- 0.02 us -> 1.27 us +- 0.03 us: 1.08x 
slower
- for i in range(1000): pass: 18.1 us +- 0.3 us -> 19.5 us +- 0.3 us: 1.07x 
slower
- list(iter(range(1))): 145 us +- 7 us -> 152 us +- 2 us: 1.05x slower
- list(iter(range(10))): 1.98 ms +- 0.06 ms -> 2.06 ms +- 0.05 ms: 1.04x 
slower
- for i in range(10): pass: 265 ns +- 9 ns -> 272 ns +- 8 ns: 1.03x slower
- deque(it_1000): 324 ns +- 4 ns -> 332 ns +- 8 ns: 1.02x slower
- deque(it_10): 327 ns +- 5 ns -> 333 ns +- 7 ns: 1.02x slower
- list(iter(range(10))): 357 ns +- 7 ns -> 363 ns +- 3 ns: 1.02x slower
- deque(it_10): 325 ns +- 5 ns -> 330 ns +- 5 ns: 1.01x slower
- deque(it_100): 325 ns +- 6 ns -> 329 ns +- 4 ns: 1.01x slower
- deque(it_1): 326 ns +- 7 ns -> 330 ns +- 4 ns: 1.01x slower

Faster (2):
- for i in it_10: pass: 26.0 ns +- 1.4 ns -> 25.3 ns +- 0.3 ns: 1.03x faster
- for i in it_1000: pass: 25.7 ns +- 0.7 ns -> 25.3 ns +- 0.4 ns: 1.02x faster

Benchmark hidden because not significant (3): for i in it_100: pass, for i in 
it_1: pass, for i in it_10: pass

Geometric mean: 1.03x slower

###

The results (with PGO):

PS C:\Users\sween\Source\Repos\cpython2\cpython> .\python.bat -m pyperf 
compare_to .\PGO-20e3149c175a24466c7d1c352f8ff2c11effc489.json 
.\PGO-cffa90a8b0057d7e7456571045f2fb7b9ceb426f.json -G
Running PGUpdate|x64 interpreter...
Slower (7):
- for i in it_100: pass: 20.3 ns +- 0.5 ns -> 21.3 ns +- 0.7 ns: 1.05x slower
- for i in it_1: pass: 20.4 ns +- 0.6 ns -> 21.4 ns +- 0.8 ns: 1.05x slower
- for i in it_10: pass: 20.5 ns +- 0.5 ns -> 21.4 ns +- 0.6 ns: 1.05x slower
- for i in it_1000: pass: 20.3 ns +- 0.5 ns -> 21.2 ns +- 0.5 ns: 1.05x slower
- for i in it_10: pass: 20.3 ns +- 0.5 ns -> 21.1 ns +- 0.5 ns: 1.04x slower
- for i in range(10): pass: 214 ns +- 3 ns -> 219 ns +- 11 ns: 1.03x slower
- deque(it_10): 288 ns +- 5 ns -> 291 ns +- 12 ns: 1.01x slower

Faster (7):
- list(iter(range(1))): 112 us +- 3 us -> 96.4 us +- 3.4 us: 1.16x faster
- list(iter(range(1000))): 9.69 us +- 0.15 us -> 8.39 us +- 0.26 us: 1.15x 
faster
- list(iter(range(10))): 1.65 ms +- 0.04 ms -> 1.48 ms +- 0.04 ms: 1.11x 
faster
- list(iter(range(100))): 663 ns +- 11 ns -> 623 ns +- 12 ns: 1.06x faster
- for i in range(1000): pass: 14.6 us +- 0.5 us -> 14.2 us +- 0.3 us: 1.03x 
faster
- for i in range(1): pass: 162 us +- 2 us -> 159 us +- 3 us: 1.02x faster
- for i in range(10): pass: 1.64 ms +- 0.03 ms -> 1.62 ms +- 0.04 ms: 1.01x 
faster

Benchmark hidden because not significant (6): deque(it_10), 
list(iter(range(10))), for i in range(100): pass, deque(it_100), 
deque(it_1000), deque(it_1)

Geometric mean: 1.01x faster

--

___
Python tracker 

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

[issue45290] test_multiprocessing_pool_circular_import fails in M1 mac

[Pablo Galindo Salgado]

New submission from Pablo Galindo Salgado :

==
FAIL: test_multiprocessing_pool_circular_import 
(test.test_importlib.test_threaded_import.ThreadedImportTests)
--
Traceback (most recent call last):
  File 
"/Users/pablogsal/github/cpython/Lib/test/test_importlib/test_threaded_import.py",
 line 258, in test_multiprocessing_pool_circular_import
script_helper.assert_python_ok(fn)
^^
  File "/Users/pablogsal/github/cpython/Lib/test/support/script_helper.py", 
line 160, in assert_python_ok
return _assert_python(True, *args, **env_vars)
   ^^^
  File "/Users/pablogsal/github/cpython/Lib/test/support/script_helper.py", 
line 145, in _assert_python
res.fail(cmd_line)
^^
  File "/Users/pablogsal/github/cpython/Lib/test/support/script_helper.py", 
line 72, in fail
raise AssertionError("Process return code is %d\n"
^^
AssertionError: Process return code is 1
command line: ['/Users/pablogsal/github/cpython/python.exe', '-X', 
'faulthandler', '-I', 
'/Users/pablogsal/github/cpython/Lib/test/test_importlib/partial/pool_in_threads.py']

stdout:
---

---

stderr:
---
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
  File 
"/Users/pablogsal/github/cpython/Lib/test/test_importlib/partial/pool_in_threads.py",
 line 9, in t
with multiprocessing.Pool(1):
 ^^^
  File "/Users/pablogsal/github/cpython/Lib/multiprocessing/context.py", line 
119, in Pool
  File "/Users/pablogsal/github/cpython/Lib/multiprocessing/pool.py", line 212, 
in __init__
  File "/Users/pablogsal/github/cpython/Lib/multiprocessing/pool.py", line 303, 
in _repopulate_pool
  File "/Users/pablogsal/github/cpython/Lib/multiprocessing/pool.py", line 326, 
in _repopulate_pool_static
  File "/Users/pablogsal/github/cpython/Lib/multiprocessing/process.py", line 
121, in start
self._popen = self._Popen(self)
  ^
  File "/Users/pablogsal/github/cpython/Lib/multiprocessing/context.py", line 
284, in _Popen
return Popen(process_obj)
   ^^
  File 
"/Users/pablogsal/github/cpython/Lib/multiprocessing/popen_spawn_posix.py", 
line 32, in __init__
super().__init__(process_obj)
^
  File "/Users/pablogsal/github/cpython/Lib/multiprocessing/popen_fork.py", 
line 19, in __init__
self._launch(process_obj)
^
  File 
"/Users/pablogsal/github/cpython/Lib/multiprocessing/popen_spawn_posix.py", 
line 53, in _launch
parent_r, child_w = os.pipe()
^
  File 
"/Users/pablogsal/github/cpython/Lib/test/test_importlib/partial/pool_in_threads.py",
 line 9, in t
with multiprocessing.Pool(1):
 ^^^
OSError: [Errno 24] Too many open files
/Users/pablogsal/github/cpython/Lib/multiprocessing/resource_tracker.py:224: 
UserWarning: resource_tracker: There appear to be 65 leaked semaphore objects 
to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
/Users/pablogsal/github/cpython/Lib/multiprocessing/resource_tracker.py:237: 
UserWarning: resource_tracker: '/mp-m8lbung6': [Errno 2] No such file or 
directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/pablogsal/github/cpython/Lib/multiprocessing/resource_tracker.py:237: 
UserWarning: resource_tracker: '/mp-w8c_ci83': [Errno 2] No such file or 
directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/pablogsal/github/cpython/Lib/multiprocessing/resource_tracker.py:237: 
UserWarning: resource_tracker: '/mp-yzcaa23b': [Errno 2] No such file or 
directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
/Users/pablogsal/github/cpython/Lib/multiprocessing/resource_tracker.py:237: 
UserWarning: resource_tracker: '/mp-vgij30u5': [Errno 2] No such file or 
directory
  warnings.warn('resource_tracker: %r: %s' % (name, e))
---

--
Ran 1428 tests in 2.752s

FAILED (failures=1, skipped=6, expected failures=1)
test test_importlib failed
test_importlib failed (1 failure)

== Tests result: FAILURE ==

6 tests OK.

--
components: Tests, macOS
messages: 402648
nosy: ned.deily, pablogsal, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_multiprocessing_pool_circular_import fails in M1 mac
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

__

[issue41914] test_pdb fails

[Léon Planken]

Léon Planken  added the comment:

So I went ahead to fix the issue and created a PR. I also signed the CLA, but I 
understand that needs a little time to process.
I was bold/forward enough to add myself to the ACKS. Please feel remove me if 
this contribution is too trivial.

--

___
Python tracker 

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

[issue41914] test_pdb fails

[Léon Planken]

Change by Léon Planken :


--
pull_requests: +26948
pull_request: https://github.com/python/cpython/pull/28564

___
Python tracker 

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

[issue45289] test_dbm and test_dbm_ndbm segfaults in M1 Mac

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
title: test_gdbm segfaults in M1 Mac -> test_dbm and test_dbm_ndbm segfaults in 
M1 Mac

___
Python tracker 

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

[issue45289] test_gdbm segfaults in M1 Mac

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

See https://buildbot.python.org/all/#/builders/725/builds/4

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Eryk Sun]

Eryk Sun  added the comment:

Running the REPL with -S is unusual, so having to use sys.exit() or `raise 
SystemExit` in that case shouldn't be an issue. 

A user who wants custom behavior for `exit` could override sys.displayhook() in 
the PYTHONSTARTUP file. For example:

import sys
import builtins

def displayhook(obj, prev_displayhook=sys.displayhook):
exit = getattr(builtins, 'exit', None)
if obj is exit and callable(exit):
exit()
else:
prev_displayhook(obj)

sys.displayhook = displayhook

> just note that you can always do Ctrl-D.

For the Windows console, Ctrl-D is not usually supported. It's supported when 
pyreadline is installed. Otherwise one has to type Ctrl-Z and enter. In IDLE 
it's Ctrl-D even in Windows, in which case the `exit` repr is wrong, as 
determined by setquit() in Lib/site.py.

--
nosy: +eryksun

___
Python tracker 

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

[issue45289] test_gdbm segfaults in M1 Mac

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
components: +macOS -Tests
nosy: +ned.deily, ronaldoussoren

___
Python tracker 

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

[issue45289] test_gdbm segfaults in M1 Mac

[Pablo Galindo Salgado]

New submission from Pablo Galindo Salgado :

0:04:14 load avg: 3.86 [141/427/1] test_dbm crashed (Exit code -11)
Fatal Python error: Segmentation fault
Current thread 0x000102e2bd40 (most recent call first):
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/test_dbm.py",
 line 58 in keys_helper
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/test_dbm.py",
 line 143 in read_helper
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/test_dbm.py",
 line 74 in test_anydbm_creation
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/case.py",
 line 547 in _callTestMethod
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/case.py",
 line 591 in run
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/case.py",
 line 646 in __call__
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/unittest/runner.py",
 line 197 in run
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/support/__init__.py",
 line 992 in _run_suite
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/support/__init__.py",
 line 1118 in run_unittest
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/runtest.py",
 line 261 in _test_module
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/runtest.py",
 line 297 in _runtest_inner2
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/runtest.py",
 line 340 in _runtest_inner
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/runtest.py",
 line 202 in _runtest
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/runtest.py",
 line 245 in runtest
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/runtest_mp.py",
 line 83 in run_tests_worker
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/main.py",
 line 678 in _main
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/main.py",
 line 658 in main
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/libregrtest/main.py",
 line 736 in main
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/regrtest.py",
 line 43 in _main
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/test/regrtest.py",
 line 47 in 
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/runpy.py",
 line 86 in _run_code
  File 
"/Users/buildbot/buildarea/3.x.pablogsal-macos-m1.macos-with-brew/build/Lib/runpy.py",
 line 196 in _run_module_as_main
Extension modules: _testcapi (total: 1)
0:04:15 load avg: 3.87 [142/427/1] test_c_

The backtrace according to lldb:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x10365c000)
  * frame #0: 0x000182bc6994 libsystem_platform.dylib`_platform_memmove + 84
frame #1: 0x0001000b71d0 python.exe`PyBytes_FromStringAndSize(str="c", 
size=4294967297) at bytesobject.c:165:5
frame #2: 0x00010360b234 
_dbm.cpython-311d-darwin.so`_dbm_dbm_keys_impl(self=0x0001034b3ca0, 
cls=0x00010088a580) at _dbmmodule.c:249:16
frame #3: 0x00010360af34 
_dbm.cpython-311d-darwin.so`_dbm_dbm_keys(self=0x0001034b3ca0, 
cls=0x00010088a580, args=0x0001007991d8, nargs=0, 
kwnames=0x) at _dbmmodule.c.h:46:20
frame #4: 0x0001000dca8c 
python.exe`method_vectorcall_FASTCALL_KEYWORDS_METHOD(func=0x0001034db290, 
args=0x0001007991d0, nargsf=9223372036854775809, 
kwnames=0x) at descrobject.c:367:24
frame #5: 0x000100252374 
python.exe`_PyObject_VectorcallTstate(tstate=0x000100808b30, 
callable=0x0001034db290, args=0x0001007991

[issue45285] c_char incorrectly treated as bytes in Structure

[CireSnave]

CireSnave  added the comment:

Wow.  Thank you Eryk Sun.  While that seems like a convoluted way to make a 
type act like the type it is...it works.  Verified it with the following code:

from ctypes import POINTER, c_char, sizeof, Structure


class char_from_c(c_char):
pass


print("Size of c_char vs size of char_from_c:")
print(sizeof(c_char))
print(sizeof(char_from_c))


class my_structure(Structure):
_fields_ = [
("first_char", char_from_c),
("second_char", char_from_c),
("third_char", char_from_c),
]


my_structure_object: my_structure = my_structure(97, 98, 99)

pointer_to_char_from_c_in_my_structure = 
POINTER(c_char)(my_structure_object.first_char)

print("\nContents of pointer_to_char_from_c_in_my_structure:")
print(pointer_to_char_from_c_in_my_structure.contents)
print("\npointer_to_char_from_c_in_my_Structure[0]:")
print(pointer_to_char_from_c_in_my_structure[0])

print("\nValues from my_structure_object:")
character_counter = 0
while character_counter < sizeof(my_structure_object):
print(pointer_to_char_from_c_in_my_structure[character_counter])
character_counter += 1



...which gave me the following results:

Size of c_char vs size of char_from_c:
1
1

Contents of pointer_to_char_from_c_in_my_structure:
c_char(b'a')

pointer_to_char_from_c_in_my_Structure[0]:
b'a'

Values from my_structure_object:
b'a'
b'b'
b'c'


Again...Thank you.  Closing this "bug" as it is weird...but not a bug.

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

[issue45283] Top / function argument level ClassVar should not be allowed during `get_type_hints()`

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Thank you, Ken Jin! Very clear explanation!

> It seems the current consensus is to use that import for code with purely 
> static typing, and not use it with runtime typing libraries.

Is it an official position? Or just a common usage pattern?
What can we do to make this more widely known?

Maybe we can formulate something like "When to use: raw, string, future 
annotations" in the typing docs (https://docs.python.org/3/library/typing.html)?

--

___
Python tracker 

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

[issue45283] Top / function argument level ClassVar should not be allowed during `get_type_hints()`

[Ken Jin]

Ken Jin  added the comment:

> 1. By adding the same `_type_check` logic we can reduce the inconsistency 
> between two versions. It would be easier for users to migrate from one 
> version to another.

That's definitely a plus. But please consider this hypothetical scenario:

- Let's say some typing code has _type_check in 3.8
- In 3.12, we decide to give type hinting with ints (like `x: 1`) some meaning 
(this has been proposed before in typing-sig).
- The new construct arrives in 3.12. We backport to typing_extensions, which 
*must* support 3.8's typing module.
- Now the new addition to 3.12 typing_extensions doesn't work with 3.8 typing 
because of _type_check, and we need to hack around it.
- The hacks may eventually lead to real behavioral inconsistencies between 
typing_extensions and typing.

If this sounds familiar, that's because something similar has already happened! 
Callable and Generic had too strict checking in typing (requiring Callable's 
args to be a tuple of types always) before 3.10. So typing_extensions doesn't 
support the full PEP 612 syntax :( 
https://github.com/python/typing/tree/master/typing_extensions#other-notes-and-limitations.

Stricter runtime type checking makes growing the typing syntax harder. For the 
newer types, we try to defer checking to 3rd-party libraries.

> Because I received quite a lot of bug reports from users involving different 
> behavior with / without `__future__` import of `annotations`.

Your perspective as a runtime typing library dev is very valuable. Thank you 
for your feedback! IMO, `from __future__ import annotations` becoming the 
default in 3.11 is still undecided. It was yanked from 3.10 for breaking 
pydantic and FastAPI, and I doubt it will land in 3.11 for the same reasons. It 
seems the current consensus is to use that import for code with purely static 
typing, and not use it with runtime typing libraries.

--

___
Python tracker 

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

[issue45026] More compact range iterator

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There is nothing in code that could explain a measureable difference in 
creating the range objects or the range object iterators. And indeed, it is in 
the range of the standard deviation, so it is non-existent.

--

___
Python tracker 

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

[issue45287] zipfile.is_zipfile returns true for a rar file containing zips

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> is_zipfile false positives

___
Python tracker 

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

[issue45286] zipfile missing API for links

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Improve zipfile: add support for symlinks

___
Python tracker 

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

[issue37921] Improve zipfile: add support for symlinks

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Adding support of symlinks in ZIP files will make the zipfile module vulnerable 
to symlink attacks like like with TAR files (see 
https://en.wikipedia.org/wiki/Tar_(computing)#Duplicates). Until we find a 
solution to this, adding support of symlinks is dangerous.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue45288] Inspect - Added sort_result parameter on getmembers function.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

But you will not get them in creation order, even if omit the final sort, 
because:

1. dir() returns names sorted alphabetically, not in order of creation.
2. Dynamic class attributes are added at the end, and inherited attributes 
follow attributes defined in that class.

So adding this parameter will not help you.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue45283] Top / function argument level ClassVar should not be allowed during `get_type_hints()`

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Just to bring in some context for this discussion: 
https://github.com/python/cpython/pull/28279

We have dicussed in the PR above that current implementation depends on 
existing of `__future__` import of `annotations`.

With `from __future__ import annotations`:
1. Top level class var will be raise `TypeError`
2. Final and ClassVar function arguments will raise `TypeError`
3. Annotations like `x: 1` will raise `TypeError: Forward references must 
evaluate to types. Got 1.`

Without `from __future import annotations`it accepts all the cases above.

I share two opposite views on this change:
1. By adding the same `_type_check` logic we can reduce the inconsitency 
between two versions. It would be easier for users to migrate from one version 
to another.
2. By adding this feature, we would more aggresively force some specific 
semantics for builtin types. Which can possibly be problematic, for example 
I've tried to add `Final` annotations to function arguments in my own type 
checker. It is something current semantics does not support. Moreover, it can 
cause incompatibility to existing users.

My opinion is that consitency is more important here. Because I received quite 
a lot of bug reports from users involving different behavior with / without 
`__future__` import of `annotations`.

But, I understand that it is not up to me to decide :)

--

___
Python tracker 

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

[issue44892] Configparser fails when the .cfg file contains inline 'comments'

[Diego Ramirez]

Diego Ramirez  added the comment:

Sure, thanks!

--

___
Python tracker 

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

[issue45020] Freeze all modules imported during startup.

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 25.09.2021 18:20, STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> Marc-Andre: I suppose that you're talking about LANDMARK in Modules/getpath.c 
> and PC/getpathp.c.

Now that you mention it: yes, that as well :-) But os.py is used in the
Python stdlib code as well, just search for "os.__file__" to see a few
such uses.

If you search for ".__file__" you'll find that there are quite a few
cases in the test suite expecting that attribute on other stdlib modules
as well. The attribute may officially be optional, but in reality a
lot of code expects to find it.

--

___
Python tracker 

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

[issue45020] Freeze all modules imported during startup.

[STINNER Victor]

STINNER Victor  added the comment:

Marc-Andre: I suppose that you're talking about LANDMARK in Modules/getpath.c 
and PC/getpathp.c.

--

___
Python tracker 

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

[issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux

[STINNER Victor]

STINNER Victor  added the comment:

> Do you have any information about when will be it released in 3.11?

Here is a schedule of Python 3.11 releases:
https://www.python.org/dev/peps/pep-0664/

In the meanwhile, you can develop a C extension to get the feature.

--

___
Python tracker 

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

[issue45283] Top / function argument level ClassVar should not be allowed during `get_type_hints()`

[Ken Jin]

Ken Jin  added the comment:

This makes ``get_type_hints`` quite opinionated and backwards incompatible. The 
first line the docs says "This is often the same as obj.__annotations__".

I also agree with Guido. FYI, we've tried to *reduce* usage of `_type_check` in 
new features since version 3.10. We've found that they make `typing_extensions` 
operability with `typing` worse. For example, the whole of PEP 612 in 
`typing_extensions` required lots of hacks to work with typing's Callable.

If you're really vouching for this change. We probably need a 2 major version 
deprecation period (with warnings telling the user their current type hints are 
invalid) *plus* asking typing-sig/python-dev if the runtime type hints users 
will be affected. See [PEP 387](https://www.python.org/dev/peps/pep-0387/) for 
more info.

On the other hand, we now have a less-opinionated alternative to 
``get_type_hints`` with ``inspect.get_annotations``, but it can't do as much 
(like resolving ForwardRef).

--
nosy: +kj

___
Python tracker 

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

[issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux

[Benjamin Szőke]

Benjamin Szőke  added the comment:

Do you have any information about when will be it released in 3.11?

--

___
Python tracker 

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

[issue45020] Freeze all modules imported during startup.

[Guido van Rossum]

Guido van Rossum  added the comment:

The plan is to add __file__ back, based on where the stdlib lives (we won’t do 
any stat() calls for frozen files).

--

___
Python tracker 

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

[issue45283] Top / function argument level ClassVar should not be allowed during `get_type_hints()`

[Guido van Rossum]

Guido van Rossum  added the comment:

Hm. IMO it is up to static type checkers to reject bad use of types. The 
runtime should be relaxed so type checkers can develop new features assigning 
new semantics to such constructs.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue45288] Inspect - Added sort_result parameter on getmembers function.

[Cristobal Riaga]

Cristobal Riaga  added the comment:

Added sort_result parameter (bool=True) on getmembers function inside 
Lib/inspect.py, that, as it name says, allows you to getmembers result without 
sorting it.
I'm needed of this and it seems impossible to achieve because of 367 line:

results.sort(key=lambda pair: pair[0])

Any other solution is very welcomed.

(I need it because I'm working on an API Reference creator and I think it would 
be better if it the members are ordered in the same order you define them.)

--

___
Python tracker 

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

[issue45288] Inspect - Added sort_result parameter on getmembers function.

[Cristobal Riaga]

New submission from Cristobal Riaga :

Added `sort_result` parameter (`bool=True`)  on `getmembers` function inside 
`Lib/inspect.py`, that, as it name says, allows you to `getmembers` result 
without sorting it.
I'm needed of this and it seems impossible to achieve because of [`367` 
line](https://github.com/python/cpython/blob/3.9/Lib/inspect.py#L367): 
```py
results.sort(key=lambda pair: pair[0])
```
Any other solution is very welcomed.

(I need it because I'm working on an [API Reference 
creator](https://github.com/Patitotective/PyAPIReference) and I think it would 
be better if it the members are ordered in the same order you define them.)

--
components: Library (Lib)
messages: 402626
nosy: Patitotective
priority: normal
pull_requests: 26947
severity: normal
status: open
title: Inspect - Added sort_result parameter on getmembers function.
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

[issue44892] Configparser fails when the .cfg file contains inline 'comments'

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: Configparser fails when the .cfg file contains comments -> Configparser 
fails when the .cfg file contains inline 'comments'

___
Python tracker 

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

[issue44892] Configparser fails when the .cfg file contains comments

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Please report back on the pip issue to read more of the doc, about inline 
comments in
https://docs.python.org/3/library/configparser.html#customizing-parser-behaviour
like I should have before writing what I did.

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

[issue45287] zipfile.is_zipfile returns true for a rar file containing zips

[mxmlnkn]

New submission from mxmlnkn :

I have created a RAR file containing two zip files like this:

zip bag.zip README.md CHANGELOG.md
zip bag1.zip CHANGELOG.md
rar a zips.rar bag.zip bag1.zip

And when calling `zipfile.is_zipfile` on zips.rar, it returns true even though 
it obviously is not a zip. The zips.rar file doesn't even begin with the magic 
bytes `PK` for zip but with `Rar!`.

--
files: zips.rar
messages: 402624
nosy: mxmlnkn
priority: normal
severity: normal
status: open
title: zipfile.is_zipfile returns true for a rar file containing zips
Added file: https://bugs.python.org/file50305/zips.rar

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> Typing `import sys; sys.exit()` every time I want to test something quick on 
> the REPL is awful UX.

Without disagreeing with the general sentiment, just note that you can always 
do Ctrl-D.

--

___
Python tracker 

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

[issue41914] test_pdb fails

[Léon Planken]

Léon Planken  added the comment:

Here's the issue again when running test_pdb.py for 3.11 (repository main). The 
same problem now occurs twice, and only inside the `screen` environment.

- 8< -

~/Temp/cpython> ./python Lib/test/test_pdb.py
.F.F
==
FAIL: test_errors_in_command (__main__.PdbTestCase)
--
Traceback (most recent call last):
  File "/home/leon/Temp/cpython/Lib/test/test_pdb.py", line 1847, in 
test_errors_in_command
self.assertEqual(stdout.splitlines()[1:], [
^^^
AssertionError: Lists differ: ['-> [278 chars]efined", 'LEAVING RECURSIVE 
DEBUGGER', '(Pdb) ', '\x1b[?1034h'] != ['-> [278 chars]efined", 'LEAVING 
RECURSIVE DEBUGGER', '(Pdb) ']

First list contains 1 additional elements.
First extra element 10:
'\x1b[?1034h'

  ['-> pass',
   "(Pdb) *** SyntaxError: '(' was never closed",
   '(Pdb) ENTERING RECURSIVE DEBUGGER',
   "*** SyntaxError: '(' was never closed",
   'LEAVING RECURSIVE DEBUGGER',
   '(Pdb) ENTERING RECURSIVE DEBUGGER',
   '> (1)()',
   "((Pdb)) *** NameError: name 'doesnotexist' is not defined",
   'LEAVING RECURSIVE DEBUGGER',
-  '(Pdb) ',
?  ^

+  '(Pdb) ']
?  ^

-  '\x1b[?1034h']

==
FAIL: test_issue34266 (__main__.PdbTestCase)
do_run handles exceptions from parsing its arg
--
Traceback (most recent call last):
  File "/home/leon/Temp/cpython/Lib/test/test_pdb.py", line 1875, in 
test_issue34266
check('\\', 'No escaped character')
^^^
  File "/home/leon/Temp/cpython/Lib/test/test_pdb.py", line 1870, in check
self.assertEqual(stdout.splitlines()[1:], [
^^^
AssertionError: Lists differ: ['-> [13 chars] *** Cannot run \\: No escaped 
character', '(Pdb) \x1b[?1034h'] != ['-> [13 chars] *** Cannot run \\: No 
escaped character', '(Pdb) ']

First differing element 2:
'(Pdb) \x1b[?1034h'
'(Pdb) '

- ['-> pass',
-  '(Pdb) *** Cannot run \\: No escaped character',
+ ['-> pass', '(Pdb) *** Cannot run \\: No escaped character', '(Pdb) ']
? +++ ++

-  '(Pdb) \x1b[?1034h']

--
Ran 56 tests in 2.850s

FAILED (failures=2)

--
versions: +Python 3.11 -Python 3.10

___
Python tracker 

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

[issue44892] Configparser fails when the .cfg file contains comments

[Diego Ramirez]

Diego Ramirez  added the comment:

Hi Terry, I didn't see your response. I think this won't be possible, taking in 
count the comment that Serhiy posted:

> By default configparser does not support inline comments. "#  percentage sign 
> '%'" is a part of value. If you want to support inline comments you should 
> pass the inline_comment_prefixes argument.

Maybe this is a reasonable behavior. What do you think about it?

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Filipe Laíns]

Filipe Laíns  added the comment:

> In my view, that's exactly why it _shouldn't_ have a special treatment. After 
> all, site can add many more builtins. Do you want all of them to have 
> autocall?

No, and I did not suggest anything of the sort. I just want the exit because of 
its integral job of... exiting the REPL. Typing `import sys; sys.exit()` every 
time I want to test something quick on the REPL is awful UX.

--

___
Python tracker 

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

[issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Livius for all these nice enhancements!

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

[issue21302] time.sleep (floatsleep()) should use clock_nanosleep() on Linux

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7834ff26cbcd4d8394d64d80d9f51a364d38b1c6 by Victor Stinner in 
branch 'main':
bpo-21302: Add nanosleep() implementation for time.sleep() in Unix (GH-28545)
https://github.com/python/cpython/commit/7834ff26cbcd4d8394d64d80d9f51a364d38b1c6


--

___
Python tracker 

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

[issue45286] zipfile missing API for links

[mxmlnkn]

New submission from mxmlnkn :

When using zipfile as a library to get simple files, there is no way to method 
to determine whether a ZipInfo object is a link or not. Moreover, links can be 
simply opened and read like normal files and will contain the link path, which 
is unexpected in most cases, I think.

ZipInfo already has an `is_dir` getter. It would be nice if there also was an 
`is_link` getter. Note that `__repr__` actually shows the filemode, which is 
`lrwxrwxrwx`. But there is not even a getter for the file mode.

For now, I can try to use the code from `__repl__` to extract the file mode 
from the `external_attr` member but the contents of that member are not 
documented in zipfile and assuming it is the same as in the ZIP file format 
specification, it's OS-dependent.

Additionally to `is_link` some getter like `linkname` or so would be nice. As 
to how it should behave when calling `open` or `read` on a link, I'm not sure.

--
messages: 402617
nosy: mxmlnkn
priority: normal
severity: normal
status: open
title: zipfile missing API for links

___
Python tracker 

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

[issue45283] Top / function argument level ClassVar should not be allowed during `get_type_hints()`

[Nikita Sobolev]

Change by Nikita Sobolev :


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

___
Python tracker 

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

[issue43914] Highlight invalid ranges in SyntaxErrors

[Łukasz Langa]

Łukasz Langa  added the comment:

This is complete now. Thanks! ✨ 🍰 ✨

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.11

___
Python tracker 

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

[issue43914] Highlight invalid ranges in SyntaxErrors

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset c523022ba8f81a3661b4ac8be81706ed095d5769 by Łukasz Langa in 
branch '3.10':
[3.10] bpo-43914: What's New 3.10: add new SyntaxError attributes (GH-28558) 
(GH-28562)
https://github.com/python/cpython/commit/c523022ba8f81a3661b4ac8be81706ed095d5769


--

___
Python tracker 

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

[issue45166] get_type_hints + Final + future annotations = TypeError

[Łukasz Langa]

Łukasz Langa  added the comment:

Thanks for the report Timothee, and Nikita for the fix! ✨ 🍰 ✨

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

[issue45166] get_type_hints + Final + future annotations = TypeError

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 1f08d16c90b6619607fe0656328062ab986cce29 by Łukasz Langa in 
branch '3.9':
[3.9] bpo-45166: fixes `get_type_hints` failure on `Final` (GH-28279) (GH-28561)
https://github.com/python/cpython/commit/1f08d16c90b6619607fe0656328062ab986cce29


--

___
Python tracker 

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

[issue45166] get_type_hints + Final + future annotations = TypeError

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset d312b8516e11027ce97897d39764e242f0f57087 by Miss Islington (bot) 
in branch '3.10':
bpo-45166: fixes `get_type_hints` failure on `Final` (GH-28279) (GH-28560)
https://github.com/python/cpython/commit/d312b8516e11027ce97897d39764e242f0f57087


--

___
Python tracker 

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

[issue43914] Highlight invalid ranges in SyntaxErrors

[Łukasz Langa]

Change by Łukasz Langa :


--
pull_requests: +26945
pull_request: https://github.com/python/cpython/pull/28562

___
Python tracker 

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

[issue43914] Highlight invalid ranges in SyntaxErrors

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 71f8ff45c62bd6b792919ac7c3804a8628ae12cb by Terry Jan Reedy in 
branch 'main':
bpo-43914: Whats New 310: add new SyntaxError attributes (GH-28558)
https://github.com/python/cpython/commit/71f8ff45c62bd6b792919ac7c3804a8628ae12cb


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue45166] get_type_hints + Final + future annotations = TypeError

[Łukasz Langa]

Change by Łukasz Langa :


--
pull_requests: +26944
pull_request: https://github.com/python/cpython/pull/28561

___
Python tracker 

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

[issue45166] get_type_hints + Final + future annotations = TypeError

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 784905dbeff68cf788bbeefe0a675af1af04affc by Nikita Sobolev in 
branch 'main':
bpo-45166: fixes `get_type_hints` failure on `Final` (GH-28279)
https://github.com/python/cpython/commit/784905dbeff68cf788bbeefe0a675af1af04affc


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue45166] get_type_hints + Final + future annotations = TypeError

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +26943
pull_request: https://github.com/python/cpython/pull/28560

___
Python tracker 

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

[issue45020] Freeze all modules imported during startup.

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Eric, I noticed that you are freezing os.py. Please be aware that
this module is often being used as indicator for where the stdlib
was installed (the stdlib itself does this in site.py to read the
LICENSE and the test suite also uses os.__file__ in a couple of
places).

It may be worth changing the stdlib to pick a different module
as landmark for this purpose.

Also: Unless you have added the .__file__ attribute to frozen
modules, much of this landmark checking code will fail... which is
the reason I added the attribute to frozen modules in PyRun.

--

___
Python tracker 

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

[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful

[Gregory P. Smith]

Gregory P. Smith  added the comment:

**If** we add a callback API for this, I agree with vstinner's 
https://bugs.python.org/issue42969#msg402558 commentary on the other callback 
APIs.  We can do this one similarly and keep it simple. - Why? It's the initial 
simplicity that provides those running into this problem a way to solve their 
problem today.  Without getting hung up on the details of the new default 
behavior.

**That said** the only conclusion I'm coming to for what the safest behavior of 
Python is in this situation is to hang the threads, effectively as PR 28525 is 
proposing.

So even if we added the callback API, I'd expect code using Python with C++ 
where these issues might ever crop up to always register a thread hanging 
callback.  Which really suggests it is the good default.  So do we even need 
the callback?

...But lets put the default behavior choice aside for a moment, there's 
something valuable regardless...

There are **New C APIs to enhance PyGILState_Ensure** proposed in PR 28525 to 
do with GIL acquisition from threads.  These appear useful as is.  They provide 
a way for threads to discover that they will never be able to get the GIL and 
re-enter the Python interpreter.  Rather than today's unexpected behavior of 
PyGILState_Ensure mercilessly terminating their thread, or given a Callback API 
whatever effect such a Callback API would have.  That allows code to be written 
with pre-problem-detection that avoids entering this point of no return state.  
That is good for everyone.  **We should add those "GIL-curious" APIs no matter 
what.**  This bit could become its own PR separate from the other parts.

If we cannot agree that blocking a non-main daemon-or-C/C++ thread forever that 
is guaranteed to not acquire the GIL because the Python interpreter is going 
away is the right default behavior instead of blindly killing it under the 
unsupportable assumption that it has nothing to clean up: We can proceed with 
such a callback API. I'm having a hard time imagining any other behavior that 
makes sense, so I'd expect lots of Python extension interface code to start 
carrying a copy of an implementation of a hang callback and sporting a 
Py_SetThreadExitCallback(xxx) call in their module Init function. (especially 
if pybind11 finds needs to generate this as boilerplate)

I think the pthread_exit() call added in issue1856's 
https://hg.python.org/cpython/rev/c892b0321d23 were well intentioned, but not 
aware of the full unsupportable ramifications of that API call. That the 
attempt at releasing a backport of the pthread_exit call to 2.7.8 broke an 
application (that was admittedly doing something unwise) and had to be reverted 
as 2.7.9 was a sign for us to revisit this in 3.x releases as well.  Which 
we're finally doing here.

--
nosy: +pitrou

___
Python tracker 

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

[issue45280] Empty typing.NamedTuple creation is not tested

[Nikita Sobolev]

Change by Nikita Sobolev :


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

___
Python tracker 

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

[issue45275] Make argparse print description of subcommand when invoke help doc on subcommand

[Nikita Sobolev]

Nikita Sobolev  added the comment:

Hi!

>From your description it is not clear how exactly you create your subcommand.

>From my experience, it works. Demo:

```
import argparse

parser = argparse.ArgumentParser(description='Process some integers.')
subparsers = parser.add_subparsers()

# create the parser for the "a" command
parser_a = subparsers.add_parser('a', help='a help', description='test me')
parser_a.add_argument('bar', type=int, help='bar help')

print(parser.parse_args())
```

Here's the output of `python script.py a -h`:

```
usage: ex.py a [-h] bar

test me

positional arguments:
  bar bar help

options:
  -h, --help  show this help message and exit
```

Do you have the same setup? Or is there anything else that needs to be fixed?

--
nosy: +sobolevn

___
Python tracker 

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

[issue45113] [subinterpreters][C API] Add a new function to create PyStructSequence from Heap.

[Hai Shi]

Hai Shi  added the comment:

> More generally, this would need solving one of the remaining limitations of 
> the limited API (PEPs 489, 630): type-specific data.
Agree. We can't track and destroy the memory block created from the heap now.

--

___
Python tracker 

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