tests/extmod/typing_*: Updates to multiple typing tests.

[Josverl]

Based on the recent discussion I updated the tests

• removed tests for typedDict as that is not implemented
• added a few tests for collections.abc that do not depend on metaclass
• cleaned up the "FIXME" messages.

With these tests I have compared the .c and the .py implementation on CPython/PEP conformance and code size.

See : micropython/micropython-lib#1051

[stinos]

Thanks! There are a bunch of tests which are now commented out like

# FIXME: CPY_DIFF : Micropython does not support User Defined Generic Classes
# TypeError: 'type' object isn't subscriptable
# class Tree(Generic[T]):

but that is actually rather simple to support in the C typing module. Probably not so in the Python typing module. Likewise commenting the 'Verify assignment is not possible' test in typing_syntax.py hides that the C typing module supports this and by doing so is compatible with CPython (List.a = None results in "TypeError: cannot set 'a' attribute of immutable type 'list'"), whereas the Python typing module probably needs extra code for that.

So I'm thinking now that (apart from actual syntax errors which make it impossible to run a file) it's probably better if no tests are commented out in order to get a more complete list of what works and what doesn't? Though by that reasoning there also shouldn't be cpydiff tests yet (again, apart from syntax errors).

[Josverl]

We can use these test to explore what is possible at what costs.
For some i expect there to be a significant size cost , at little benefit.
Ith the few changes I added to the c implentation, i saw a significant size impact, so im a bit concerned about adding more.

It would be very interesting to explore if the index notation for user defined Genetics can be supported, but I think that may be a large chunk of work and perhaps best kept for a seperate PR.
I explored that in Python, and ran into limits, to my understanding it needs changes to the compiler and base object.

[stinos]

It would be very interesting to explore if the index notation for user defined Genetics can be supported, but I think that may be a large chunk of work and perhaps best kept for a seperate PR.

To be clear, you mean the code sample I posted i.e. support Generic[T] ? Or something more elaborate? Because supporting the former syntax is only something like this in any_call_module_attr:

#if MICROPY_PY_TYPING_PEP_0586 || MICROPY_PY_TYPING_PEP_0484
if(attr == MP_QSTR_Generic || attr == MP_QSTR_Literal) {
    // To be able to support indexing like Literal[0] and Generic[T].
    dest[0] = any_call_new(&mp_type_any_call_t, 0, 0, NULL);
}
#endif

This is only POC where I'm exploring some options, didn't test if there are adverse effects, but it does pass those commented out tests and fixes some of the FIXMEs.

[Josverl]

IIUC we need a runtime implementations of metaclass, class_getitem, and mro_entries.
while metaclass can be avoided by using composition or decorators,
__class_getitem can be used for typing , but also for runtime checks.
perhaps we can keep this simple by allowing only single inheritance - but

See :

• Instantiating a Generic class returns None Josverl/micropython-stubs#806 and links from that to various places.
• https://github.com/orgs/micropython/discussions/9327,
• https://zetcode.com/python/dunder-class_getitem/

because I have not been able to get it to work at all in just .py , im also unaware of the things that might break if the runtime behavior of the 'minimal stub' is.

so perhaps we can have something that is stable enough to merge for 1.27.0
and explore further in a separate branch

A rebase would go well with that as well - ( my attempts at that failed beyond recovery)

[stinos]

Josverl/micropython-stubs#806 and links from that to various places

Hmm, right. This is a rather severe issue. And my POC exhibits similar breaking behavior: it results in not being to instantiate TestClass.

Note the following snippet also prints None when used with micropython/micropython-lib#1051 (it does happen to work correctly in my current branch with the C typing module after I've been messing around with allowing multiple inheritance but only if all inherited classes come from the typing module):

from typing import Protocol, Iterator

class TestClass(Protocol, Iterator):
    def __init__(self, attr):
        self._attr = attr

print(TestClass(34))

So just like the one issue with the decorator I found in my original PR, it seems to come down to using typing for anything but annotating (i.e. : <sometype>) might break runtime. But tests don't catch that yet.

so perhaps we can have something that is stable enough to merge for 1.27.0

I'm not sure if we can risk merging any implementation using __Ignore unless we have even more test coverage. Well, and a way to fix that which indeed is going to require some runtime support.

A rebase would go well with that as well - ( my attempts at that failed beyond recovery)

I did actually rebase everything I have on master (minus your 'extmod/modtyping: Add support for tytping aliases and typing.Literal in typing alias specifications.' commit because I was exploring other ways to do that); I'll push that already.

[Josverl]

Ill take a look at the latest, must have missed or mixed up my remotes.

Perhaps we should move the discussion to the PR to make sure that Damien is aware.
Its a balance between size and precise, and its hard to have both.