4 ms·
> Blessings provides just one top-level object: Terminal. Instantiating a Terminal figures out whether you're on a terminal at all and, if so, does any necessar
by ciupicri 14y ago
> Blessings provides just one top-level object: Terminal. Instantiating a Terminal figures out whether you're on a terminal at all and, if so, does any necessary terminal setup.
Why doesn't the module figure this out at import? Since there is a single terminal (at least right now), I don't see the point of having to instantiate a class. All that stuff could be provided directly by the module. Or if there's the possibility of controlling 2 terminals simultaneously, do something similar with the random module. Provide both functions and a class that can be instantiated if needed.
- erikrose 14y agoDeferring the setup is first a matter of politeness, an artifact of my opinion that importing a module shouldn't have (possibly surprising) side effects on the environment. As for hanging everything off the Terminal instance, the motivation is that there's significant state on it that you might want to customize. Things like type (ANSI, vt100, etc.) and whether to suppress or force styling affect the result of formatting methods. See http://packages.python.org/blessings/#blessings.Terminal.__init__ http://packages.python.org/blessings/#blessings.Terminal.__i.... I've several times benefitted by making a formatting-suppressed Terminal and passing it around. I fully endorse you saying... term = Terminal() ...at the top level of some module and referencing it there. Then you get the init-on-import behavior you want, but it's not forced on anybody who'd rather not have it. Cheers!
- ciupicri 14y agoOr as The Zen of Pythons says, explicit is better than implicit. Thanks for clearing things up for me.