Skip to content
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

some way to skip replacing mock with unittest.mock #314

Closed
graingert opened this issue May 26, 2020 · 10 comments · Fixed by #316
Closed

some way to skip replacing mock with unittest.mock #314

graingert opened this issue May 26, 2020 · 10 comments · Fixed by #316

Comments

@graingert
Copy link
Contributor

graingert commented May 26, 2020

when you're using python 3.6 or 3.7 unittest.mock.AsyncMock is unavailable, but mock.AsyncMock is available if you're using the latest backport

there should be some way to skip replacing mock with unittest.mock, or the fixer should be moved to --py38-plus and then to a later --py...-plus as and when unittest.mock gains features

@asottile
Copy link
Owner

@mxr ^ thoughts

@mxr
Copy link
Contributor

mxr commented May 26, 2020

I suppose we could hardcode of a list of unittest.mock attrs and the version they were added into unittest.mock, and rewrite conditionally based on that

@asottile
Copy link
Owner

maybe --no-mock is easier, idk

@mxr
Copy link
Contributor

mxr commented May 26, 2020

But would you want --no-xx for suppressing an arbitrary rewrite? If not, why this specific case?

@asottile
Copy link
Owner

only this case because there's a good reason to keep it (%-rewrite could break python2 in some exotic scenarios) -- unless we can actually detect it properly and then we don't need an option

@mxr
Copy link
Contributor

mxr commented May 26, 2020

It should be possible to detect it properly using the approach I outlined

@graingert
Copy link
Contributor Author

graingert commented May 26, 2020

also mock.patch behaves differently (on 3.6/3.7 Vs pypi mock/3.8) when applied to a coroutinefunction

@graingert
Copy link
Contributor Author

Also I don't like an autodetect because I don't want some project files using unittest.mock and others using mock

@graingert
Copy link
Contributor Author

thirdly how should other backports be handled? eg functools32 contextlib2 pkg_util_resolve_name etc?

@mxr
Copy link
Contributor

mxr commented May 27, 2020

Good points, sounds like --no-mock is the best approach for now

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 a pull request may close this issue.

3 participants