+1 And, well articulated, @Robert Burke <rob...@frantil.com> !
On Wed, Nov 9, 2022 at 10:43 AM Robert Burke <rob...@frantil.com> wrote: > +1 to standardizing on "type hint" > > I learned that there's a rule in English that defines when one would have > a space in a compound word or not. If removing one of the components would > change the meaning of the others, the space should be removed. > > Eg. By removing "type", it's still a hint, so "type hint" is appropriate. > > This rule is why the Apple products are "MacBooks" or "AirPods" rather > than "Mac Book" and "Air Pods". Without the Mac, the laptop isn't a Book. > Without the Air, it's not a "pod". > > > > On Wed, Nov 9, 2022, 10:35 AM Kenneth Knowles <k...@apache.org> wrote: > >> +1 to "type hint" for referring to hinting that something has a >> particular type, and "type" for referring to a... type. >> >> On Mon, Nov 7, 2022 at 7:27 AM Jack McCluskey via dev < >> dev@beam.apache.org> wrote: >> >>> I'm in agreement that how we refer to type hints in documentation should >>> be standardized across the board. It's a good practice for both style and >>> clarity. Seems like it wouldn't be too hard to update our docstrings >>> either, based on a quick search of the repo. >>> >>> On Mon, Nov 7, 2022 at 9:00 AM Brian Hulette via dev < >>> dev@beam.apache.org> wrote: >>> >>>> Hi everyone, >>>> >>>> In a recent code review we noticed that we are not consistent when >>>> describing python type hints in documentation. Depending on who wrote the >>>> patch, we switch between typehint, type-hint, and "type hint" [1]. >>>> >>>> I think we should standardize on "type hint" as this is what Guido used >>>> in PEP 484 [2]. Please comment on the issue in the next few days if you >>>> disagree with this approach. >>>> >>>> Note this is orthogonal to how we refer to type hints in _code_, in our >>>> public APIs. In general we use "type" in that context (e.g. >>>> `with_input_types`), and there doesn't seem to be a consistency issue. >>>> >>>> [1] https://github.com/apache/beam/issues/23950 >>>> [2] https://peps.python.org/pep-0484/ >>>> >>>
