Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

String mutations: the two case flips are equivalent wherever the consumer is case-insensitive, and no option turns them off

Abierto
  • ¿Algo no está bien?
#577 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

@nabi-noor ya está trabajando en esto.

Desde el 10/9/2026.

  • #579 de @nabi-noor — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python, sqlite
Área
cli, testing-qa, tooling

Línea de trabajo

Comienza con el punto de entrada operator_string y el comportamiento de configuración existente de --disable-mutation-types y do_not_mutate_patterns. Reproduce los mutantes de minúsculas y mayúsculas que sobreviven con example.py, test_example.py y pyproject.toml, y después añade cobertura de regresión que demuestre que los cambios de mayúsculas y minúsculas pueden deshabilitarse sin eliminar los mutantes XX ni los de indexación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement good first issue

Disclaimer: AI-drafted, verified by me before filing. I answer follow-ups.

operator_string emits three mutants for every string literal: the literal wrapped in XX, lowercased, and uppercased. Where the literal's consumer is case-insensitive -- SQL, codec names, HTTP header names -- the case flips are equivalent mutants by construction.

Expected: a mutation I cannot kill can be switched off, as --disable-mutation-types did in 2.x (#175, added by #225).
Actual: both case flips survive every run, and the only lever in 3.x, do_not_mutate_patterns, matches whole lines, so it drops the XX mutant on that line too.

They were 25% and 11% of all survivors on two of my codebases: re-read on every run, and nothing to be done about them.

Reproduce -- three files, mutmut 3.7.0, pytest 9.1.1, CPython 3.12.12 
# example.py
import sqlite3


def note_count(db_path: str) -> int:
    con = sqlite3.connect(db_path)
    return con.execute("SELECT COUNT(*) FROM notes").fetchone()[0]

# test_example.py
import sqlite3

from example import note_count


def test_note_count(tmp_path):
    db = tmp_path / "n.db"
    con = sqlite3.connect(db)
    con.execute("CREATE TABLE notes (id int)")
    con.execute("INSERT INTO notes VALUES (1)")
    con.commit()
    con.close()
    assert note_count(str(db)) == 1

# pyproject.toml
[project]
name = "repro"
version = "0"
requires-python = ">=3.11"

[tool.mutmut]
source_paths = ["example.py"]

$ mutmut run
7/7  🎉 5 🫥 0  ⏰ 0  🤔 0  🙁 2  🔇 0  🧙 0

$ mutmut results
    example.x_note_count__mutmut_5: survived
    example.x_note_count__mutmut_6: survived

$ mutmut show example.x_note_count__mutmut_5
# example.x_note_count__mutmut_5: survived
--- example.py
+++ example.py
@@ -1,3 +1,3 @@
 def note_count(db_path: str) -> int:
     con = sqlite3.connect(db_path)
-    return con.execute("SELECT COUNT(*) FROM notes").fetchone()[0]
+    return con.execute("select count(*) from notes").fetchone()[0]

$ mutmut show example.x_note_count__mutmut_6      # the same line, uppercased
+    return con.execute("SELECT COUNT(*) FROM NOTES").fetchone()[0]

SQLite parses either casing and resolves table names case-insensitively, so both mutants are equivalent to the original. The only test that would kill them asserts the query string's exact casing, which tests the literal rather than the behaviour.

What the line pattern costs -- 7 mutants become 2 
[tool.mutmut]
source_paths = ["example.py"]
do_not_mutate_patterns = ["SELECT"]

$ mutmut run
2/2  🎉 2 🫥 0  ⏰ 0  🤔 0  🙁 0  🔇 0  🧙 0

Five of the seven mutants are gone. Two of them, mutant 4 ("XXSELECT COUNT(*) FROM notesXX") and mutant 7 (.fetchone()[1]), are killed by the test as it stands, so the pattern removes working signal in order to remove two mutants that carry none.

Lenguaje dominante
Python
Estrellas
1.5k
Forks
182
Merge medio
2 d 14 h
PR fusionados (30 d)
3

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de boxed/mutmut

Todos los issues de boxed/mutmut

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.