On Mon, Apr 13, 2020 at 10:38 AM Valentyn Tymofieiev <valen...@google.com> 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. > 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. (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 <rober...@google.com> > wrote: > >> On Fri, Apr 10, 2020 at 4:00 PM Valentyn Tymofieiev <valen...@google.com> >> 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 <rober...@google.com> >>> 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 < >>>> valen...@google.com> 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 >>>>> >>>>
