> >> Seems to me that this is a good argument for module-level properties, > >> BTW, or we require that all module attributes be set only through > >> functions. > > > > I'm not following. What do you mean by module-level properties? > > Data descriptors on module objects. I promise you will never get these. Modules are supposed to be robust and simple. If you want fancy, you can use classes and instances. > Let's suppose we have, say, a BCD module. For example, we want to > set the "global" rounding state on a per-thread basis. By > definition, modules are singletons, so there needs to be a container > within the module to hold the per-thread rounding state. Question > is, how/when do we update that container? Currently, the only > option is to require a user to call a function with the new setting > as a parameter; I can imagine cases where it would be convenient to > be able to simply set the module attribute, exactly the way we now > permit with new-style classes. Hm, why hide the mechanism? I'd say let the BCD module get an options object by explicitly asking for the current thread (or using a higher-level per-thread data facility), and let the user make a function call to set the state -- the function can request the per-thread options object and update it. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4