-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Refactor testpep561 and add test to address #5767 #5782
Conversation
94c854d
to
2b69726
Compare
Let's make sure this catches #5784 |
I would very much like to use these tests to prove that I've fixed #5784 (rather than just manually running the example shown there). But for that to happen this would probably have to be brought back to minimally invasive form -- or at least it would have to pass the tests on AppVeyor. |
Woops sorry, I'm moving too fast. I just saw I got an error and commited it. I'll work on actually repro'ing now that I've properly read the issue. |
Build failures so far are because of #5784. Right now, I am not really sure what the test should actually look like but for now it reproduces the issue at least, I will make a better test once the issue gets fixed. |
See if the one-line fix in #5785 (latest version) fixes it. |
#5785 worked locally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't claim to fully understand the issue in the 0.640 release yet (I will finally have time to look at it later today) but I don't think the C-extension complexity is needed. While in the original report it was an issue with the C-extension in asyncio, we also got a report with a normal Python module. Since this adds a fair amount of complexity, perhaps we could do something a bit simpler?
@ethanhs could you share a link to the repro that doesn't use c extensions? |
I've got a hunch that what you need to repro the issue is an installed package with a I think that you have to install at least something like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some style comments, and a suggestion on how to avoid having to compile C code (which will make the tests fail on machines where the user hasn't installed a C compiler -- these days all too common).
On my machine (update: a Mac) test_typedpkg_editable()
fails consistently, as follows:
Traceback (most recent call last):
File "/Users/guido/src/mypy/mypy/test/testpep561.py", line 280, in test_typedpkg_editable
venv_dir=venv_dir,
File "/Users/guido/src/mypy/mypy/test/testpep561.py", line 123, in check_mypy_run
assert out == self.build_msg(*expected_out), err
AssertionError:
assert "/var/folders...pe is 'Any'\n" == "/var/folders/...ltins.str]'\n"
- /var/folders/63/czkyq6090dd0t157zhx54xvhrdlybt/T/tmpo6_mhk_f/test_program.py:2: error: Cannot find module named 'typedpkg.sample'
- /var/folders/63/czkyq6090dd0t157zhx54xvhrdlybt/T/tmpo6_mhk_f/test_program.py:2: note: (Perhaps setting MYPYPATH or using the "--ignore-missing-imports" flag would help)
- /var/folders/63/czkyq6090dd0t157zhx54xvhrdlybt/T/tmpo6_mhk_f/test_program.py:3: error: Cannot find module named 'typedpkg'
- /var/folders/63/czkyq6090dd0t157zhx54xvhrdlybt/T/tmpo6_mhk_f/test_program.py:5: error: Revealed type is 'Any'
? ^ ^
+ /var/folders/63/czkyq6090dd0t157zhx54xvhrdlybt/T/tmpo6_mhk_f/test_program.py:5: error: Revealed type is 'builtins.tuple[builtins.str]'
? ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
(Also, these tests still take way too long to run. But I understand that running pip install is just slow...)
mypy/test/testpep561.py
Outdated
|
||
class NamespaceProgramImportStyle(Enum): | ||
from_import = """\ | ||
from typedpkg_nested.nested_package.nested_module import nested_func |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dislike having those long module names. If you give each of them names of 3-5 letters it will become more readable (and you won't have to break long lines with \
below). Also a comment may be in order explaining why some things must go together on one line (IIUC it's so that the line numbers in the error messages are consistent?)
mypy/test/testpep561.py
Outdated
self.namespace_msg_int_bool = ( | ||
'{0}:9: error: Argument 1 to "alpha_func" has incompatible type "int"; ' | ||
'expected "bool"\n'.format(self.namespace_tempfile)) | ||
self.simple_example_program = ExampleProgram(SIMPLE_PROGRAM) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These variable names are all too long -- when skimming all I see is blah_blah_blah_blah
. I don't think they all need to end in _example_program
, and you can abbreviate namespace
as ns
.
******************************************************************/ | ||
#include <Python.h> | ||
|
||
// ot ForbesFunction 1: A simple 'hello world' function |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"ot"?
name='typedpkg_c_ext', | ||
version='1.0', | ||
packages=['typedpkg_c_ext'], | ||
ext_modules=[Extension('typedpkg_c_ext.hello', ['hello.c'])], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you can just delete this line (and the file hello.c) and the test works just as well. (Verified by removing the isdir()
check from modulefinder.c line 124.)
There's something else missing. I patched this in, and then put an early But all pep561 tests still pass with that change (except |
I reorganized the test files so there isn't as much overlap with the test packages and made names in general shorter. I removed the c extensions test package because the repro can be done without it; and I made sure that the #5767 case is covered. Side Note: I am expecting the tests to fail because it looks like there is repeated warning output in some cases. |
But most tests are failing in the install phase -- is that also expected? What warnings are you expecting exactly? |
I was reading the |
I still get the failure on |
Are you under a virtualenv on a Mac? If yes, then this is not new, it fails since some time. |
I am seeing this:
for few month, but I have never had time to fix it. |
Yeah, that's what I get too (the traceback I reported is about the same). And yes, I am under a venv. |
I think this is an issue with the test infrastructure, since the same scenario works fine with installed mypy. A natural guess is that something goes wrong because this test creates a new virtual environment that probably conflicts somehow with the current environment. |
Hm, I should really leave this alone, but I investigated a bit more and found that when an outer venv is already active, the line |
One more internal monologue and then I'll let it go. :-) I added
There's other verbose output before and after this, but in a successful run, instead of this I see:
Additional notes:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. If Ethan agrees this can be merged!
mypy/test/testpep561.py
Outdated
python_executable, | ||
expected_out=self.msg_dne + self.msg_list, | ||
[SimpleMsg.msg_dne, | ||
SimpleMsg.msg_list], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I don't care much for splitting this line -- the whole list easily fits.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two suggestions, but otherwise seems fine to me.
Thank you for working on this!
mypy/test/testpep561.py
Outdated
self._temp_dir = None # type: Optional[tempfile.TemporaryDirectory[str]] | ||
self._full_fname = '' | ||
|
||
def init(self) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: rename to create
? init
doesn't really tell me what it is doing, create
implies it is doing setup work and creating the test case.
assert err == expected_err, out | ||
assert returncode == expected_returncode, returncode | ||
finally: | ||
class NSImportStyle(Enum): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad to see these going into Enums. :)
return _NAMESPACE_PROGRAM.format(import_style=import_style.value) | ||
|
||
|
||
class ExampleProg(object): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe change this to just Program
and change the suffixes below to self.simple_ep
to self.simple_prog
or something? ep
is not a straightforward mnemonic (at least to me).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll merge this now. Thank you for this! (And thanks Ethan for the review.)
I took some liberties while refactoring this to more fit my personal style and hopefully make more readable/extensible. I also added test cases for all the edge cases I found and filed in #5758; including a test case for which #5767 was filed.
I understand this is a pretty big change to this file and I am open to redoing it if its not popular.