Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option for issue-126: General approach to empty string parameter values #137

Merged
merged 1 commit into from
Dec 10, 2020
Merged

Option for issue-126: General approach to empty string parameter values #137

merged 1 commit into from
Dec 10, 2020

Conversation

dcslagel
Copy link
Contributor

This pull-request is a draft of one of the alternative options discussed in pull-request #134 (for fixing #126).

On reading from_las() and from_lasio() if a header field/mnemonic is an empty string convert it to python's None type.

This could be good because it would be a general rule applied to all fields/mnemonic and any changes in subsequent code to handle this would be consistent across Welly. There may be other impacts that are less favorable if processing of other fields/mnemonics expect a str object. A draft implementation could be interesting.

This draft further constrains the values changed to the parameter section and to those fields/mnemonics without a unit setting. It is limited to the parameter section just to limit any unknown impact. It would be opened up to cover other sections. The reason for limiting to fields/mnemonics without a unit setting, is that items with a unit setting are likely to be numbers and handled elsewhere.

Let me know if this change could be accepted (or rejected) or
needs some additional changes before being approved and merged.

Thank you,
DC

- At well.read_lasio() convert empty string param values without a unit to None
- Include tests for this change in tests/test_location.py
@kwinkunks kwinkunks merged commit 3066d51 into agilescientific:develop Dec 10, 2020
@kwinkunks
Copy link
Member

Apologies for this taking me so long to get to... I finally made some time to work on welly this week. I think this looks like a good solution, and a sensible way to deal with the issue. Thank you!

@dcslagel
Copy link
Contributor Author

Hey @kwinkunks,

Great! Thank you for getting to back to this. I appreciate it. :-)

We can close the other two pull-requests that were other approaches for this issue: #134 and #136. In relooking at them now in retrospect, this one does feel like the better approach of the 3.

Thanks!,
DC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants