I've recently been looking into how Curses works in Python. I've followed the tutorial here: Curses Programming with Python, and I have successfully messed around with their code to properly output text to various locations in a console screen.
My question is:
Why are some functions attributes of the module, e.g. curses.noecho()
but other functions are attributes of a screen object, e.g. sreen_instance.keypad(True)?
It would make sense to me to have the screen instance specify things like noecho() or cbreak(), rather than the module.
What is the reasoning behind this, and is there any general rule to recognize whether a function should be an attribute of the module, or an attribute of an instance of an object within the Curses library?
Notwithstanding the name "stdscr" as "standard screen", that is a curses window (and it is the top-level window in case there are subwindows).
The attributes are at the curses-level or window-level because that's how the corresponding functions are organized in curses. Most of the Python binding has the same name and similar parameters to the C library (allowing for optional parameters in the Python binding which reduce the number of names used, e.g., for addstr in Python versus waddstr in C).
To see how that works, I'd simply look at the curses C interfaces: anything that uses a WINDOW* parameter (counting aliases such as getch() as wgetch(stdscr)) would be implemented in the Python binding as a window attribute (or function), while those that do not use a WINDOW parameter would be a curses attribute (or function).