hardbyte / hardbyte/python-can

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

Ouverte
#1,922 0 commentaires 1 réaction 0 personnes assignées Voir sur GitHub
bug
Langage dominant
Python
Étoiles
1.6k
Forks
697
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

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

Guide de contribution

Ouvrir le guide de contribution

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.