hardbyte / hardbyte/python-can

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

Abierto
#1,922 0 comentarios 1 reacción 0 asignados Ver en GitHub
bug
Lenguaje dominante
Python
Estrellas
1.6k
Forks
697
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

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

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.