Is the best way to get rid of it to just parse it out?
Personally I would avoid the str representation of the message except for debugging purposes. Use the attribute directly to get the float value in the most efficient and accurate way.
Brian Thornerepo owner
Mike is this the can_logger output that has changed - or your own program?
I agree with Travis though, avoid parsing the str repr and instead define your own message format function which displays exactly what you want.
Thanks guys. Yes, this is a program of my own. I didn't use it for a while, and yesterday when I ran it, it crashed (on a new Raspberry PI, with what was obviously an updated version of python-can)...and so I traced it down to the addition of the descriptions in the Message.
I'll move away from the str repr, and just look at the message attributes now.
However, I'm curious, what drove the need to put the descriptions in the str representation of the Message? Why don't all the elements of the str rep have descriptions?
Looks like the listener/buffered reader utilizes the str repr of the can message...is this true?