Hello folks.
If you have a project you want to eventually run through both Black and MonkeyType, is there any advantage to running Black first?
IOW, is MonkeyType less likely to get confused by Black-formatted code than by inconsistently multiple-humans-formatted code?
Also, I'm hearing that Black does before-and-after AST's to make sure no bugs are introduced. Does MonkeyType do anything like this?
Thanks.
Two completely different use-cases.
Black normalises syntax (always run) MonkeyType adds typing information (one-time run)
… so you can run each in isolation and be ok.
Normally you run black frequently, on each and every commit/save, as it just makes life easier.
Whereas Monkey type is more one-time affair. Run it once and then ensure that typing is valid with mypy in CiCd.
Bear in mind that MonkeyType can make code changes, and that black will then make those changes conform to its coding style, and that’s ok. More than ok.
F.
On Sat, 30 Jul 2022 at 16:58, Dan Stromberg drsalists@gmail.com wrote:
Hello folks.
If you have a project you want to eventually run through both Black and MonkeyType, is there any advantage to running Black first?
IOW, is MonkeyType less likely to get confused by Black-formatted code than by inconsistently multiple-humans-formatted code?
Also, I'm hearing that Black does before-and-after AST's to make sure no bugs are introduced. Does MonkeyType do anything like this?
Thanks.
code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: frank@doublethefish.com
Thanks for the reply.
I was actually wondering.... Black does a before-and-after AST comparison for reliability. Does MonkeyType do anything like that?
And if not, would MonkeyType be less prone to introducing bugs if we run Black first?
On Sat, Jul 30, 2022 at 9:19 AM Frank Harrison frank@lursight.com wrote:
Two completely different use-cases.
Black normalises syntax (always run) MonkeyType adds typing information (one-time run)
… so you can run each in isolation and be ok.
Normally you run black frequently, on each and every commit/save, as it just makes life easier.
Whereas Monkey type is more one-time affair. Run it once and then ensure that typing is valid with mypy in CiCd.
Bear in mind that MonkeyType can make code changes, and that black will then make those changes conform to its coding style, and that’s ok. More than ok.
F.
On Sat, 30 Jul 2022 at 16:58, Dan Stromberg drsalists@gmail.com wrote:
Hello folks.
If you have a project you want to eventually run through both Black and MonkeyType, is there any advantage to running Black first?
IOW, is MonkeyType less likely to get confused by Black-formatted code than by inconsistently multiple-humans-formatted code?
Also, I'm hearing that Black does before-and-after AST's to make sure no bugs are introduced. Does MonkeyType do anything like this?
Thanks.
code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: frank@doublethefish.com
code-quality mailing list -- code-quality@python.org To unsubscribe send an email to code-quality-leave@python.org https://mail.python.org/mailman3/lists/code-quality.python.org/ Member address: strombrg@gmail.com
Hi Dan,
On Sat, Jul 30, 2022 at 12:54 PM Dan Stromberg strombrg@gmail.com wrote:
Thanks for the reply.
I was actually wondering.... Black does a before-and-after AST comparison for reliability. Does MonkeyType do anything like that?
No. This wouldn’t make sense for MonkeyType, since type annotations are part of the AST, so MonkeyType’s entire purpose is to modify the AST. If it does anything at all, it would always “fail” such a test. Unlike Black, which should modify only syntactic trivia that is invisible in the AST.
And if not, would MonkeyType be less prone to introducing bugs if we run
Black first?
Not unless there’s a bug in LibCST (the underlying codemod library used by MonkeyType) where it chokes on some super strange code formatting. But this is unlikely.
The kinds of bugs MonkeyType is likely to introduce are not code formatting related, but logical bugs related to the type annotations it adds; eg MonkeyType can easily create circular imports in your code, if you don’t use `from __future__ import annotations`. You definitely want to run your test suite and your type checker after running MonkeyType, and review/edit the changes manually as needed. MonkeyType changes are definitely not intended to commit blindly.
You probably also want to run Black _after_ MonkeyType, since MonkeyType may modify your code in such a way that it no longer conforms to Black formatting.
Carl (MonkeyType maintainer)
participants (4)
-
Carl Meyer -
Dan Stromberg -
Dan Stromberg -
Frank Harrison