Skip to content

Allow multiple shadow files to be specified #5023

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
May 16, 2018

Conversation

garetht
Copy link
Contributor

@garetht garetht commented May 12, 2018

This pull request allows the --shadow-file argument to be specified multiple times, allowing multiple different source files to be replaced by their corresponding shadow files.

Tests have also been added to ensure the original and new behaviors both work.

@garetht
Copy link
Contributor Author

garetht commented May 14, 2018

Not sure why the tests are failing only in Python 3.5.1 - it seems the newly added method hasn't made its way into that test?

@JelleZijlstra
Copy link
Member

I think you'll have to type: ignore it until python/typeshed#2053 is merged. The issue appears only in 3.5.1 probably because we run additional tests on 3.5.1 only (see .travis.yml).

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good work! I have some suggestions for tidying up the code a bit, and some requests to clarify the docs (since this feature has been widely misunderstood).

@@ -468,7 +468,8 @@ Here are some more useful flags:
make transformations to a file before type checking without having to change
the file in-place. (For example, tooling could use this to display the type
of an expression by wrapping it with a call to reveal_type in the shadow
file and then parsing the output.)
file and then parsing the output.) This argument may be specified multiple times
to make mypy substitute multiple different files with their shadow replacements.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs an example -- do you write --shadow-file X1 X2 Y1 Y2 or --shadow-file X1 X2 --shadow-file Y1 Y2? (I presume the latter, but some options use the former syntax, and argparse supports both.)

Also, this argument has caused many people to be confused. We should present an example explaining that --shadow-file X1 X2 means that whenever the checker is asked to check X1, it actually reads and checks the contents of X2, but diagnostics will refer to X1 (it may well be the latter bit that trips people up).

mypy/build.py Outdated
if (self.options.shadow_file and
os.path.samefile(self.options.shadow_file[0], path)):
path = self.options.shadow_file[1]
if not self.options.shadow_file:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it would be better if this checked for if not self.shadow_map. The Options object has been processed already in __init__() above.

else:
self.shadow_equivalence_map[path] = None

shadow_file = self.shadow_equivalence_map.get(path)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the rest of the function could be shortened to

return self.shadow_equivalence_map.get(path, path)

mypy/build.py Outdated

previously_checked = path in self.shadow_equivalence_map
if not previously_checked:
for k in self.shadow_map.keys():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd switch this to for k, v in self.shadow_map.items(), then you can use v instead of self.shadow_map.get(k) two lines below.

(Also perhaps use more imaginative names than k, v -- how about source, shadow?

def samefile(self, f1: str, f2: str) -> bool:
s1 = self.stat(f1)
s2 = self.stat(f2)
return os.path.samestat(s1, s2) # type: ignore
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious -- why do you need # type: ignore here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were missing this function in the stub. We just merged the PR adding it, so this ignore can be removed as soon as we sync typeshed.

@gvanrossum gvanrossum merged commit 2a0c4e5 into python:master May 16, 2018
@gvanrossum
Copy link
Member

Thanks! (I cancelled the tests of my final cleanup since Travis and AppVeyor are kind of busy.)

@garetht
Copy link
Contributor Author

garetht commented May 16, 2018

Thanks for the quick review!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants