-
Notifications
You must be signed in to change notification settings - Fork 2
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
fix: isolate data pull #80
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've some general comments on this! Let me know what you think.
|
||
class case_ID: | ||
"""docstring for case_ID""" | ||
|
||
def __init__(self, track_name): | ||
import re |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be a good idea to move this import to the top of the file – you can get weird behavior with imports in function bodies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hollandjg Would you care to elaborate on this? Some authors say it's okay to import on demand unless the functions/methods are called many times and/or importing takes a non-negligible amount of time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure! This is just the recommendation from PEP8:
Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
They write at the top:
A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is the most important.
However, know when to be inconsistent – sometimes style guide recommendations just aren’t applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don’t hesitate to ask!
If there's a strong reason to import in the function body, of course we can disregard PEP8. I don't see there being a strong reason here (but if there's something you all see that I don't, then no problem).
Some of the weird behavior I've seen in the past was stuff like:
- You're trying to compare whether two equivalent objects are equal and they look equal, but they don't act equal because they weren't created from the same copy of the imported package.
- You set a breakpoint in a function, but it never gets hit because the debugger doesn't see the imported files as the same.
Other things I could imagine:
- There's some code which runs when the module is imported and is only meant to be run once, but because it's imported multiple times it runs more than once and leads to a weird state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about rename the io.py file
to icesat_io_tools.py
? vscode can refactor all the dependencies in the project.
What about |
- Refactor getATL03_beam: Simplified the logic of the function to improve readability and performance - Update case_ID class: Add comments to clarify the purpose and functionality of the class. Also, simplified some of its logic for better performance and readability - Use pathlib where appropriate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
Changes:
io
module for testing purposesRename io.py #83