search

spatialaudio / python-sounddevice

:sound: Play and Record Sound with Python :snake:
https://python-sounddevice.readthedocs.io/
MIT License
980 stars 145 forks source link

Type annotations #398

Closed vrslev closed 2 years ago

vrslev commented 2 years ago

Hey there! Are there plans to add type hints? Also, Python 3.6 reached end of life.

mgeier commented 2 years ago

I don't have any experience with type hints and I don't have any plans to add them myself.

If it's not just for the sake of it (i.e. if it has real benefits) and if it doesn't hurt non-type-hint usage, I'm open to someone adding them.

It's important that the usage of NumPy stays optional, though. I don't know how something like "array-like" can be specified without importing NumPy?

Also, there are some specific CFFI types involved (e.g. "buffers"), I don't know how they should be handled.

I would appreciate a little "proof of concept" before making a huge PR for the whole API.

Also, Python 3.6 reached end of life.

Thanks for the heads-up. What needs to be done?

vrslev commented 2 years ago

What needs to be done?

Update CI, change metadata in setup.py, optionally run pyupgrade. I can send a PR ☺️

vrslev commented 2 years ago

I will work on proof of concept 🙏

vrslev commented 2 years ago

@mgeier Just looked at code base. I think there's a lot of things that need to be changed to support type hints. First things that catches the eye: code repetition and code structure. Are you up to this?

mgeier commented 2 years ago

Good question! I don't know, it depends on the concrete changes.

I'm always open for improvements, but the definition of "improvement" is often a matter of taste ...

Removing code repetition seems like a good idea, independent of type annotations. Do you have an example?

"code structure" sound a bit vague, can you clarify?

vrslev commented 2 years ago

Highly dynamic behavior is considered antipattern in modern Python (someone would argue I suppose) and is almost impossible to be type checked. By that I mean things like removing self from locals to pass params to super().__init__. Also I noticed big if-blocks in stream base that could be moved to more specialized classes.

Regarding code structure, it would be easier to maintain and refactor code that is split to modules, IMHO.

vrslev commented 2 years ago

Path of annotating an existing code base is hard and long anyway 😅