Skip to content

Conversation

@hoechenberger
Copy link
Member

@hoechenberger hoechenberger commented Dec 14, 2023

This is a follow-up to #12250

There, I suggested we don't need to add return type hints to read_raw_*(), because Pylance infers the return type for those functions. Now, working on type stubs, I realized that as soon as stubs for a function are present, Pylance won't infer the return type from the implementation anymore. Hence, this forces us to add return types, or else the UX will degrade in the presence of stubs.

I therefore added return type hints for

  • read_raw_*()
  • read_epochs()
  • read_annotations() (for which I also corrected the docstring, which stated an incorrect return type)

I had to annotate via strings (names of the classes) in many places because the reader functions appeared before the actual class definition, i.e. I had to make a forward reference.

@larsoner I had to disable MyPy's strict testing, because with strict it reports errors in functions and classes that are not even annotated yet. I'd be +1 for keeping strict=false, but feel free to take a look yourself if you have time, thanks!

Returns
-------
annot : instance of Annotations | None
annot : instance of Annotations
Copy link
Member Author

Choose a reason for hiding this comment

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

we actually raise if annot is None

@hoechenberger
Copy link
Member Author

Thanks for the fixes, Eric

@cbrnr
Copy link
Contributor

cbrnr commented Dec 14, 2023

Is it really necessary have separate classes for each file format?

@larsoner
Copy link
Member

larsoner commented Dec 14, 2023

Yes based on how EDIT: subclassing of BaseRaw works

@cbrnr
Copy link
Contributor

cbrnr commented Dec 14, 2023

OK. But really we could subclass BaseRaw -> Raw, i.e. every reader uses the same subclass.

@larsoner
Copy link
Member

every reader uses the same subclass

Every reader does currently use the same subclass, BaseRaw. Raw is really an alias for RawFIF because historically we documented everything there. I don't think there is much usability gain from fixing this and it would be a lot of doc / redirecting work potentially to rework the doc processes behind this

@cbrnr
Copy link
Contributor

cbrnr commented Dec 14, 2023

No, they use RawArtemis123, RawBOXY, RawCTF...?

@larsoner
Copy link
Member

No, they use RawArtemis123, RawBOXY, RawCTF...?

Sorry what I mean is that those are all subclasses of BaseRaw, and that they all have the same super class

@larsoner larsoner enabled auto-merge (squash) December 14, 2023 20:27
@larsoner
Copy link
Member

Local doc build is green and looks good, marking for merge when green, thanks @hoechenberger !

@cbrnr
Copy link
Contributor

cbrnr commented Dec 14, 2023

Sorry what I mean is that those are all subclasses of BaseRaw, and that they all have the same super class

Yes, but what I meant was, why can't they all just be Raw (or whatever derived class we are using).


@verbose
def read_raw_curry(fname, preload=False, verbose=None):
def read_raw_curry(fname, preload=False, verbose=None) -> "RawCurry":
Copy link
Member

Choose a reason for hiding this comment

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

question from a type-hints n00b: why is "RawCurry" a string here? Some of the other type hints like RawEDF are not strings, but references to the Class object.

Copy link
Member Author

Choose a reason for hiding this comment

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

See my top comment:

"I had to annotate via strings (names of the classes) in many places because the reader functions appeared before the actual class definition, i.e. I had to make a forward reference."

It's ugly, but I wanted to avoid having to re-order the code.

Thoughts on this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes. Rearrange the code 😄.

Copy link
Member

Choose a reason for hiding this comment

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

oops, sorry! I did read the PR description but somehow my eyes skipped right over that sentence. Let's leave it as-is for now, someone can do the copy-paste reordering later in a commit that we can add to .git-blame-ignore-revs

@hoechenberger
Copy link
Member Author

Disabling auto merge while waiting for feedback from @drammock

@drammock drammock enabled auto-merge (squash) December 14, 2023 20:55
@drammock drammock merged commit 35f0ef6 into mne-tools:main Dec 14, 2023
@hoechenberger hoechenberger deleted the typings branch December 14, 2023 21:37
hoechenberger added a commit to hoechenberger/mne-python that referenced this pull request Dec 15, 2023
Also clean up a little after mne-tools#12296, where I accidentally put a few return types in quoation marks that were, in fact, no forward references.

Also updated the changelog.
snwnde pushed a commit to snwnde/mne-python that referenced this pull request Mar 20, 2024
…ations()` (mne-tools#12296)

Co-authored-by: Eric Larson <larson.eric.d@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants