Closed cristi-neagu closed 6 years ago
Yes, this is something which is not so clean. All the prints that are annoying you, are actually there to inform user something happened during parsing but it is not important enough to stop processing and raising error. Most of them are actually rather there for debugging purpose. Error management is also weak I think, but another subject. I could propose to actually convert all those prints by warnings.warn('message'). Then you could tune behaviour using filter from warnings module. Already existing information to user remains and you can suppress it when you need.
That sounds fair enough. A little bit roundabout, but it's probably the pythonic way of doing it.
Edit: For this to work properly, the raised warnings should be specific to mdfreader, so that only they can be filtered out.
Should be done in dev branch, you could try.
I can confirm that it does seem to work at least for the particular issue i was having. To hide the warnings, this is the code i used, roughly:
import mdfreader as mdf
import warnings
datFile = mdf.mdf('test.dat', channelList=[])
with warnings.catch_warnings():
warnings.simplefilter('ignore')
datFile.resample(0.1)
Note that i am loading the file with an empty channelList
to force the warnings.
I'd say that solved, for now. Thank you.
Hello,
This is to discuss a solution (if a solution is even required) to the various warnings printed by the library. This often interfere with scripts, ruining output formating. In this case, messing up a progress bar:
The particular library i am using (tqdm) has ways of dealing with print statements inside the loop by routing the output to a custom print function, but that means changing the print instruction itself. While i supposed that can be done inside mdfreader to deal with this particular progress bar library, i am certain it won't work in all cases.
I would argue that the best way to handle these types of messages is by returning a status message. In the case of mdfreader.resample(), the function could return the error message. If i am interested in knowing if there is any data to resample or not, i would store the result in a variable. If not, i can just not store it. This would not need any code changes in any function using this library. This might be difficult to implement seamlessly in functions which already return values (such as .getChannelData())
Another approach would be to have some sort of flag that puts the library in "quiet" mode. This would have the advantage of working seamlessly with all functions.
Sometimes, these warnings are expected and should be dealt with in code. If there is no data to resample and my script doesn't handle this correctly, it will still crash whether or not i get the warning.
Let me know what you think about this. It will obviously take some time to implement, but i think it's a good change.