Skip to content
New issue

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

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

Already on GitHub? # to your account

Allow a "no-image" mode for mosviz #502

Merged
merged 3 commits into from
Apr 12, 2021
Merged

Allow a "no-image" mode for mosviz #502

merged 3 commits into from
Apr 12, 2021

Conversation

ibusko
Copy link
Contributor

@ibusko ibusko commented Apr 6, 2021

The Mosviz example notebook exercises this mode.

@ibusko ibusko requested review from javerbukh and rosteen April 6, 2021 15:00
Copy link
Contributor

@javerbukh javerbukh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I imagine the next step is to remove the image viewer but I understand that will be a significant amount of work and should be tracked separately.

@ibusko ibusko requested a review from duytnguyendtn April 7, 2021 14:51
@havok2063
Copy link
Collaborator

Since this was something I've requested, I've also tested this. It minimally works. I think the images keyword argument should be made optional, possibly with just images=None. I'm not sure how easy it is to disable/enable viewers, but one could imagine a workflow where the image viewer is enabled/disabled when the images keyword parameter is specified or not.

Copy link
Collaborator

@rosteen rosteen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me, but I think I agree with @havok2063 that if the images are optional, the argument in load_data should be images=None so that it defaults to None instead of needing explicit input of None.

And as @javerbukh said, potentially removing the image viewer in this case is on our radar but was decided to be out of scope for this particular PR.

@ibusko
Copy link
Contributor Author

ibusko commented Apr 9, 2021

I agree that the images argument should be optional and default to None, but only if that is the most frequent way users are going to use MosViz. From my previous interaction with this app, I thought the intended default way is to be used with images (as when reading from a mos table), and in that case the no-images mode would be optional.

Maybe we need PO advice here?

@duytnguyendtn
Copy link
Collaborator

I'm personally in the opinion that the software should try its best given what the user gives it. In that case, I'd be in opinion of not requiring images=None

@ibusko
Copy link
Contributor Author

ibusko commented Apr 9, 2021

I modified load_data to have images=None by default.

Copy link
Collaborator

@rosteen rosteen left a 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

"metadata": {},
"outputs": [],
"source": [
"mosviz.load_data(spectra_1d, spectra_2d, images=images)\n",
Copy link
Collaborator

@rosteen rosteen Apr 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note that you can still use the old syntax here, you don't necessarily have to name the images argument. Maybe we actually want to keep this line as-is (I say, having already approved the PR)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, writing it explicitly ensures the user gets the point that it's an optional argument.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! Merging...

@rosteen rosteen merged commit 90c755a into spacetelescope:main Apr 12, 2021
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants