On Mon, Apr 13, 2020 at 11:48 AM Valentyn Tymofieiev <[email protected]> wrote:
> > On Mon, Apr 13, 2020 at 10:53 AM Robert Bradshaw <[email protected]> > wrote: > >> On Mon, Apr 13, 2020 at 10:38 AM Valentyn Tymofieiev <[email protected]> >> wrote: >> >>> To clarify, I don't suggest that every variable should have a defined >>> type that doesn't change. However, I'd like to establish a culture where we >>> consistently add type annotations when we write new code. Where type is >>> defined gradually, we can use flexible annotations: "# type: (Any) -> Any" >>> or something like that. >>> >> >> IMHO we should use such annotations when the inputs/outputs are truly >> Any, or at least a wide enough variety of types that it's not worth the >> effort to be more explicit. >> > Agreed. > >> >> >>> We can argue that there is a point of diminishing returns as well, and >>> this is a valid point too. A possible tradeoff may be to >>> require annotations, docstrings or both in *most* functions/methods. >>> Possible definition of 'most' - all functions unless they meet three of the >>> following criteria[1]: >>> - not externally visible >>> - very short >>> - obvious >>> >>> [1] >>> http://google.github.io/styleguide/pyguide.html#383-functions-and-methods >>> <http://google.github.io/styleguide/pyguide.html> >>> >> >> While I'd be open to this. Let's get the type checkers enabled in >> presubmit and see what it takes to keep those happy before establishing >> more strict criterea. >> > That's reasonable, thanks for your feedback. Is there a JIRA issue > tracking this effort? > https://issues.apache.org/jira/browse/BEAM-7746 > (It does sound like we have consensus on using type comments until 2.7 is >> dropped.) >> >> >>> On Fri, Apr 10, 2020 at 4:56 PM Robert Bradshaw <[email protected]> >>> wrote: >>> >>>> 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 >>>>>>> >>>>>>
