Moved the RT fmrisim generator and updated it to use resource stream#460
Conversation
|
@mihaic Hi Mihai, I am running into issues with using |
|
After many pep8 errors, I now have new errors I am not sure about. The first one throws an error because I do not have enough arguments, but that is precisely the test I am running that should be caught by the pytest command. Is that because it is not in a function? The other errors are peculiar. Is it something about how the dictionary data type is being altered by being supplied a resource stream? |
|
Yes, testing for raised exceptions should be part of Pytest functions. However, the current errors are raised by Mypy assumes all the values in data_dict['ROI_A_file'] = resource_stream(gen.__name__,
"sim_parameters/ROI_A.nii.gz")You can avoid it by explicitly specifying a type for for from typing import Dict
data_dict: Dict = {}You can disable type checking for any line by adding a gen.generate_data() # type: ignore |
|
@CameronTEllis, in case you are baffled by the current error, note that import gzip
roi_a_file = resource_stream(__name__, "ROI_A.nii.gz")
image = nibabel.nifti1.Nifti1Image.from_bytes(gzip.decompress(roi_a_file.read())) |
|
@mihaic Hmm still strange errors. this one seems to be a version issue perhaps: from_bytes was added recently. This solution is also quite cumbersome, are there alternative solutions to find the path to something in the resource stream so that it can be treated as a path? |
|
It is cumbersome, but you have implemented it already. :) You can try the following for the import error: from nibabel.nifti1 import Nifti1Image
_from_bytes = Nifti1Image.from_bytesNote that I wrote |
|
I recommend changing the signature of def from typing import Any, Dict
def generate_data(
output_dir: str,
data_dict: Dict[str, Any],
roi_a_file: str = None,
roi_b_file: str = None,
template_path: str = None,
noise_dict_file: str = None,
) -> None: |
|
Hmm I am not familiar with this style of signature. But separate from that, how does this solve the problem? If |
|
I should not have changed the style, sorry about that. (The style follows PEP 484, as mentioned in our contributing documentation.) My suggestion is to move the code from |
|
Sorry I am still confused. The resource stream call I do to get the text file from The whole reason we got into this resource stream business is because I need a way to read the files that are in the Using these files should be the default behavior but users can specify other paths if they want to. Incorporating |
|
Right, you cannot use text_in_noise_dict_file = resource_stream(__name__, "sub_noise_dict.txt").read().decode()You can keep Note that you should change the test code to pass There are other ways to read data files shipped with Python packages, but I recommend we continue using |
|
@mihaic Hi I assumed that the temp path that was created would be a string but it seems to be a |
|
Indeed, |
|
@mihaic is this saying there is an indent on line 11 of the docstring? If so, I don't see it: there are no characters on that line |
|
First, congrats for getting Pytest to succeed! The line numbers in docstring errors are misleading, because they refer to the docstring, not the file. We documented this issue some time ago, but unfortunately we still do not have a solution: In this case, the file line number is 11 + 3 (the start of the the docstring) = 14:
Remember that docstrings must follow the Sphinx format. In particular:
Note that the text documenting the |
|
@mihaic Suggestions on how to resolve the Python 3.5 vs 3.6 issue? Seems like a different solution is needed for this dictionary mem map issue |
|
I forgot that type annotations for variables were only introduced in Python 3.6. Let's maintain compatibility with Python 3.5 for the moment. Please change to: data_dict = {} # type: Dict |
gdoubleyew
left a comment
There was a problem hiding this comment.
Cameron, looks good! Thanks for making all these default settings, that will make it very easy to get started using. Also, thanks for making all the test functions.
|
Thanks, @CameronTEllis & @gdoubleyew. Note that I changed from The Conda error we were seeing was caused by |
No description provided.