-
Notifications
You must be signed in to change notification settings - Fork 70
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
Don't hide common classes / hide imports #22
Comments
I don't quite understand your comment. What exactly are you trying to do, and what do you think SoundCard is doing wrong? |
It isn't doing anything wrong, but if one wants to explore a module, it is helpful to hide imports that the developer does not need to see. I changed everything except numpy to start with underscores: import soundcard as sc
sc._Speaker raised an |
There's a reason for the underscores on As for renaming common imports, do you have a reference for this? I know this practice exists, but I find it profoundly ugly. Could you accomplish a similar goal by specifying an |
One use case: I was trying to use type annotations for functions that passed around
Yes, The main downside of |
For reference, I've been using this: __all__ = (
'_Microphone',
'_Player',
'_Recorder',
'_Speaker',
'all_microphones',
'all_speakers',
'default_microphone',
'default_speaker',
'get_microphone',
'get_speaker',
) (those are the classes that appears to be common, but I've only tested on windows) |
Yes, type annotations are a good reason for accessing these. But then, I think |
If anyone cares enough about this to contribute a pull request, I'll be happy to merge it. |
If trying to create a higher level script with custom classes, it is helpful to have direct access to the common classes of SoundCard, e.g.:
The text was updated successfully, but these errors were encountered: