Just to clarify: you say

return True if the bus supports the CAN-FD protocol

but you actually just want to know whether CAN FD is currently active, right?

Generally i don't mind standardizing this for all interfaces, but with CAN XL coming soon it might make sense to use an enum instead of a boolean flag. Otherwise we would need to add is_xl soon.

Sure, I can implement this as an enum. Let me know what you want it to look like, something along the lines:

• CAN_ISO_11898
• CAN_FD
• CAN_XL

CAN FD is already part of ISO 11898 and CAN XL will also be part of 11898. So instead of CAN_ISO_11898 i'd suggest CAN_20 or something like that. Do you have any ideas for the class name? CanSpec? Protocol? PhysicalLayer?

@hardbyte not sure how to contact you but i recommend @lumagi as maintainer ;)

@lumagi - Lukas thanks so much for your contributions so far. As suggested I've invited you to the repository as a collaborator. Use your new powers for good! In essence, please be sensible and request reviews for non-trivial changes 👍

Great idea @zariiii9003!

@hardbyte Thank you for the invitation, I appreciate it! And thanks for the recommendation @zariiii9003 ;)

Regarding the naming of the enum, I think I like Protocol. But I would like make it a bit more specific like CANProtocol, otherwise this might clash with a different symbol when importing it into the module scope.

Edit: Maybe BusProtocol would fit better with the naming.

Here is an interesting sentence

The third generation of the CAN data link layer supports all three protocol types (Classical CAN, CAN FD, and CAN XL)

So it is either "DataLinkLayer" or "Protocol". I'm not sure which one is technically correct in our case. I prefer CanProtocol over BusProtocol btw if we take the protocol option.

Ok, to me either one would be fine: CANLinkLayer, CANProtocol. But I wouldn't want to make the names too long.

Ok, to me either one would be fine: CANLinkLayer, CANProtocol. But I wouldn't want to make the names too long.

I just looked through the rest of the code, can you rename it to CanProtocol? That's more in line with the rest of our code:
image

Done

Yes sure, I don't mind. I only have a couple Bus implementations left, so this can probably change state away from draft soon. But I imagine there's gonna be some feedback :D

I resolved all the merge conflicts from #1551. I hope i didn't break anything.

Thanks for resolving the conflicts! And also the rogue black test - It was not able to come to terms with my local black version.

Thanks for resolving the conflicts! And also the rogue black test - It was not able to come to terms with my local black version.

You could install the correct versions with pip install -r requirements-lint.txt

@zariiii9003 I think I'm through with all the implementations, if you would like to take a look.

Great, thanks for the review! How many reviewers do you normally have for greater changes like this one?

Great, thanks for the review! How many reviewers do you normally have for greater changes like this one?

At some point 2 reviews were required. But we had more active maintainers at that point. I will merge this after a 4.2.1 bugfix release to avoid backporting headaches.

@zariiii9003 When do you think this will make it into a release? Will this have to wait until a major release or will this go into the next minor? To be honest, I am quite looking forward to having this feature available :D

@lumagi I was hoping to include #1611. But i could release 4.3 anytime. I'll try to get it ready by the end of the week.
You could accelerate it by updating the changelog to include all relevant changes since 4.2.2 😄

Sure, I can take care of that. I'll probably get around to doing that over the weekend.