You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Brian Hulette via dev <de...@beam.apache.org> on 2022/11/07 14:00:12 UTC
[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/
Re: [Python][Bikeshed] typehint vs. type-hint vs. "type hint"
Posted by Austin Bennett <wh...@gmail.com>.
+1
And, well articulated, @Robert Burke <ro...@frantil.com> !
On Wed, Nov 9, 2022 at 10:43 AM Robert Burke <ro...@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 <ke...@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/
>>>>
>>>
Re: [Python][Bikeshed] typehint vs. type-hint vs. "type hint"
Posted by Robert Burke <ro...@frantil.com>.
+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 <ke...@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 <de...@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 <de...@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"
Posted by Kenneth Knowles <ke...@apache.org>.
+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 <de...@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 <de...@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"
Posted by Jack McCluskey via dev <de...@beam.apache.org>.
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 <de...@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/
>