Looking in Inventory.py, another section which can probably be shortened:
if len(List_Equip) > 0:
for Equipment in List_Equip:
If the length of
List_Equip is 0, then the loop should be skipped entirely anyway, so the
if doesn't provide any real protection. This can be shortened to just:
for Equipment in List_Equip:
If there is a chance that
List_Equip is not an iterable object, then you may want an
if guard. However, by testing
len(List_Equip) > 0, you're already making an assumption that it is iterable (or at least that it provides a length). Not to mention the variable has "List" in the name, so if it represented anything other than an iterable list, you've got bigger problems.
If for some reason you have a nullable type, which might represent a list, or might represent a null value, then it may make some sense to test first. Same if you have a variant type, where the type can change, so you can't know if any given property will exist. For more on that, you might consider reading:
How to know if an object has an attribute in Python
I would pay particular attention to the discussion of look before you leap versus asking for forgiveness rather than permission. It seems idiomatic Python may be to catch exceptions after the fact, rather than test for the existence of a property before hand.
Here is another example where an
if test seems to be making an assumption about the value which it seeks to protect from:
if Equipment.equipment.melee_damage_bonus > 0:
Melee_Damage += Equipment.equipment.melee_damage_bonus
Presumably not all objects are weapons, and so not all objects will have
melee_damage_bonus, and so you're only adding in the bonus for objects of the correct type. However, the
if test accesses this field and compares against 0, and so implicit is an assumption that
melee_damage_bonus exists as a field, and is a number. Assuming the only problem number is 0, you can just add it anyways, as it won't change the result. If objects that aren't weapons will have
melee_damage_bonus set to 0, adding it unconditionally is still correct. I'd recommend just using:
Melee_Damage += Equipment.equipment.melee_damage_bonus
Granted, the results are different here if negative values are allowed. I assume they aren't, or if they were allowed, they maybe should have been added in anyway.
A possible exception to the above, some languages will return a null value for fields that don't exist, rather than throw an error, and some languages can have unexpected comparisons when dealing with certain values, such as infinity, non-a-number (NaN), or null. As an example, if
melee_damage_bonus was set to NaN, you might not want to add in the bonus. And as a cool effect, infinity should compare greater than 0, so that will be added in as a bonus.