`test_curses` regression in 3.16.0a1: `test_newterm` fails on a real terminal that's not 80x25
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 72/100
Rechercherichtung
Der fehlschlagende Check ist self.assertEqual(win.getmaxyx(), (24, 80)) in test_newterm in Lib/test/test_curses.py (ungefähr Zeile 3336), der von einem 80x25-Terminal ausgeht. Reproduziere das Problem, indem du python -m test test_curses -v in einem echten Terminal mit anderer Größe ausführst, und vergleiche das Ergebnis mit einem Lauf in der CI. Fertig ist es, wenn der Test nicht mehr von den Abmessungen des Host-Terminals abhängt und trotzdem prüft, was er prüfen soll.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Bug report
The test seems to be written with the wrong assumption that curses will always evaluate the terminal size to 80x25, which fails when tests are run on a real terminal rather than GHA:
======================================================================
FAIL: test_newterm (test.test_curses.ScreenTests.test_newterm)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/tmp/portage/dev-lang/python-3.16.0_alpha1/work/Python-3.16.0a1/Lib/test/test_curses.py", line 3336, in test_newterm
self.assertEqual(win.getmaxyx(), (24, 80))
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Tuples differ: (24, 135) != (24, 80)
First differing element 1:
135
80
- (24, 135)
+ (24, 80)
----------------------------------------------------------------------
Ran 189 tests in 4.068s
FAILED (failures=1, skipped=4)
CPython versions tested on:
3.16
Operating systems tested on:
Linux
- Vorherrschende Sprache
- Python
- Sterne
- 77.7k
- Forks
- 38.3k
- Ø Merge
- 11 Std. 58 Min.
- Gemergte PRs (30 T.)
- 672
Entwicklungsumgebung
Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus python/cpython
-
topic-socket type-bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
python/cpython#160561 · 7 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
tests topic-profiling type-bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
python/cpython#160334 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
extension-modules type-bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Maintainer antworten meist innerhalb von 1 Tag
-
interpreter-core type-feature
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 78/100
python/cpython#160109 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
extension-modules type-bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
python/cpython#160001 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Arekkazu/sgpmp-backend#744 ·
Maintainer antworten meist innerhalb von 1 Tag
-
agent/reviewer
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
projectbluefin/utah-packages#634 ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement good first issue help wanted
Schwierigkeit 2/5 1-2 Tage Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
home-assistant/core#188613 ·
Maintainer antworten meist innerhalb von 1 Tag
-
WebsiteOffengood first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 91/100
TanbirRamim/open-source-radar#314 ·
Maintainer antworten meist innerhalb von 1 Tag