+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/ >>> >>
