On Fri, Apr 10, 2020 at 4:00 PM Valentyn Tymofieiev <[email protected]> wrote:
> My preference is also for type-comments for now. > > Is it possible to configure the type checkers that we use to require > type-comments in new code? > My personal opinion is that there comes a point where there's diminishing return on explicitly typing everything (there's a reason people choose Python over Java) which is one of the big selling points of gradual typing, but before we can consider this the first step is to simply enable the type checkers on presubmit (IIRC we're really close). > On Fri, Apr 10, 2020 at 1:46 PM Robert Bradshaw <[email protected]> > wrote: > >> I prefer type-comments, as they can be validated by type checkers. Once >> we drop 2.7, we can go with actual type annotations (and the comments can >> be automatically converted over). >> >> On Fri, Apr 10, 2020 at 11:17 AM Valentyn Tymofieiev <[email protected]> >> wrote: >> >>> I am seeing several styles we use to annotate non-pipeline code in Beam >>> codebase: >>> >>> - informal docstring comments: >>> file_pattern (str): the file glob to read, >>> assign_context: Instance of AssignContext, >>> - type comments like # type: (...) -> iobase.RestrictionTracker >>> - pydoc-style annotation: A :class:`PTransform` object . >>> >>> It may be a good idea to create a guideline which style to use when, >>> that we can point at in code reviews, and be more consistent. >>> >>> Please suggest your opinions and preferences. >>> >>> Thanks >>> >>
