mirror of https://github.com/zulip/zulip.git
eee02a3403
An additional check for whether customer.stripe_customer_id is None is added to the function. That check was not really required before since all the customers with a plan also have a valid value for stripe_customer_id. So all the calls to stripe.Invoice.list would have non None value for customer argument. Even though that is the case, mypy should still have complained about the possibility of customer.stripe_customer_id being None when passed to stripe.Invoice.list as customer paramater since mypy don't know that customers with a plan will always have a non empty value for stripe_customer_id. Our stripe stubs expect a non empty value for the customer parameter of stripe.Invoice.list. This is despite the fact that stripe.Invoice.list can actually be called with customer set to None. This returns the invoices from the entire organization. Though, we still decided to ensure that the value of customer should be non empty since there is no reason for us to ever call this function with customer set to None. You can just call the function wuthout the customer argument instead. So this requirement of a non None customer paramater is useful for catching bugs. The reason mypy didn't complain was because the type of Customer.objects.all() is Any and not QuerySet[Customer]. So mypy has no idea that customer.stripe_customer_id can be theoratically None even though it was not possible in this [articular case as explained before. I verified that this was the reason mypy didn't complain by using the reveal_type function on Customer.objects.all() and the customer object. After the refactoring it's super to obvious to mypy that the type of the customer is Customer since it's mentioned in the function defintion. So it was able to complain about the possibility of customer.stripe_customer_id being None after the refactoring. |
||
|---|---|---|
| .. | ||
| stripe_fixtures | ||
| __init__.py | ||
| test_stripe.py | ||