Asserts in Python code

[peteru]

As prl recently pointed out, there are a number of instances in the enigma2 (and plugin) Python code where "assert" is used to catch code errors. Unfortunately, these asserts have no effect, since the code is always compiled with optimisation turned on.

This is a real shame, because coding errors are not being caught in either development or production use. It would be good to convert some of these asserts into their unconditional "raise AssertionError" equivalent. There are no shortcuts here, since assignments to __debug__ are illegal.

Of course, doing this has the potential to introduce many places where code that used to silently misbehave will now crash and complain. This is both good and bad. Good for developers, because problem areas will be identified easily, bad for end users, because instead of unexpected behaviour, they may get a crash.

Opinions, suggestions, feedback?

[prl]

I think it's probably worth doing.

There are about 70 assert statements in about 35 files in the easy-ui-4 Python code.

I think it would be best to do it in stages, a few files at a time.

[MrQuade]

Are any of them going to have a time-critical impact? More incentive to treat them on a case-by-case basis.

[prl]

Are any of them going to have a time-critical impact? More incentive to treat them on a case-by-case basis.

I had a quick look at all the "assert" lines (without looking at their context), and I didn't see any that looked as though they contained an expensive test. But of course, if the cost of the test is a significant part of the cost of a loop iteration in a loop that iterates many times, you'd need to think a bit about it.

[IanSav]

Hi,

I also think it is worth the effort to force the errors to the surface so that they can be properly stomped out. Incorrectly handled error conditions are probably going to manifest as other errors and issues that will be much harder to profile and identify. (Anyone remember the issues about arrow buttons that stopped working etc.)

Are there sufficient resources available to fix the code as faults are found? Will code updates be available as online updates (rather than full USB reloads) for fast tracked updates and testing?

I would suggest that this only be done as a *special* beta series that is not in the usual place and not encouraged for regular users. Only users who are prepared to run unstable firmware and will contribute appropriate failure reports should be encouraged to run this special series of firmware.

Regards,
Ian.

[MrQuade]

If the changes are rolled out gradually in stages, I would be happy with them being rolled out in the regular beta feed. I think we have been quite spoiled by the beta stability to date, a credit to all involved

If any showstopper bugs are found, then the asserts can just be reinstated and pushed out as an interim update, while the underlying bug is found and squashed.

[peteru]

My intent would be to use the normal beta cycle to get a fairly wide exposure. Probably do this in several passes, allowing for a bit of real-world use at each stage. If errors are raised, the modus operandi would be to investigate and fix the problem, instead of rolling back. I'd probably do this mainly as online updates in order to avoid the overhead of pushing out full USB images.