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

New error behaviour when calling `flush_tx_buffer` for several interface types

Abierto Apto para principiantes
#1,922 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
1/5
Tiempo estimado
Menos de una hora
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
python
Área
api

Línea de trabajo

Comienza con la clase BusABC y el comportamiento de flush_tx_buffer() introducido por PR #1724; reproduce la excepción usando una interfaz como socketcan. Confirma que las interfaces no compatibles vuelven al comportamiento no-op anterior sin cambiar las interfaces que implementan el vaciado, y verifica después que la reproducción ya no produce una excepción.

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

Descripción

bug
Describe the bug

Due to the addition of raise NotImplementedError in the BusABC class introduced with https://github.com/hardbyte/python-can/pull/1724 by @zariiii9003, trying to call flush_tx_buffer() throws an exception when called for any interface type that doesn't explicitly implement this.

There are several interface types in python-can which don't, including e.g. socketcan.

This breaks other tools which relied on the previous behaviour of "doing nothing" when flush_tx_buffer() was called on one of these interfaces.

To Reproduce

Call flush_tx_buffer() on an interface type that doesn't explicitly implement this method.

I noticed this because the tool pydronecan no longer works for socketcan if python-can is installed on the system.

Expected behavior

I expect the old behaviour where flushing does nothing. This can easily be done by removing the raise line, or more complicated, by implementing flush_tx_buffer() with a pass for all interface types in this repo where flushing is irrelevant.

If behavour was like this from the beginning, I would be OK with raising error. However, I think it's problematic when previous versions didn't behave like this, causing problems for tools like pydronecan. The behaviour of interfaces like this should be kept stable.

Additional context

This problem exists for every version after the PR linked above was merged. All releases after 4.4.0 are affected.

Lenguaje dominante
Python
Estrellas
1.6k
Forks
697
Sin PR fusionados en 30 d

Guía de contribución

Abrir la guía de contribución

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 hardbyte/python-can

Todos los issues de hardbyte/python-can

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.