"Bug fixed" make_dataset supports dicts as input and doesn't do unnecessary save-load #65
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
, but all the realization relied on
parser
and manipulation with files, hence the actual generation from dict didn't work. I fixed it in the first commit.Just check that the key 'SEED' exists and is a 32-bit unsigned integer convertible. Try-catch blocks in C++ were super slow, not speaking of Python.
or line 310-316
both
image_paths
andimage_configurations
were declared as empty lists in lines 310,311, but one of them is appended and the other is overwritten. I copy-pasted it fromParser._get_image_locations
(to keep the same behavior), so it might be worth checking what happens if you have more than one background image (I guess only the last one will be used)make_dataset
with an optionsave_to_disk=False
the dictionaries with config files we saved to the disk anyway. The reason was that in line 405 you saved dicts and in line 411 you read them back. First, it is unnecessary, second it is a hard drive use bottleneck. I fixed this behavior in the second commit, but there is a question about the lines 352-354 in the old code.So you saved dicts to the disk, cleared them from
organizer
's class fields (as well as fromdataset.organizer
's fields), and then reread the dicts back. I don't see any reason to clear those from fields, but if there is something behind it you might want to change the behavior.Overall I would say that the logic behind the code is quite questionable. I might not know the general paradigm and underlying details, so think through the corrections I've made. To check that everything is fine I also added unit tests for the changes I've made. They don't follow your usual paradigm of unit tests, so you can delete them if they are not needed.