Bounds can contain unions, at least.

If marshalled bounds always became strings, that would be problematic in the possible future where PEP 563 is eventually deprecated and PEP 649 takes its place.

Now, unions (at least) are picklable, so we could probably seriaze them using marshal as well (by extending that protocol slightly), and make things work that way.

But I think we may be prematurely optimizing here, and I'd rather focus on Eric's current version, where I'd like to get rid of the `__type_variables__` local variable, ideally.

At the same time I think we can put that off until the PEP has been accepted. An extra local with a dunder name is not a bad price to pay for this feature.

On Mon, Jul 11, 2022 at 9:56 AM Daniel Moisset <dfmoisset@gmail.com> wrote:

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?

D.

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

_______________________________________________
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: guido@python.org