Patchwork D7295: pytype: add a (very slow) test that executes pytype

login
register
mail settings
Submitter phabricator
Date Nov. 6, 2019, 11:01 p.m.
Message ID <differential-rev-PHID-DREV-ja2vr3fd2becf6h26ylj-req@mercurial-scm.org>
Download mbox | patch
Permalink /patch/42846/
State New
Headers show

Comments

phabricator - Nov. 6, 2019, 11:01 p.m.
durin42 created this revision.
Herald added subscribers: mercurial-devel, mjpieters.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  This doesn't actually pass yet, but I wanted to share it early so
  others can play with pytype.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

AFFECTED FILES
  tests/test-check-pytype.t

CHANGE DETAILS




To: durin42, #hg-reviewers
Cc: mjpieters, mercurial-devel
phabricator - Nov. 8, 2019, 4:52 p.m.
This revision now requires changes to proceed.
indygreg added a comment.
indygreg requested changes to this revision.


  This can't land per commit message, so setting status accordingly.
  
  I'm extremely supportive of adding type checking, whether it be pytype or mypy. I don't think it matters much. And TBH I wouldn't be surprised if we end up with both once we drop Python 2 support and start using inline annotations heavily!
  
  As for how to start testing, I think we should do this like Python 3 and try to make individual files "clean." Maintain a list of clean files and we ratchet from there.
  
  Since type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg
Cc: indygreg, mjpieters, mercurial-devel
phabricator - Nov. 19, 2019, 4:28 p.m.
mharbison72 added inline comments.

INLINE COMMENTS

> test-check-pytype.t:22
> +  >    -x mercurial/lsprof.py \
> +  >    -x mercurial/policy.py
> +  >    -x mercurial/pycompat.py \

Needs a trailing slash here.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg
Cc: mharbison72, dlax, indygreg, mjpieters, mercurial-devel
phabricator - Nov. 22, 2019, 10:43 p.m.
mharbison72 added a comment.


  In D7295#107482 <https://phab.mercurial-scm.org/D7295#107482>, @indygreg wrote:
  
  > Since type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?
  
  It takes 15-20 minutes on a 2018 Mac mini.  In addition to the disabled files here, I've disabled:
  
    mercurial/httppeer.py
    mercurial/repoview.py
    mercurial/localrepo.py
    mercurial/revlog.py
    mercurial/merge.py
    mercurial/testing/storage.py
  
  But I've also added back these, and sprinkled various disable comments around:
  
    mercurial/bundlerepo.py
    mercurial/error.py
    mercurial/exchange.py
    mercurial/policy.py
    mercurial/pycompat.py
    mercurial/scmwindows.py
    mercurial/windows.py
    mercurial/wireprotoframing.py
  
  Even with the state files, it seems to take 10-15 minutes or so.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg
Cc: mharbison72, dlax, indygreg, mjpieters, mercurial-devel
phabricator - Nov. 23, 2019, 5:48 p.m.
durin42 added a comment.


  In D7295#110254 <https://phab.mercurial-scm.org/D7295#110254>, @mharbison72 wrote:
  
  > In D7295#107482 <https://phab.mercurial-scm.org/D7295#107482>, @indygreg wrote:
  >
  >> Since type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?
  >
  > It takes 15-20 minutes on a 2018 Mac mini.  In addition to the disabled files here, I've disabled:
  >
  >   mercurial/httppeer.py
  >   mercurial/repoview.py
  >   mercurial/localrepo.py
  >   mercurial/revlog.py
  >   mercurial/merge.py
  >   mercurial/testing/storage.py
  >
  > But I've also added back these, and sprinkled various disable comments around:
  >
  >   mercurial/bundlerepo.py
  >   mercurial/error.py
  >   mercurial/exchange.py
  >   mercurial/policy.py
  >   mercurial/pycompat.py
  >   mercurial/scmwindows.py
  >   mercurial/windows.py
  >   mercurial/wireprotoframing.py
  >
  > Even with the state files, it seems to take 10-15 minutes or so.
  
  Ooh, can you send your extra suppressions? For the most part I've been tackling this as a side project when I'm waiting on compiles.
  
  As to doing individual files: that's well and good, and might be a viable approach for mypy. That said, my sense has been that mypy is faster and significantly less useful, since we don't get cross-file analysis of what's going on. I _think_ pytype gets faster as we add more annotations, so my rough thought thus far as been to try and get some subset of the codebase clean, transitively, and then try to start stamping some types on important functions and interfaces to constrain things. Where I'd _really_ like to get is to be able to migrate the `@command` decorators and friends to use strings instead of bytes, and be able to recommend typechecking as a way for extension authors to clean things up, but that'll take a while.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg
Cc: mharbison72, dlax, indygreg, mjpieters, mercurial-devel
phabricator - Jan. 30, 2020, 6:34 p.m.
marmoute added a comment.


  This seems useful, and the stabilisation seems to take a long while. Maybe we could take it in its current state (with "expected" broken output) and iterate from there. With the test in the repo.
  
  What do you all think ?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg
Cc: marmoute, mharbison72, dlax, indygreg, mjpieters, mercurial-devel
phabricator - Jan. 31, 2020, 5:15 a.m.
quark added a comment.


  Have `pyre` been considered? It seems `pyre` only takes 10 seconds to check all the `.py` files.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg
Cc: quark, marmoute, mharbison72, dlax, indygreg, mjpieters, mercurial-devel
phabricator - Jan. 31, 2020, 3:19 p.m.
durin42 added a comment.


  In D7295#118785 <https://phab.mercurial-scm.org/D7295#118785>, @quark wrote:
  
  > Have `pyre` been considered?
  
  No, initially because I'd never heard of it, but now because I don't want to deal with ocaml. :)
  
  > It seems `pyre` only takes 10 seconds to check all the `.py` files.
  > EDIT: 10s on a machine with many CPU cores. 1 minute on laptop.
  
  I'm dubious that it's doing anywhere near the checking of pytype if it manages to run to completion without errors. What does the output look like?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg
Cc: quark, marmoute, mharbison72, dlax, indygreg, mjpieters, mercurial-devel
phabricator - Jan. 31, 2020, 7:58 p.m.
quark added a comment.


  > No, initially because I'd never heard of it, but now because I don't want to deal with ocaml. :)
  
  The `pip install` version ships with a pre-compiled binary so an ocaml compiler is not needed.
  
  > I'm dubious that it's doing anywhere near the checking of pytype if it manages to run to completion without errors. What does the output look like?
  
  Good question. I wasn't aware about the differences and I read pytype's README and the examples apply to pyre. Pytype does type inference while pyre only checks function with stricter type annotations.
  
  Pyre does complete (output <https://bpaste.net/7JCQ>). I wasn't able to get pytype past 44/251 (output <https://bpaste.net/CLEQ>). For files with type annotations like `mail.py`, it seems pyre output is useful:
  
    # on commit d844202324924919bc517691052d39c520e077eb
    mercurial/mail.py:57:4 Inconsistent override [15]: `mail.STARTTLS.starttls` overrides method defined in `smtplib.SMTP` inconsistently. The overriding method is not annotated but should return a subtype of `typing.Tuple[int, bytes]`.
    mercurial/mail.py:387:22 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.
    mercurial/mail.py:392:28 Incompatible parameter type [6]: Expected `bytes` for 2nd anonymous parameter to call `_encode` but got `Union[bytes, str]`.
    mercurial/mail.py:394:33 Incompatible parameter type [6]: Expected `bytes` for 1st anonymous parameter to call `encoding.strfromlocal` but got `Union[bytes, str]`.
    mercurial/mail.py:397:35 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.
    mercurial/mail.py:399:4 Incompatible variable type [9]: addr is declared to have type `str` but is used as type `bytes`.
    mercurial/mail.py:402:30 Incompatible parameter type [6]: Expected `typing.Optional[str]` for 1st anonymous parameter to call `str.split` but got `bytes`.
    mercurial/mail.py:405:8 Incompatible variable type [9]: addr is declared to have type `str` but is used as type `bytes`.
    mercurial/mail.py:414:63 Incompatible parameter type [6]: Expected `bytes` for 1st anonymous parameter to call `encoding.strfromlocal` but got `str`.
    mercurial/mail.py:417:31 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.
    mercurial/mail.py:426:30 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.
    mercurial/mail.py:446:22 Incompatible variable type [9]: charsets is declared to have type `List[str]` but is used as type `None`.
    mercurial/mail.py:499:52 Incompatible parameter type [6]: Expected `Union[email.header.Header, str]` for 1st anonymous parameter to call `email.header.decode_header` but got `Union[bytes, email.header.Header]`.
  
  It seems to me that a combined approach might be interesting - use pytype to generate `pyi` files and pyre for faster checking.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg
Cc: quark, marmoute, mharbison72, dlax, indygreg, mjpieters, mercurial-devel
phabricator - April 17, 2020, 6:36 p.m.
This revision now requires changes to proceed.
marmoute added a comment.
marmoute requested changes to this revision.


  According to IRC discussion with Augie, this is not ready yet.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7295/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7295

To: durin42, #hg-reviewers, indygreg, marmoute
Cc: quark, marmoute, mharbison72, dlax, indygreg, mjpieters, mercurial-devel

Patch

diff --git a/tests/test-check-pytype.t b/tests/test-check-pytype.t
new file mode 100644
--- /dev/null
+++ b/tests/test-check-pytype.t
@@ -0,0 +1,33 @@ 
+#require pytype py3 slow
+
+  $ cd $RUNTESTDIR/..
+
+Many of the individual files that are excluded here confuse pytype
+because they do a mix of Python 2 and Python 3 things
+conditionally. There's no good way to help it out with that as far as
+I can tell, so let's just hide those files from it for now. We should
+endeavor to empty this list out over time, as some of these are
+probably hiding real problems.
+
+  $ pytype mercurial \
+  >   -x mercurial/encoding.py \
+  >   -x mercurial/error.py \
+  >   -x mercurial/pycompat.py \
+  >   -x mercurial/urllibcompat.py \
+  >   -x mercurial/lsprof.py \
+  >   -x mercurial/i18n.py \
+  >   -x mercurial/sslutil.py \
+  >   -x mercurial/scmwindows.py \
+  >   -x mercurial/keepalive.py \
+  >   -x mercurial/windows.py \
+  >   -x mercurial/wireprotoframing.py \
+  >   -x mercurial/utils/stringutil.py \
+  >   -x mercurial/hgweb/server.py \
+  >   -x mercurial/hgweb/wsgicgi.py \
+  >   -x mercurial/minirst.py \
+  >   -x mercurial/chgserver.py \
+  >   -x mercurial/bundlerepo.py \
+  >   -x mercurial/interfaces \
+  >   -x mercurial/cffi \
+  >   -x mercurial/pure \
+  >   -x mercurial/thirdparty