On 13 August 2017 at 12:15, Nathaniel Smith <n...@pobox.com> wrote: > On Sat, Aug 12, 2017 at 6:27 PM, Yury Selivanov <yselivanov...@gmail.com> > wrote: >> Yes, I considered this idea myself, but ultimately rejected it because: >> >> 1. Current solution makes it easy to introspect things. Get the >> current EC and print it out. Although the context item idea could be >> extended to `sys.create_context_item('description')` to allow that. > > My first draft actually had the description argument :-). But then I > deleted it on the grounds that there's also no way to introspect a > list of all threading.local objects, and no-one seems to be bothered > by that, so why should we bother here.
In the TLS/TSS case, we have the design constraint of wanting to use the platform provided TLS/TSS implementation when available, and standard C APIs generally aren't designed to support rich runtime introspection from regular C code - instead, they expect the debugger, compiler, and standard library to be co-developed such that the debugger knows how to figure out where the latter two have put things at runtime. > Obviously it'd be trivial to > add though, yeah; I don't really care either way. As noted in my other email, I like the idea of making the context dependent state introspection API clearly distinct from the core context dependent state management API. That way the API implementation can focus on using the most efficient data structures for the purpose, rather than being limited to the most efficient data structures that can readily export a Python-style mapping interface. The latter can then be provided purely for introspection purposes. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/