Give Your Data a Shape

The order processing code has a problem, and Priya is the one who found it. A customer placed an order with a negative quantity. The system accepted it, calculated a negative total, and the finance team spent half a day figuring out why the daily revenue was three hundred dollars lower than expected. When Priya traced it back to the source, she found the order stored as a dictionary: a grab bag of keys and values with no rules about what could go in. Dictionaries do not say no. They accept whatever you give them. A quantity of minus five? Sure. A price that is actually a string? No problem. A customer name that is somehow an empty list? Welcome aboard. The data looks fine until something downstream explodes, and by then you are debugging three layers away from the actual mistake. Priya's tech lead fixed it by wrapping the order in a class. There was an `__init__` method that validated the quantity on creation, a `total` property that calculated itself, and an `__eq__` method she did not understand at all. The PR description said "orders should be objects, not bags of data." She approved it because she trusts her tech lead. She did not understand why a class was better than just adding an if-statement to check for negative quantities. That question — why does the data itself need to know its own rules — is what separates someone who uses Python from someone who thinks in it.