Conversation
Config
ConfigConfig
|
|
||
| CURRENT_PLATFORM = platform.system() | ||
| try: | ||
| assert CURRENT_PLATFORM == "Darwin" |
There was a problem hiding this comment.
so this will catch all Mac OS? Have you also tested the bug in non-Mac OS? Why is it that python is connected to Mac and all others use c?
| simulation results of SED documents | ||
| SAVE_PLOT_DATA (:obj:`bool`, optional): whether to save data for plots alongside data for reports in CSV/HDF5 files | ||
| REPORT_FORMATS (:obj:`list` of :obj:`str`, optional): default formats to generate reports in | ||
| REPORT_FORMATS (:obj:`list` of :obj:`str`, optional): default formats to generate reports in-->defaults to 'csv' |
There was a problem hiding this comment.
This PR sets the default to None
There was a problem hiding this comment.
I originally was generating the value of REPORT_FORMATS to have a default constructor setting of [ReportFormat.csv] (formats are of type(enum.Enum)), or even [ReportFormat.h5]. Our good friend SonarCloud complained about this definition, which makes sense as the definition is also performing a very basic operation other than just instantiation. This doc string annotation was from when I had it in the definition and must have missed it.
There was a problem hiding this comment.
After review, that doc string is actually as I intended it to be. Following the logic of the constructor, if there is no value for the REPORT_FORMATS attribute upon instantiation, it defaults to 'csv'. As per the constructor: self.REPORT_FORMATS = REPORT_FORMATS or [ReportFormat.csv], which evaluates roughly as:
if not REPORT_FORMATS:
REPORT_FORMATS = [ReportFormat.csv]
| self.SAVE_PLOT_DATA = SAVE_PLOT_DATA | ||
| self.REPORT_FORMATS = REPORT_FORMATS | ||
| self.VIZ_FORMATS = VIZ_FORMATS | ||
| self.REPORT_FORMATS = REPORT_FORMATS or [ReportFormat.csv] |
There was a problem hiding this comment.
Hah, I saw this and thought it was an actual csv file rather than a csv attribute of ReportFormat.
There was a problem hiding this comment.
You know, I did at first as well! As I mentioned, I moved the logic for this inside the actual constructor as per SonarCloud.
| DEBUG=False): | ||
| DEBUG=False, | ||
| STDOUT_LEVEL=DEFAULT_STDOUT_LEVEL, | ||
| **CUSTOM_SETTINGS): |
There was a problem hiding this comment.
using the ** I see. kind of dangerous that anything can come in here and will be applied to the settings. Do you have examples of what kind of kwargs might be used?
There was a problem hiding this comment.
This was a part of my original implementation in an idea that I had. As you can see starting at line 181, these **kwargs become unpacked in the private method __getcustomsettings() and returned as a dict in the attribute CUSTOM_SETTINGS. I realize the danger of arbitrarily using unpacking, but I have funneled it into a collection.
There was a problem hiding this comment.
Devising some presentable use cases now to plead my case, hah.
|
I left some comments, this is looking pretty close. What's failing in the CI? |
|
Kudos, SonarCloud Quality Gate passed!
|
I just need to take care of some linting errors in this case. |
AlexPatrie
left a comment
There was a problem hiding this comment.
I am going to add an example use case for the unpacking **CUSTOM_SETTINGS.
| DEBUG=False): | ||
| DEBUG=False, | ||
| STDOUT_LEVEL=DEFAULT_STDOUT_LEVEL, | ||
| **CUSTOM_SETTINGS): |
There was a problem hiding this comment.
This was a part of my original implementation in an idea that I had. As you can see starting at line 181, these **kwargs become unpacked in the private method __getcustomsettings() and returned as a dict in the attribute CUSTOM_SETTINGS. I realize the danger of arbitrarily using unpacking, but I have funneled it into a collection.
| DEBUG=False): | ||
| DEBUG=False, | ||
| STDOUT_LEVEL=DEFAULT_STDOUT_LEVEL, | ||
| **CUSTOM_SETTINGS): |
There was a problem hiding this comment.
Devising some presentable use cases now to plead my case, hah.
| simulation results of SED documents | ||
| SAVE_PLOT_DATA (:obj:`bool`, optional): whether to save data for plots alongside data for reports in CSV/HDF5 files | ||
| REPORT_FORMATS (:obj:`list` of :obj:`str`, optional): default formats to generate reports in | ||
| REPORT_FORMATS (:obj:`list` of :obj:`str`, optional): default formats to generate reports in-->defaults to 'csv' |
There was a problem hiding this comment.
I originally was generating the value of REPORT_FORMATS to have a default constructor setting of [ReportFormat.csv] (formats are of type(enum.Enum)), or even [ReportFormat.h5]. Our good friend SonarCloud complained about this definition, which makes sense as the definition is also performing a very basic operation other than just instantiation. This doc string annotation was from when I had it in the definition and must have missed it.
| self.SAVE_PLOT_DATA = SAVE_PLOT_DATA | ||
| self.REPORT_FORMATS = REPORT_FORMATS | ||
| self.VIZ_FORMATS = VIZ_FORMATS | ||
| self.REPORT_FORMATS = REPORT_FORMATS or [ReportFormat.csv] |
There was a problem hiding this comment.
You know, I did at first as well! As I mentioned, I moved the logic for this inside the actual constructor as per SonarCloud.








What new features does this PR implement?
Please summarize the features that this PR implements. As relevant, please indicate the issues that the PR closes.
Adds Optional default setting for StandardOutputCapturerLevel to Config object through a validation block. Adjusted default setting from "c" to "python" (resolves dependency on
capturer#135)Adds type annotations to functions
What bugs does this PR fix?
Please summarize the bugs that this PR fixes. As relevant, please indicate the issues that the PR closes.
How have you tested this PR?
Pytest, and self testing.