Conversation
This way we still end up with the same data type to operate on -> avoid type errors
|
Hey @andybotting just wondering your thoughts on this :) |
|
Have you had errors with this previously, or is it just to make it easier for testing? Either way, I think it looks OK. Defensive coding is always a good thing |
andybotting
left a comment
andybotting
left a comment
There was a problem hiding this comment.
Couple of comments, but the code is good 👍
lib/aussieaddonscommon/utils.py
Outdated
| return xbmc.getInfoLabel("System.BuildVersion") | ||
| except Exception: | ||
| return | ||
| return '' |
There was a problem hiding this comment.
Returning None is usually best if you're going to later test it with if build: for example. As you've done here, an empty string also evaluates to False. Does this necessarily need to be a string?
There was a problem hiding this comment.
You're right - the changes in get_kodi_version make this redundant, I'll make it None.
lib/aussieaddonscommon/utils.py
Outdated
| """Return the major version number of Kodi""" | ||
| version = get_kodi_version().split('.')[0] | ||
| return int(version) | ||
| if version: |
There was a problem hiding this comment.
Looks like version should never evaluate to False from get_kodi_version(), so this change might not be that useful?
There was a problem hiding this comment.
Yeah I worked from this function upwards, should have come back to look at it again!
I've been checking the major version in a couple of cases recently, for either inputstream adaptive version checking or testing whether I can use more recent Kodi Python API calls. What got me thinking about safeness is that I remember from a couple of years ago there was one of the |
2 participants
This way we still end up with the same data type to operate on -> avoid type errors