Repository navigation
Conversation
|
For some reason (circularity?) the tests do not recognize |
|
How do I test changes to typeshed? |
|
Typeshed has a travis build that does some minimal consistency checks. I think that there's a script you can also run locally, but I haven't tried that. You can also run the mypy test suite locally against your typeshed changes. More generally, you can write some dummy code that uses your changed stubs and manually try to verify that type checking and running a program seem compatible. If your typeshed and mypy changes happen to depend on each other for a clean build, you'll probably want to coordinate them with a mypy core dev, as one of the builds may have to be red at least momentarily until both changes have been merged. |
|
Thanks |
| pass | ||
| takes_some_ext_int_enum(SomeExtIntEnum.x) | ||
|
|
||
| [case testEnumIter] |
There was a problem hiding this comment.
Can you also add a normal unit test that defines a metaclass and uses it? It may be better to first merge the code change + the unit test (that doesn't depend on typeshed), and land the typeshed change and the pythoneval test separately. This way the commit history is a little cleaner and there's less coupling to typeshed changes.
There was a problem hiding this comment.
There seem to be other tests relying on typeshed
FAILURE #3 check file runtests.py
typeshed/stdlib/3/types.pyi:111: note: In module imported here,
typeshed/stdlib/3/sys.pyi:10: note: ... from here,
runtests.py:9: note: ... from here:
typeshed/stdlib/3/_importlib_modulespec.pyi:36: error: Name 'abc.ABCMeta' is not defined
typeshed/stdlib/3/_importlib_modulespec.pyi:36: error: Invalid metaclass 'abc.ABCMeta'
|
(I didn't do a detailed review, just mentioned that it may better to split this PR.) |
Here's the way I do it.
This runs 5 sets of tests: You can limit it to a single Python version using (UPDATE: I've now added this information to the typeshed README.md.) |
|
I think I will wait for syncing typeshed and reopen another one. |
In order to fix #2305, I think we need a better handling of metaclasses: store the type of the metaclass in TypeInfo, and use it when possible, instead of
builtins.type.I assume metaclasses inherit from type; I don't yet follow the documentation.
This PR requires changes to typeshed.