Yes, my suggestion was to "stringify" bounds (PEP-563 style) to make them serializable. I understand that this limits introspection slightly, but do we think that the live class information will be actually used for bounds of typevars? Currently it is legal to have a bound set as a string anyway, and bounds have a lot of restrictions (they can not use typevars themselves, and I don't think they can be special forms) so most of the time evaluating them with a global namespace (for a function f, it's f.__globals__) will give you the right answer if you really want a class object.

So yes, my suggestion introduces a limitation, but is that limitation relevant in any real scenario?

On Mon, 11 Jul 2022 at 00:01, Eric Traut <eric@traut.com> wrote:

Thanks for the tips, Daniel. Those were really helpful.

As Guido said, I don't think we can construct type variables at compile time because we need to evaluate bound expressions at runtime.

I incorporated your other suggestions, and this allowed me to eliminate the two pointers in the frame object! I still require a new pointer in the function object, but it's optional and will be NULL most of the time.

My latest implementation can be found here: https://github.com/erictraut/cpython/tree/type_param_syntax2

This implementation makes use of a local variable named "__type_variables__". This name will show up in the locals if you call "get_locals()", which is an unfortunate leakage of an implementation detail. I looked for ways to make this variable completely anonymous, but I didn't see a way of doing this without significant changes to the compiler. Of course, we could allocate a dedicated pointer within the frame like I was doing previously, but I was trying to avoid this.

-Eric
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: dfmoisset@gmail.com