Guido van Rossum
Guido van Rossum
Yup. And this is why I still prefer keeping Type[] for things that are actual class objects and introducing TypeForm[] for other things that have concrete classes defined in typing.py....
On Thu, May 27, 2021 at 7:52 PM David Foster ***@***.***> wrote: > By the way,typing.Type is supposed to be deprecated since Python 3.9 > because of PEP 585. This...
> But I don't think we can change the meaning of `type[T]`, because `type` is a builtin object; changing it would be like saying that `list[T]` could be something else...
So the mentions of unboxed ints are speculative and not part of the initial implementation, right? And the tagged pointers just have their tag bit(s) removed when used in the...
Okay... So from this definition ```c #define PACK(obj) ((PyTaggedObject){.bits = (uintptr_t)obj | _Py_IsImmortal(obj)}) ``` I gather that the tag bit is (by default) only set if the object is immortal....
Nice, although this does make the code more complicated. It's already quite hard to follow what's going on -- I was mostly "programming by random modification" in the tag-strings-v2 branch.
> it'd be wise to switch recommending to using the types concrete classes where possible I can't follow this sentence. Could you elaborate, maybe by mentioning the actual attributes you're...
Oh, this is a typeshed issue. You should probably close this issue here and rely on the [typeshed issue](https://github.com/python/typeshed/pull/10816) you just opened.
What runtime changes do you propose?
Closing per Serhiy's recommendation.