> > Aahz: > >> Hrm. While I don't want to overload what looks like a simple PEP, I'd > >> like some thoughts about how this ought to interact with thread-local > >> storage (if at all). There are some modules (notably the BCD module) > >> that need to keep track of state on a per-thread basis, but without > >> requiring a user of the module to do the work. > On Wed, Apr 23, 2003, Guido van Rossum wrote: > > IMO you can do thread-local storage just fine by attaching private > > attributes to threading.currentThread(). Aahz: > Agreed -- *if* Jeremy goes for your threading-only solution. If this > PEP hooks in at a lower level, that's going to require that everything > else built on top of threads work at a lower level, too. Well, I think it's fair to say that you should use the higher-level threading module if you want higher-level concepts like thread-local storage. (A poor name IMO; it would be better to call it "per-thread data".) > 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? --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