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? > > (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 >>>>>> >>>>>
