Re: [Python][Bikeshed] typehint vs. type-hint vs. "type hint"
+1 And, well articulated, @Robert Burke ! On Wed, Nov 9, 2022 at 10:43 AM Robert Burke 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 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/ >>>
Re: [Python][Bikeshed] typehint vs. type-hint vs. "type hint"
+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 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 > 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 >> 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/ >>> >>
Re: [Python][Bikeshed] typehint vs. type-hint vs. "type hint"
+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 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 > 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/ >> >
Re: [Python][Bikeshed] typehint vs. type-hint vs. "type hint"
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 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/ >
[Python][Bikeshed] typehint vs. type-hint vs. "type hint"
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/
