On Sat, Aug 12, 2017 at 9:05 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> 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.

Excellent point.

>> 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.

Also an excellent point :-).


Nathaniel J. Smith -- https://vorpus.org
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to