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

Go over grammar for why there are duplicate (more) reductions.

Abierto
#26 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
python

Línea de trabajo

Start with ./bin/uncompyle6 -g test/bytecode_2.5/10_if_else_ternary.pyc and compare the reductions with the older Python 2.7 grammar from git history or uncompyle2. Use git bisect to identify when duplicate rules appeared, then inspect the optional and recursive grammar changes and the more specific grammar selection. Done means the duplicate reductions are explained and the affected deparse no longer emits them.

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

Descripción

Consider this deparse:

$ ./bin/uncompyle6 -g test/bytecode_2.5/10_if_else_ternary.pyc
# Python bytecode 2.5 (decompiled from Python 2.6)
# Embedded file name: simple_source/branching/10_if_else_ternary.py
...
exprlist ::= expr
compare ::= expr expr COMPARE_OP
compare ::= expr expr COMPARE_OP
cmp ::= compare
cmp ::= compare
expr ::= cmp
expr ::= cmp
...

In the good old days for Python 2.7 this used to be:

compare ::= expr expr COMPARE_OP
cmp ::= compare
expr ::= cmp

I suspect adding various optional nonterminals, e.g. come_from_opt for Python 3.5 is what caused this. And even here, the optional nonterminals were a result of fixing problems before I realized that python 2.7. structure analysis was needed in Python 3.

It is also possible that the duplication comes from changes to use left-recursive grammars. I read in wikipedia that left-recursive grammars for Early parsers generally gives linear parse time, but perhaps I shouldn't believe wikipedia? Or it could be the other way around, maybe I added a right-recursive rule instead of a left-recursive one. (If that's the case we should fix up spark to warn about right, or is it left, recursive rules.)

Tracking this down can be as simple as a git bisect, or reinstating the old 2.7 grammar say from uncompyle2 which should be in git history.

By the way, we now have ways to better select more specific grammars for sets of Python versions, so that could and should be used.

@moagstar is this something that interests you?

Lenguaje dominante
Python
Estrellas
4.3k
Forks
464
Merge medio
10 h 7 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 rocky/python-uncompyle6

Todos los issues de rocky/python-uncompyle6

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.