You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See line 87 above in the importer class, there is a lot of dict/key usage, often several levels like:
for vendor in data["affects"]["vendor"]["vendor_data"] and then again for products in vendor["product"]["product_data"].
Shouldn't we probably use something like the AdvisoryData classes (or a special subclass for that) which would model the advisory data directly, and then use those classes everywhere instead of dicts. This has some advantages:
code would be more pythonic and readable (and better looking)
we can and should test for the advisory format and handle keyerrors gracefully (idk if the data format changes that much at all, but it could in future?)
for vendor in data["affects"]["vendor"]["vendor_data"]
and then againfor products in vendor["product"]["product_data"]
.Shouldn't we probably use something like the
AdvisoryData
classes (or a special subclass for that) which would model the advisory data directly, and then use those classes everywhere instead of dicts. This has some advantages:Originally posted by @AyanSinhaMahapatra in #1102 (comment)
The text was updated successfully, but these errors were encountered: