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
Right now, if a requested extra key isn't present in the file, wellmap just pretends like that key wasn't requested. This is pretty bad behavior, because it makes the return signature depend on the input file.
The question is how to better handle missing extra keys. Some options:
Return None or {} for missing keys. This isn't great, though, because these won't be sensible defaults in all cases.
Allow the extras argument to be a {key: default} dictionary, and error out if we find a missing key without a default. This is backwards compatible, but adds a lot of complexity to the API (including the need to deal with mutable default values).
Always return the extras as a dictionary. Missing values would simply not be present, and the user would have to deal with that. This is simpler than #2, but breaks backwards compatibility and complicates the case where only a single extra is requested.
Make the extras argument a simple boolean, where True just means to return a dictionary of all the non-wellmap fields. Or I could even include the wellmap fields; maybe there's some use for that. This avoids forcing the user to specify the same key twice (a smell with #3), but also breaks backwards compatibility.
The text was updated successfully, but these errors were encountered:
Right now, if a requested extra key isn't present in the file, wellmap just pretends like that key wasn't requested. This is pretty bad behavior, because it makes the return signature depend on the input file.
The question is how to better handle missing extra keys. Some options:
None
or{}
for missing keys. This isn't great, though, because these won't be sensible defaults in all cases.{key: default}
dictionary, and error out if we find a missing key without a default. This is backwards compatible, but adds a lot of complexity to the API (including the need to deal with mutable default values).True
just means to return a dictionary of all the non-wellmap fields. Or I could even include the wellmap fields; maybe there's some use for that. This avoids forcing the user to specify the same key twice (a smell with #3), but also breaks backwards compatibility.The text was updated successfully, but these errors were encountered: