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
It's not unlikely that I will want to add even more information like this in the future, too. It's already a bit unwieldy to keep track of what values are returned by load() in what order, and this will only get worse as more and more optional return values are added. Therefore, I think I should move to a signature that wraps all of this information into a single object. That way, adding new information will just mean adding a new attribute to this object; the signature of load() won't change.
Here's some pseudocode for what I have in mind:
defload(path, meta=False):
# Load the layout in the usual way...meta_obj=Metadata(
extras=extras,
deps=deps,
...
)
ifmeta:
returndf, meta_objelse:
returndf
This would be a backwards-compatible change as long as I don't get rid of the current options. I would want to deprecate them, though, since they would just be making the code more complicated for no benefit.
The text was updated successfully, but these errors were encountered:
Right now,
load()
has two arguments which cause additional information to be returned:extras
: Return any keys from the TOML file that wellmap didn't use.report_dependencies
: Return a list of all the files that were read.A few recent issues suggest that more information is needed:
meta.style
: see Option to superimpose labels on wells #24It's not unlikely that I will want to add even more information like this in the future, too. It's already a bit unwieldy to keep track of what values are returned by
load()
in what order, and this will only get worse as more and more optional return values are added. Therefore, I think I should move to a signature that wraps all of this information into a single object. That way, adding new information will just mean adding a new attribute to this object; the signature ofload()
won't change.Here's some pseudocode for what I have in mind:
This would be a backwards-compatible change as long as I don't get rid of the current options. I would want to deprecate them, though, since they would just be making the code more complicated for no benefit.
The text was updated successfully, but these errors were encountered: