Skip to content
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

Add int type to num_samples on InjectTemplatesRecording. #3229

Merged
merged 34 commits into from
Aug 27, 2024

Conversation

JoeZiminski
Copy link
Collaborator

Adds a missing case for the num_samples parameter type hint on InjectTemplatesRecording. @zm711 @h-mayorquin was the consensus to change Union and Optional to | in type hints? If so should these be changed in this module?

@h-mayorquin
Copy link
Collaborator

h-mayorquin commented Jul 18, 2024

Yes, we have been using | instead of Union or Optional. I think is less verbose for Union and way more explicit than Optional.

@zm711
Copy link
Collaborator

zm711 commented Jul 18, 2024

Also we have switched to all native typing rather than the typing module types. So all the uses of List can be changed to list.

@JoeZiminski
Copy link
Collaborator Author

Great thanks both I'll make some changes to this module then request review

@JoeZiminski
Copy link
Collaborator Author

One consideration, | syntax was introduced in python 3.10. This is okay for docstring and generally won't error (I don't think) with from __future__ import annotations when run on any python version. But if we ever want to use a static type checker then it will not be possible to use it on python <3.10 or add it to pre-commit when running on version < 3.10. However, I see python 3.9 is end of life in october 2025 and I think it's extremely unlikely we will add static type checking to the CI by then. Do you think its ok to proceed?

@zm711
Copy link
Collaborator

zm711 commented Jul 18, 2024

It'll be the sixth republic before Sam let's us do static type checking. So we've worked under the from __future__ import annotations in so much of the code base that changing this would be a drop in the bucket. I wouldn't worry about it.

Copy link
Collaborator

@zm711 zm711 left a comment

Choose a reason for hiding this comment

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

numpydoc standard requires a space before the colon after an argument. So the final format is:

arg : float, default: 5.0

we put a space before the first colon since it is required for the linter, but not for the second one. This is Chris's project, but I figure we can help him out a little ;)

The recording over which to add the templates.
If None, will default to traces containing all 0.
num_samples: list[int] | int | None
num_samples: list[int] | int | None, default: None
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
num_samples: list[int] | int | None, default: None
num_samples : list[int] | int | None, default: None

Copy link
Collaborator

Choose a reason for hiding this comment

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

Should it not be optional in the case of None?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As in the default: None part? I'm not sure on this @zm711 may know, happy to make any changes as required

Copy link
Collaborator

@zm711 zm711 Jul 22, 2024

Choose a reason for hiding this comment

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

Yeah, this is an issue where we had previously agreed that None would be default: None so much of the code base has been transitioning over to that style. But more recently we had a discussion about using num_samples : list[int] | int | None, optional as an alternative style. Maybe we should add this to a maintenance meeting that way we can all discuss this in person and make sure we are all on the same page with the style. We could do a quick vote to make sure everyone agrees on which of the two styles.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nice this sounds good, I think I prefer default: None for consistency and it is clearer than optional if you don't know much about typing. If most of the code is default: None shall I leave this for now and we can discuss at the meeting?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm fine with that for now :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

All right if you find those semantics clearer.

src/spikeinterface/core/generate.py Outdated Show resolved Hide resolved
src/spikeinterface/core/generate.py Outdated Show resolved Hide resolved
src/spikeinterface/core/generate.py Show resolved Hide resolved
src/spikeinterface/core/generate.py Show resolved Hide resolved
src/spikeinterface/core/generate.py Outdated Show resolved Hide resolved
src/spikeinterface/core/generate.py Outdated Show resolved Hide resolved
src/spikeinterface/core/generate.py Outdated Show resolved Hide resolved
src/spikeinterface/core/generate.py Outdated Show resolved Hide resolved
src/spikeinterface/core/generate.py Outdated Show resolved Hide resolved
@JoeZiminski JoeZiminski changed the title Add 'int' type to 'num_samples' on 'InjectTemplatesRecording'. Add int type to num_samples on InjectTemplatesRecording. Jul 22, 2024
JoeZiminski and others added 11 commits July 22, 2024 16:22
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
Co-authored-by: Zach McKenzie <[email protected]>
@JoeZiminski JoeZiminski requested review from zm711 and h-mayorquin July 22, 2024 16:18
@JoeZiminski
Copy link
Collaborator Author

Thanks both! I've applied changes and made some further changes to docstrings, re-requested review

Number of units.
sampling_frequency : float
sampling_frequency : float, default: 30000.0 (in Hz)
Copy link
Collaborator

Choose a reason for hiding this comment

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

For these sampling frequency default values I don't know if they should be (in Hz) vs having the (in Hz) down in the actual description. So for me I would prefer:

sampling_frequency : float, default: 30000.0
    The sampling rate entered in Hz. (or samples/second)

opinions @chrishalcrow @h-mayorquin ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd personally prefer the Hz to be in the description, so that a user can copy and paste the default value and it would work.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Agree I prefer in the description I will make the change

@zm711
Copy link
Collaborator

zm711 commented Jul 23, 2024

@JoeZiminski one more discussion point and then a couple of typos :)

JoeZiminski and others added 4 commits July 24, 2024 15:04
@JoeZiminski
Copy link
Collaborator Author

Thanks @zm711! After all that talk of codespell I should actually remember to run it locally 😆

Copy link
Collaborator

@h-mayorquin h-mayorquin left a comment

Choose a reason for hiding this comment

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

LGTM

@alejoe91 alejoe91 added the documentation Improvements or additions to documentation label Aug 27, 2024
@alejoe91 alejoe91 merged commit e430774 into SpikeInterface:main Aug 27, 2024
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants