Re: Python Static Typing: Next Steps
Awesome! Congrats to all involved in making the project achieve such milestone! On Thu, May 7, 2020 at 7:13 PM Luke Cwik wrote: > > Sweet. > > On Wed, May 6, 2020 at 5:05 PM Robert Bradshaw wrote: >> >> Just an update on this: we just merged >> https://github.com/apache/beam/pull/11620 which enforces typechecking >> for all files that currently pass. >> >> On Tue, Mar 3, 2020 at 1:12 PM Chad Dombrova wrote: >> >> >> >> This probably does not apply yet, does optional mean that opting-in for >> >> all or none of the precommit hooks? Would contributors have a choice of >> >> which pre-commits they can opt-in too? >> > >> > >> > Yes, once the hook is installed, individual checks are opt-out and the >> > design is clearly built around a one-time override, rather than setting up >> > a long-term preference: https://pre-commit.com/#temporarily-disabling-hooks >> > >> > There might be better way that's not documented. >> >
Re: Python Static Typing: Next Steps
Sweet. On Wed, May 6, 2020 at 5:05 PM Robert Bradshaw wrote: > Just an update on this: we just merged > https://github.com/apache/beam/pull/11620 which enforces typechecking > for all files that currently pass. > > On Tue, Mar 3, 2020 at 1:12 PM Chad Dombrova wrote: > >> > >> This probably does not apply yet, does optional mean that opting-in for > all or none of the precommit hooks? Would contributors have a choice of > which pre-commits they can opt-in too? > > > > > > Yes, once the hook is installed, individual checks are opt-out and the > design is clearly built around a one-time override, rather than setting up > a long-term preference: > https://pre-commit.com/#temporarily-disabling-hooks > > > > There might be better way that's not documented. > > >
Re: Python Static Typing: Next Steps
Just an update on this: we just merged https://github.com/apache/beam/pull/11620 which enforces typechecking for all files that currently pass. On Tue, Mar 3, 2020 at 1:12 PM Chad Dombrova wrote: >> >> This probably does not apply yet, does optional mean that opting-in for all >> or none of the precommit hooks? Would contributors have a choice of which >> pre-commits they can opt-in too? > > > Yes, once the hook is installed, individual checks are opt-out and the design > is clearly built around a one-time override, rather than setting up a > long-term preference: https://pre-commit.com/#temporarily-disabling-hooks > > There might be better way that's not documented. >
Re: Python Static Typing: Next Steps
> > This probably does not apply yet, does optional mean that opting-in for > all or none of the precommit hooks? Would contributors have a choice of > which pre-commits they can opt-in too? > Yes, once the hook is installed, individual checks are opt-out and the design is clearly built around a one-time override, rather than setting up a long-term preference: https://pre-commit.com/#temporarily-disabling-hooks There might be better way that's not documented.
Re: Python Static Typing: Next Steps
On Tue, Mar 3, 2020 at 11:53 AM Chad Dombrova wrote: > >>> +1. Also would not running dmypy would require all contributors to run a >> process all the time? I do not know if this is desired by existing >> contributors, and I am not sure if it will be friendly to new contributors. >> > > Pre-commit git hooks are completely opt-in. Developers who choose not to > use them will simply continue doing what they do now. The Jenkins jobs > remain the only gatekeeper that really matters. But as a developer I'd > rather get all my linting and mypy checks done in a second each time I > commit, so that I know that the Jenkins lint job will succeed when I push > up my changes. Plus there's a lot of overhead running the lint jobs via > tox. > > Also note that even after you've setup the pre-commit hook in git, you can > opt out for a specific commit by passing -n to git commit. > OK, this sounds fine, if it will be completely optional and would not require any effort from new contributors to opt-out. This probably does not apply yet, does optional mean that opting-in for all or none of the precommit hooks? Would contributors have a choice of which pre-commits they can opt-in too?
Re: Python Static Typing: Next Steps
> > >> +1. Also would not running dmypy would require all contributors to run a > process all the time? I do not know if this is desired by existing > contributors, and I am not sure if it will be friendly to new contributors. > Pre-commit git hooks are completely opt-in. Developers who choose not to use them will simply continue doing what they do now. The Jenkins jobs remain the only gatekeeper that really matters. But as a developer I'd rather get all my linting and mypy checks done in a second each time I commit, so that I know that the Jenkins lint job will succeed when I push up my changes. Plus there's a lot of overhead running the lint jobs via tox. Also note that even after you've setup the pre-commit hook in git, you can opt out for a specific commit by passing -n to git commit.
Re: Python Static Typing: Next Steps
On Tue, Mar 3, 2020 at 11:10 AM Robert Bradshaw wrote: > Nice. > > I still think we should enable it in jenkins and get some experience > with it before we add it to the default pre-commit-hook territory. > +1. Also would not running dmypy would require all contributors to run a process all the time? I do not know if this is desired by existing contributors, and I am not sure if it will be friendly to new contributors. > > On Tue, Mar 3, 2020 at 10:38 AM Chad Dombrova wrote: > > > > I tested out dmypy (the mypy daemon) last night and it was completing in > under a second after editing a file and rerunning (usually around 0.6s), > which puts it into pre-commit-hook territory. > > > > -chad > > > > > > > > > > On Tue, Mar 3, 2020 at 1:54 AM Ismaël Mejía wrote: > >> > >> +1 to do it by default. Great to see the typing work arrive to this > >> maturity milestone. > >> We can also refer to some of the mypy typing docs for newbies on the > subject. > >> > >> On Tue, Mar 3, 2020 at 10:15 AM Kamil Wasilewski > >> wrote: > >> > > >> > +1 for enabling mypy as a precommit job > >> > > >> > This however could be a good occasion to rework the current > PythonLint job. Since yapf has been introduced, some of the checks made by > pylint/flake are now unnecessary and could be dismantled. This would > speed-up PythonLint quite a lot. > >> > I volunteer to help with anything as well. > >> > > >> > On Tue, Mar 3, 2020 at 1:43 AM Robert Bradshaw > wrote: > >> >> > >> >> It seems people are conflating git pre-commit hooks (which IMHO > should > >> >> ideally be in the sub-second range, and run when an author does "git > >> >> commit") with jenkins pre-commit tests (for which minutes is nothing > >> >> compared to what we already do). I am +1 to adding mypy to the latter > >> >> for sure, and think we should probably hold off for the former. > >> >> > >> >> On Mon, Mar 2, 2020 at 4:38 PM Udi Meiri wrote: > >> >> > > >> >> > Off-topic: Python lint via pre-commit should be much faster. (I > wrote my own modified-file-only lint in the past) > >> >> > > >> >> > On Mon, Mar 2, 2020 at 2:08 PM Kyle Weaver > wrote: > >> >> >> > >> >> >> > Python lint takes 4-5mins to complete. I think if the mypy > analysis is really on the order of 10s, the additional time won't matter > and could always be enabled. > >> >> >> > >> >> >> +1 of course it would be nice to make mypy as fast as possible, > but I don't think speed needs to be a blocker. The productivity gains we'd > get from reliable type analysis more than offset the cost IMO. > >> >> >> > >> >> >> On Mon, Mar 2, 2020 at 2:03 PM Luke Cwik > wrote: > >> >> >>> > >> >> >>> Python lint takes 4-5mins to complete. I think if the mypy > analysis is really on the order of 10s, the additional time won't matter > and could always be enabled. > >> >> >>> > >> >> >>> On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova > wrote: > >> >> > > >> >> > I believe that mypy via pre-commit hook will be faster than > 10s since it only applies to modified files. > >> >> > >> >> > >> >> Correct, with a few caveats: > >> >> > >> >> pre-commit can be setup to only run if a python file changes. > so modifying a java file won't trigger mypy to run. > >> >> if *any* python file changes mypy has to run on the whole > codebase, because a change to one file can affect the others (i.e. a > function arg type changes). it's not really meaningful to run mypy on a > single file. > >> >> the mypy daemon tracks which files have changed, and runs > incremental updates. so if we setup the precommit hook to run the daemon, > we should see that get appreciably faster. I'll do some tests and report > back. >
Re: Python Static Typing: Next Steps
Nice. I still think we should enable it in jenkins and get some experience with it before we add it to the default pre-commit-hook territory. On Tue, Mar 3, 2020 at 10:38 AM Chad Dombrova wrote: > > I tested out dmypy (the mypy daemon) last night and it was completing in > under a second after editing a file and rerunning (usually around 0.6s), > which puts it into pre-commit-hook territory. > > -chad > > > > > On Tue, Mar 3, 2020 at 1:54 AM Ismaël Mejía wrote: >> >> +1 to do it by default. Great to see the typing work arrive to this >> maturity milestone. >> We can also refer to some of the mypy typing docs for newbies on the subject. >> >> On Tue, Mar 3, 2020 at 10:15 AM Kamil Wasilewski >> wrote: >> > >> > +1 for enabling mypy as a precommit job >> > >> > This however could be a good occasion to rework the current PythonLint >> > job. Since yapf has been introduced, some of the checks made by >> > pylint/flake are now unnecessary and could be dismantled. This would >> > speed-up PythonLint quite a lot. >> > I volunteer to help with anything as well. >> > >> > On Tue, Mar 3, 2020 at 1:43 AM Robert Bradshaw wrote: >> >> >> >> It seems people are conflating git pre-commit hooks (which IMHO should >> >> ideally be in the sub-second range, and run when an author does "git >> >> commit") with jenkins pre-commit tests (for which minutes is nothing >> >> compared to what we already do). I am +1 to adding mypy to the latter >> >> for sure, and think we should probably hold off for the former. >> >> >> >> On Mon, Mar 2, 2020 at 4:38 PM Udi Meiri wrote: >> >> > >> >> > Off-topic: Python lint via pre-commit should be much faster. (I wrote >> >> > my own modified-file-only lint in the past) >> >> > >> >> > On Mon, Mar 2, 2020 at 2:08 PM Kyle Weaver wrote: >> >> >> >> >> >> > Python lint takes 4-5mins to complete. I think if the mypy analysis >> >> >> > is really on the order of 10s, the additional time won't matter and >> >> >> > could always be enabled. >> >> >> >> >> >> +1 of course it would be nice to make mypy as fast as possible, but I >> >> >> don't think speed needs to be a blocker. The productivity gains we'd >> >> >> get from reliable type analysis more than offset the cost IMO. >> >> >> >> >> >> On Mon, Mar 2, 2020 at 2:03 PM Luke Cwik wrote: >> >> >>> >> >> >>> Python lint takes 4-5mins to complete. I think if the mypy analysis >> >> >>> is really on the order of 10s, the additional time won't matter and >> >> >>> could always be enabled. >> >> >>> >> >> >>> On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova >> >> >>> wrote: >> >> > >> >> > I believe that mypy via pre-commit hook will be faster than 10s >> >> > since it only applies to modified files. >> >> >> >> >> >> Correct, with a few caveats: >> >> >> >> pre-commit can be setup to only run if a python file changes. so >> >> modifying a java file won't trigger mypy to run. >> >> if *any* python file changes mypy has to run on the whole codebase, >> >> because a change to one file can affect the others (i.e. a function >> >> arg type changes). it's not really meaningful to run mypy on a >> >> single file. >> >> the mypy daemon tracks which files have changed, and runs >> >> incremental updates. so if we setup the precommit hook to run the >> >> daemon, we should see that get appreciably faster. I'll do some >> >> tests and report back.
Re: Python Static Typing: Next Steps
I tested out dmypy (the mypy daemon) last night and it was completing in under a second after editing a file and rerunning (usually around 0.6s), which puts it into pre-commit-hook territory. -chad On Tue, Mar 3, 2020 at 1:54 AM Ismaël Mejía wrote: > +1 to do it by default. Great to see the typing work arrive to this > maturity milestone. > We can also refer to some of the mypy typing docs for newbies on the > subject. > > On Tue, Mar 3, 2020 at 10:15 AM Kamil Wasilewski > wrote: > > > > +1 for enabling mypy as a precommit job > > > > This however could be a good occasion to rework the current PythonLint > job. Since yapf has been introduced, some of the checks made by > pylint/flake are now unnecessary and could be dismantled. This would > speed-up PythonLint quite a lot. > > I volunteer to help with anything as well. > > > > On Tue, Mar 3, 2020 at 1:43 AM Robert Bradshaw > wrote: > >> > >> It seems people are conflating git pre-commit hooks (which IMHO should > >> ideally be in the sub-second range, and run when an author does "git > >> commit") with jenkins pre-commit tests (for which minutes is nothing > >> compared to what we already do). I am +1 to adding mypy to the latter > >> for sure, and think we should probably hold off for the former. > >> > >> On Mon, Mar 2, 2020 at 4:38 PM Udi Meiri wrote: > >> > > >> > Off-topic: Python lint via pre-commit should be much faster. (I wrote > my own modified-file-only lint in the past) > >> > > >> > On Mon, Mar 2, 2020 at 2:08 PM Kyle Weaver > wrote: > >> >> > >> >> > Python lint takes 4-5mins to complete. I think if the mypy > analysis is really on the order of 10s, the additional time won't matter > and could always be enabled. > >> >> > >> >> +1 of course it would be nice to make mypy as fast as possible, but > I don't think speed needs to be a blocker. The productivity gains we'd get > from reliable type analysis more than offset the cost IMO. > >> >> > >> >> On Mon, Mar 2, 2020 at 2:03 PM Luke Cwik wrote: > >> >>> > >> >>> Python lint takes 4-5mins to complete. I think if the mypy analysis > is really on the order of 10s, the additional time won't matter and could > always be enabled. > >> >>> > >> >>> On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova > wrote: > >> > > >> > I believe that mypy via pre-commit hook will be faster than 10s > since it only applies to modified files. > >> > >> > >> Correct, with a few caveats: > >> > >> pre-commit can be setup to only run if a python file changes. so > modifying a java file won't trigger mypy to run. > >> if *any* python file changes mypy has to run on the whole > codebase, because a change to one file can affect the others (i.e. a > function arg type changes). it's not really meaningful to run mypy on a > single file. > >> the mypy daemon tracks which files have changed, and runs > incremental updates. so if we setup the precommit hook to run the daemon, > we should see that get appreciably faster. I'll do some tests and report > back. >
Re: Python Static Typing: Next Steps
+1 to do it by default. Great to see the typing work arrive to this maturity milestone. We can also refer to some of the mypy typing docs for newbies on the subject. On Tue, Mar 3, 2020 at 10:15 AM Kamil Wasilewski wrote: > > +1 for enabling mypy as a precommit job > > This however could be a good occasion to rework the current PythonLint job. > Since yapf has been introduced, some of the checks made by pylint/flake are > now unnecessary and could be dismantled. This would speed-up PythonLint quite > a lot. > I volunteer to help with anything as well. > > On Tue, Mar 3, 2020 at 1:43 AM Robert Bradshaw wrote: >> >> It seems people are conflating git pre-commit hooks (which IMHO should >> ideally be in the sub-second range, and run when an author does "git >> commit") with jenkins pre-commit tests (for which minutes is nothing >> compared to what we already do). I am +1 to adding mypy to the latter >> for sure, and think we should probably hold off for the former. >> >> On Mon, Mar 2, 2020 at 4:38 PM Udi Meiri wrote: >> > >> > Off-topic: Python lint via pre-commit should be much faster. (I wrote my >> > own modified-file-only lint in the past) >> > >> > On Mon, Mar 2, 2020 at 2:08 PM Kyle Weaver wrote: >> >> >> >> > Python lint takes 4-5mins to complete. I think if the mypy analysis is >> >> > really on the order of 10s, the additional time won't matter and could >> >> > always be enabled. >> >> >> >> +1 of course it would be nice to make mypy as fast as possible, but I >> >> don't think speed needs to be a blocker. The productivity gains we'd get >> >> from reliable type analysis more than offset the cost IMO. >> >> >> >> On Mon, Mar 2, 2020 at 2:03 PM Luke Cwik wrote: >> >>> >> >>> Python lint takes 4-5mins to complete. I think if the mypy analysis is >> >>> really on the order of 10s, the additional time won't matter and could >> >>> always be enabled. >> >>> >> >>> On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova wrote: >> > >> > I believe that mypy via pre-commit hook will be faster than 10s since >> > it only applies to modified files. >> >> >> Correct, with a few caveats: >> >> pre-commit can be setup to only run if a python file changes. so >> modifying a java file won't trigger mypy to run. >> if *any* python file changes mypy has to run on the whole codebase, >> because a change to one file can affect the others (i.e. a function arg >> type changes). it's not really meaningful to run mypy on a single file. >> the mypy daemon tracks which files have changed, and runs incremental >> updates. so if we setup the precommit hook to run the daemon, we >> should see that get appreciably faster. I'll do some tests and report >> back.
Re: Python Static Typing: Next Steps
+1 for enabling mypy as a precommit job This however could be a good occasion to rework the current PythonLint job. Since yapf has been introduced, some of the checks made by pylint/flake are now unnecessary and could be dismantled. This would speed-up PythonLint quite a lot. I volunteer to help with anything as well. On Tue, Mar 3, 2020 at 1:43 AM Robert Bradshaw wrote: > It seems people are conflating git pre-commit hooks (which IMHO should > ideally be in the sub-second range, and run when an author does "git > commit") with jenkins pre-commit tests (for which minutes is nothing > compared to what we already do). I am +1 to adding mypy to the latter > for sure, and think we should probably hold off for the former. > > On Mon, Mar 2, 2020 at 4:38 PM Udi Meiri wrote: > > > > Off-topic: Python lint via pre-commit should be much faster. (I wrote my > own modified-file-only lint in the past) > > > > On Mon, Mar 2, 2020 at 2:08 PM Kyle Weaver wrote: > >> > >> > Python lint takes 4-5mins to complete. I think if the mypy analysis > is really on the order of 10s, the additional time won't matter and could > always be enabled. > >> > >> +1 of course it would be nice to make mypy as fast as possible, but I > don't think speed needs to be a blocker. The productivity gains we'd get > from reliable type analysis more than offset the cost IMO. > >> > >> On Mon, Mar 2, 2020 at 2:03 PM Luke Cwik wrote: > >>> > >>> Python lint takes 4-5mins to complete. I think if the mypy analysis is > really on the order of 10s, the additional time won't matter and could > always be enabled. > >>> > >>> On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova > wrote: > > > > I believe that mypy via pre-commit hook will be faster than 10s > since it only applies to modified files. > > > Correct, with a few caveats: > > pre-commit can be setup to only run if a python file changes. so > modifying a java file won't trigger mypy to run. > if *any* python file changes mypy has to run on the whole codebase, > because a change to one file can affect the others (i.e. a function arg > type changes). it's not really meaningful to run mypy on a single file. > the mypy daemon tracks which files have changed, and runs incremental > updates. so if we setup the precommit hook to run the daemon, we should > see that get appreciably faster. I'll do some tests and report back. >
Re: Python Static Typing: Next Steps
It seems people are conflating git pre-commit hooks (which IMHO should ideally be in the sub-second range, and run when an author does "git commit") with jenkins pre-commit tests (for which minutes is nothing compared to what we already do). I am +1 to adding mypy to the latter for sure, and think we should probably hold off for the former. On Mon, Mar 2, 2020 at 4:38 PM Udi Meiri wrote: > > Off-topic: Python lint via pre-commit should be much faster. (I wrote my own > modified-file-only lint in the past) > > On Mon, Mar 2, 2020 at 2:08 PM Kyle Weaver wrote: >> >> > Python lint takes 4-5mins to complete. I think if the mypy analysis is >> > really on the order of 10s, the additional time won't matter and could >> > always be enabled. >> >> +1 of course it would be nice to make mypy as fast as possible, but I don't >> think speed needs to be a blocker. The productivity gains we'd get from >> reliable type analysis more than offset the cost IMO. >> >> On Mon, Mar 2, 2020 at 2:03 PM Luke Cwik wrote: >>> >>> Python lint takes 4-5mins to complete. I think if the mypy analysis is >>> really on the order of 10s, the additional time won't matter and could >>> always be enabled. >>> >>> On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova wrote: > > I believe that mypy via pre-commit hook will be faster than 10s since it > only applies to modified files. Correct, with a few caveats: pre-commit can be setup to only run if a python file changes. so modifying a java file won't trigger mypy to run. if *any* python file changes mypy has to run on the whole codebase, because a change to one file can affect the others (i.e. a function arg type changes). it's not really meaningful to run mypy on a single file. the mypy daemon tracks which files have changed, and runs incremental updates. so if we setup the precommit hook to run the daemon, we should see that get appreciably faster. I'll do some tests and report back.
Re: Python Static Typing: Next Steps
Off-topic: Python lint via pre-commit should be much faster. (I wrote my own modified-file-only lint in the past) On Mon, Mar 2, 2020 at 2:08 PM Kyle Weaver wrote: > > Python lint takes 4-5mins to complete. I think if the mypy analysis is > really on the order of 10s, the additional time won't matter and could > always be enabled. > > +1 of course it would be nice to make mypy as fast as possible, but I > don't think speed needs to be a blocker. The productivity gains we'd get > from reliable type analysis more than offset the cost IMO. > > On Mon, Mar 2, 2020 at 2:03 PM Luke Cwik wrote: > >> Python lint takes 4-5mins to complete. I think if the mypy analysis is >> really on the order of 10s, the additional time won't matter and could >> always be enabled. >> >> On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova wrote: >> >>> I believe that mypy via pre-commit hook will be faster than 10s since it only applies to modified files. >>> >>> Correct, with a few caveats: >>> >>>- pre-commit can be setup to only run if a python file changes. so >>>modifying a java file won't trigger mypy to run. >>>- if *any* python file changes mypy has to run on the whole >>>codebase, because a change to one file can affect the others (i.e. a >>>function arg type changes). it's not really meaningful to run mypy on a >>>single file. >>>- the mypy daemon tracks which files have changed, and runs >>>incremental updates. so if we setup the precommit hook to run the >>> daemon, >>>we should see that get appreciably faster. I'll do some tests and report >>>back. >>> >>> smime.p7s Description: S/MIME Cryptographic Signature
Re: Python Static Typing: Next Steps
> Python lint takes 4-5mins to complete. I think if the mypy analysis is really on the order of 10s, the additional time won't matter and could always be enabled. +1 of course it would be nice to make mypy as fast as possible, but I don't think speed needs to be a blocker. The productivity gains we'd get from reliable type analysis more than offset the cost IMO. On Mon, Mar 2, 2020 at 2:03 PM Luke Cwik wrote: > Python lint takes 4-5mins to complete. I think if the mypy analysis is > really on the order of 10s, the additional time won't matter and could > always be enabled. > > On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova wrote: > >> I believe that mypy via pre-commit hook will be faster than 10s since it >>> only applies to modified files. >>> >> >> Correct, with a few caveats: >> >>- pre-commit can be setup to only run if a python file changes. so >>modifying a java file won't trigger mypy to run. >>- if *any* python file changes mypy has to run on the whole codebase, >>because a change to one file can affect the others (i.e. a function arg >>type changes). it's not really meaningful to run mypy on a single file. >>- the mypy daemon tracks which files have changed, and runs >>incremental updates. so if we setup the precommit hook to run the daemon, >>we should see that get appreciably faster. I'll do some tests and report >>back. >> >>
Re: Python Static Typing: Next Steps
Python lint takes 4-5mins to complete. I think if the mypy analysis is really on the order of 10s, the additional time won't matter and could always be enabled. On Mon, Mar 2, 2020 at 1:21 PM Chad Dombrova wrote: > I believe that mypy via pre-commit hook will be faster than 10s since it >> only applies to modified files. >> > > Correct, with a few caveats: > >- pre-commit can be setup to only run if a python file changes. so >modifying a java file won't trigger mypy to run. >- if *any* python file changes mypy has to run on the whole codebase, >because a change to one file can affect the others (i.e. a function arg >type changes). it's not really meaningful to run mypy on a single file. >- the mypy daemon tracks which files have changed, and runs >incremental updates. so if we setup the precommit hook to run the daemon, >we should see that get appreciably faster. I'll do some tests and report >back. > >
Re: Python Static Typing: Next Steps
> > I believe that mypy via pre-commit hook will be faster than 10s since it > only applies to modified files. > Correct, with a few caveats: - pre-commit can be setup to only run if a python file changes. so modifying a java file won't trigger mypy to run. - if *any* python file changes mypy has to run on the whole codebase, because a change to one file can affect the others (i.e. a function arg type changes). it's not really meaningful to run mypy on a single file. - the mypy daemon tracks which files have changed, and runs incremental updates. so if we setup the precommit hook to run the daemon, we should see that get appreciably faster. I'll do some tests and report back.
Re: Python Static Typing: Next Steps
Let's go forward with this and see. I volunteer to help as well. I believe that mypy via pre-commit hook will be faster than 10s since it only applies to modified files. On Mon, Mar 2, 2020 at 10:53 AM Robert Bradshaw wrote: > +1 > > We should enable this on jenkins, plus trivial instructions (ideally a > one-liner tox command) to run it locally. Hopefully the errors will be > easy enough for contributors to figure out (in particular local to and > commensurate in complexity with the code that they're editing), and I > agree it's the only way to keep them accurate (which is a net positive > for tooling and developers). > > Running it as part of a pre-commit hook could be discussed once we > have a bit more experience (but 10s is certainly on the long side). > > On Mon, Mar 2, 2020 at 10:01 AM Luke Cwik wrote: > > > > +1 > > > > The typing information has really helped me several times figuring out > that API contracts and expected types. > > > > On Mon, Mar 2, 2020 at 9:54 AM Pablo Estrada wrote: > >> > >> I am in favor of enabling the test, and also am happy to start > answering questions too. > >> Thanks so much Chad for leading this. > >> Best > >> -P. > >> > >> On Mon, Mar 2, 2020 at 9:44 AM Chad Dombrova wrote: > >>> > >>> Good news everyone! > >>> We nearly have the full beam codebase passing in mypy. > >>> > >>> As we are now approaching the zero-error event horizon, I'd like to > open up a discussion around enabling mypy in the PythonLint job. Every day > or so a PR is merged that introduces some new mypy errors, so enabling this > test is the only way I see to keep the annotations accurate and thus useful. > >>> > >>> Developer fatigue is a real concern here, since static typing has a a > steep learning curve, and there are still not a lot of experts to help > consult on PRs. Here are some things that I hope will mitigate those > concerns: > >>> > >>> We have a lot of tying coverage, so that means plenty of examples of > how to solve different types of problems > >>> Running mypy only takes 10 seconds to complete (if you execute it > outside of gradle / tox), and that will get better when we get to 0 > errors. Also, running mypy in daemon mode should speed that up even more > >>> I have a PR[1] to allow developers to easily (and optionally) setup > yapf to run in a local git pre-commit hook; I'd like to do the same for > mypy. > >>> I will make myself and members of my team available to help out with > typing questions in PRs > >>> > >>> Is there anyone else on the list who is knowledgable about python > static typing who would like to volunteer to be flagged on typing questions? > >>> > >>> What else can we do to make this transition easier? > >>> > >>> [1] https://github.com/apache/beam/pull/10810 > >>> > >>> -chad > >>> > smime.p7s Description: S/MIME Cryptographic Signature
Re: Python Static Typing: Next Steps
+1 We should enable this on jenkins, plus trivial instructions (ideally a one-liner tox command) to run it locally. Hopefully the errors will be easy enough for contributors to figure out (in particular local to and commensurate in complexity with the code that they're editing), and I agree it's the only way to keep them accurate (which is a net positive for tooling and developers). Running it as part of a pre-commit hook could be discussed once we have a bit more experience (but 10s is certainly on the long side). On Mon, Mar 2, 2020 at 10:01 AM Luke Cwik wrote: > > +1 > > The typing information has really helped me several times figuring out that > API contracts and expected types. > > On Mon, Mar 2, 2020 at 9:54 AM Pablo Estrada wrote: >> >> I am in favor of enabling the test, and also am happy to start answering >> questions too. >> Thanks so much Chad for leading this. >> Best >> -P. >> >> On Mon, Mar 2, 2020 at 9:44 AM Chad Dombrova wrote: >>> >>> Good news everyone! >>> We nearly have the full beam codebase passing in mypy. >>> >>> As we are now approaching the zero-error event horizon, I'd like to open up >>> a discussion around enabling mypy in the PythonLint job. Every day or so a >>> PR is merged that introduces some new mypy errors, so enabling this test is >>> the only way I see to keep the annotations accurate and thus useful. >>> >>> Developer fatigue is a real concern here, since static typing has a a steep >>> learning curve, and there are still not a lot of experts to help consult on >>> PRs. Here are some things that I hope will mitigate those concerns: >>> >>> We have a lot of tying coverage, so that means plenty of examples of how to >>> solve different types of problems >>> Running mypy only takes 10 seconds to complete (if you execute it outside >>> of gradle / tox), and that will get better when we get to 0 errors. Also, >>> running mypy in daemon mode should speed that up even more >>> I have a PR[1] to allow developers to easily (and optionally) setup yapf to >>> run in a local git pre-commit hook; I'd like to do the same for mypy. >>> I will make myself and members of my team available to help out with typing >>> questions in PRs >>> >>> Is there anyone else on the list who is knowledgable about python static >>> typing who would like to volunteer to be flagged on typing questions? >>> >>> What else can we do to make this transition easier? >>> >>> [1] https://github.com/apache/beam/pull/10810 >>> >>> -chad >>>
Re: Python Static Typing: Next Steps
+1 The typing information has really helped me several times figuring out that API contracts and expected types. On Mon, Mar 2, 2020 at 9:54 AM Pablo Estrada wrote: > I am in favor of enabling the test, and also am happy to start answering > questions too. > Thanks so much Chad for leading this. > Best > -P. > > On Mon, Mar 2, 2020 at 9:44 AM Chad Dombrova wrote: > >> Good news everyone! >> We nearly have the full beam codebase passing in mypy. >> >> As we are now approaching the zero-error event horizon, I'd like to open >> up a discussion around enabling mypy in the PythonLint job. Every day or >> so a PR is merged that introduces some new mypy errors, so enabling this >> test is the only way I see to keep the annotations accurate and thus useful. >> >> Developer fatigue is a real concern here, since static typing has a a >> steep learning curve, and there are still not a lot of experts to help >> consult on PRs. Here are some things that I hope will mitigate those >> concerns: >> >>- We have a lot of tying coverage, so that means plenty of examples >>of how to solve different types of problems >>- Running mypy only takes 10 seconds to complete (if you execute it >>outside of gradle / tox), and that will get better when we get to 0 >>errors. Also, running mypy in daemon mode should speed that up even more >>- I have a PR[1] to allow developers to easily (and optionally) setup >>yapf to run in a local git pre-commit hook; I'd like to do the same for >>mypy. >>- I will make myself and members of my team available to help out >>with typing questions in PRs >> >> Is there anyone else on the list who is knowledgable about python static >> typing who would like to volunteer to be flagged on typing questions? >> >> What else can we do to make this transition easier? >> >> [1] https://github.com/apache/beam/pull/10810 >> >> -chad >> >>
Re: Python Static Typing: Next Steps
I am in favor of enabling the test, and also am happy to start answering questions too. Thanks so much Chad for leading this. Best -P. On Mon, Mar 2, 2020 at 9:44 AM Chad Dombrova wrote: > Good news everyone! > We nearly have the full beam codebase passing in mypy. > > As we are now approaching the zero-error event horizon, I'd like to open > up a discussion around enabling mypy in the PythonLint job. Every day or > so a PR is merged that introduces some new mypy errors, so enabling this > test is the only way I see to keep the annotations accurate and thus useful. > > Developer fatigue is a real concern here, since static typing has a a > steep learning curve, and there are still not a lot of experts to help > consult on PRs. Here are some things that I hope will mitigate those > concerns: > >- We have a lot of tying coverage, so that means plenty of examples of >how to solve different types of problems >- Running mypy only takes 10 seconds to complete (if you execute it >outside of gradle / tox), and that will get better when we get to 0 >errors. Also, running mypy in daemon mode should speed that up even more >- I have a PR[1] to allow developers to easily (and optionally) setup >yapf to run in a local git pre-commit hook; I'd like to do the same for >mypy. >- I will make myself and members of my team available to help out with >typing questions in PRs > > Is there anyone else on the list who is knowledgable about python static > typing who would like to volunteer to be flagged on typing questions? > > What else can we do to make this transition easier? > > [1] https://github.com/apache/beam/pull/10810 > > -chad > >
