I agree with Robert to only put Any where it really can be any type. I'm not sure how much typing we should add. At minimum: external APIs and wherever mypy complains. Ideally I would like to have annotations everywhere, because this reduces uncertainty when modifying existing code. You are increasing test coverage (e.g. via mypy) when you add type annotations.
OTOH, the tradeoff is that adding types changes structural (duck) typing to nominal. To keep using structural typing you can define a custom Protocol type, which slightly increases code complexity and may be a barrier to entry for new developers. On Mon, Apr 13, 2020 at 12:11 PM Robert Bradshaw <rober...@google.com> wrote: > On Mon, Apr 13, 2020 at 11:48 AM Valentyn Tymofieiev <valen...@google.com> > wrote: > >> >> On Mon, Apr 13, 2020 at 10:53 AM Robert Bradshaw <rober...@google.com> >> wrote: >> >>> 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. >>> >> 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 <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 >>>>>>>> >>>>>>>
smime.p7s
Description: S/MIME Cryptographic Signature
