Let's deprecate `@no_type_check_decorator`
Hi, I recently posted a proposal to deprecate `typing.no_type_check_decorator` in Python 3.13, with a view to removing it in Python 3.15: https://github.com/python/cpython/issues/106309. `typing.no_type_check` and `typing.no_type_check_decorator` have both been in the typing module since its introduction in Python 3.5. However, the two decorators have been on a different journey since then. Some (though not all) major type checkers have added support for `typing.no_type_check`, and, while it's far from being a flagship feature of the typing module, it's reasonably popular among users. `typing.no_type_check_decorator`, on the other hand, has not (to my knowledge) had support added by any major type checkers in the past eight years, and has very little usage. While there have been a few feature requests to type checkers asking them to add support for `typing.no_type_check_decorator`, none of them have received many upvotes. At this point, I don't think it's worth it for type checkers to add support for `typing.no_type_check_decorator`, and I think it's unlikely that they ever will, or should. As such, continuing to advertise its existence in the typing module is frankly misleading to users. I therefore propose that we deprecate it, and schedule its removal. (I do not propose that we deprecate `typing.no_type_check.) If anybody objects to these plans, please comment on the GitHub issue — it's important that we don't remove anything unless there's consensus behind doing so! Thanks, Alex
Just to summarize the current status: * mypy: supports @no_type_check on functions, but not classes ( https://github.com/python/mypy/issues/607) and does not support @no_type_check_decorator (https://github.com/python/mypy/issues/6583) * pyanalyze: does not support either @no_type_check or @no_type_check_decorator * pyre: does not support either * pyright: does not support either, and declined to add support ( https://github.com/microsoft/pyright/issues/1448) * pytype does not support either ( https://github.com/google/pytype/issues/1452; the issue asks for @no_type_check_decorator but @no_type_check isn't supported either) Given that no type checker supports @no_type_check_decorator and few have been asked for it, I agree with deprecating it. @no_type_check is also not well-supported; only mypy supports it, and then only for functions but not classes. However, it appears to be reasonably popular among users, so deprecating it would be disruptive. Still, perhaps we should amend the docs ( https://docs.python.org/3.12/library/typing.html#typing.no_type_check) to indicate that the feature is not widely supported in reality. El sáb, 1 jul 2023 a las 15:38, Alex Waygood (<alex.waygood@gmail.com>) escribió:
Hi,
I recently posted a proposal to deprecate `typing.no_type_check_decorator` in Python 3.13, with a view to removing it in Python 3.15: https://github.com/python/cpython/issues/106309.
`typing.no_type_check` and `typing.no_type_check_decorator` have both been in the typing module since its introduction in Python 3.5. However, the two decorators have been on a different journey since then. Some (though not all) major type checkers have added support for `typing.no_type_check`, and, while it's far from being a flagship feature of the typing module, it's reasonably popular among users. `typing.no_type_check_decorator`, on the other hand, has not (to my knowledge) had support added by any major type checkers in the past eight years, and has very little usage. While there have been a few feature requests to type checkers asking them to add support for `typing.no_type_check_decorator`, none of them have received many upvotes.
At this point, I don't think it's worth it for type checkers to add support for `typing.no_type_check_decorator`, and I think it's unlikely that they ever will, or should. As such, continuing to advertise its existence in the typing module is frankly misleading to users. I therefore propose that we deprecate it, and schedule its removal. (I do not propose that we deprecate `typing.no_type_check.)
If anybody objects to these plans, please comment on the GitHub issue — it's important that we don't remove anything unless there's consensus behind doing so!
Thanks, Alex _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
Regarding @no_type_check, given that support for it is very limited and there exists an alternative (typing.Annotated), wouldn't this be a prime candidate for the Soft Deprecation marker currently in discussion ( https://github.com/python/steering-council/issues/199 )? That is to say, it gets no warnings or other runtime effects so there are not disruptions, but gets marked as soft deprecated in docs with a hint to use Annotated instead.
Just to summarize the current status:
* mypy: supports @no_type_check on functions, but not classes (https://github.com/python/mypy/issues/607) and does not support @no_type_check_decorator (https://github.com/python/mypy/issues/6583) * pyanalyze: does not support either @no_type_check or @no_type_check_decorator * pyre: does not support either * pyright: does not support either, and declined to add support (https://github.com/microsoft/pyright/issues/1448) * pytype does not support either (https://github.com/google/pytype/issues/1452; the issue asks for @no_type_check_decorator but @no_type_check isn't supported either)
Given that no type checker supports @no_type_check_decorator and few have been asked for it, I agree with deprecating it.
@no_type_check is also not well-supported; only mypy supports it, and then only for functions but not classes. However, it appears to be reasonably popular among users, so deprecating it would be disruptive. Still, perhaps we should amend the docs (https://docs.python.org/3.12/library/typing.html#typing.no_type_check) to indicate that the feature is not widely supported in reality.
El sáb, 1 jul 2023 a las 15:38, Alex Waygood (<alex.waygood@gmail.com>) escribió:
Hi,
I recently posted a proposal to deprecate `typing.no_type_check_decorator` in Python 3.13, with a view to removing it in Python 3.15: https://github.com/python/cpython/issues/106309.
`typing.no_type_check` and `typing.no_type_check_decorator` have both been in the typing module since its introduction in Python 3.5. However, the two decorators have been on a different journey since then. Some (though not all) major type checkers have added support for `typing.no_type_check`, and, while it's far from being a flagship feature of the typing module, it's reasonably popular among users. `typing.no_type_check_decorator`, on the other hand, has not (to my knowledge) had support added by any major type checkers in the past eight years, and has very little usage. While there have been a few feature requests to type checkers asking them to add support for `typing.no_type_check_decorator`, none of them have received many upvotes.
At this point, I don't think it's worth it for type checkers to add support for `typing.no_type_check_decorator`, and I think it's unlikely that they ever will, or should. As such, continuing to advertise its existence in the typing module is frankly misleading to users. I therefore propose that we deprecate it, and schedule its removal. (I do not propose that we deprecate `typing.no_type_check.)
If anybody objects to these plans, please comment on the GitHub issue — it's important that we don't remove anything unless there's consensus behind doing so!
Thanks, Alex _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
_______________________________________________ Typing-sig mailing list --typing-sig@python.org To unsubscribe send an email totyping-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address:dev@reggx.eu
Note that most uses of `no_type_check` I've seen are just as a function level type ignore, instead of the "my annotations aren't type hints" use case which Annotated can help with. On Sun, 2 Jul 2023 at 11:29, ReggX <dev@reggx.eu> wrote:
Regarding @no_type_check, given that support for it is very limited and there exists an alternative (typing.Annotated), wouldn't this be a prime candidate for the Soft Deprecation marker currently in discussion ( https://github.com/python/steering-council/issues/199 )?
That is to say, it gets no warnings or other runtime effects so there are not disruptions, but gets marked as soft deprecated in docs with a hint to use Annotated instead.
Just to summarize the current status:
* mypy: supports @no_type_check on functions, but not classes ( https://github.com/python/mypy/issues/607) and does not support @no_type_check_decorator (https://github.com/python/mypy/issues/6583) * pyanalyze: does not support either @no_type_check or @no_type_check_decorator * pyre: does not support either * pyright: does not support either, and declined to add support ( https://github.com/microsoft/pyright/issues/1448) * pytype does not support either ( https://github.com/google/pytype/issues/1452; the issue asks for @no_type_check_decorator but @no_type_check isn't supported either)
Given that no type checker supports @no_type_check_decorator and few have been asked for it, I agree with deprecating it.
@no_type_check is also not well-supported; only mypy supports it, and then only for functions but not classes. However, it appears to be reasonably popular among users, so deprecating it would be disruptive. Still, perhaps we should amend the docs ( https://docs.python.org/3.12/library/typing.html#typing.no_type_check) to indicate that the feature is not widely supported in reality.
El sáb, 1 jul 2023 a las 15:38, Alex Waygood (<alex.waygood@gmail.com>) escribió:
Hi,
I recently posted a proposal to deprecate `typing.no_type_check_decorator` in Python 3.13, with a view to removing it in Python 3.15: https://github.com/python/cpython/issues/106309.
`typing.no_type_check` and `typing.no_type_check_decorator` have both been in the typing module since its introduction in Python 3.5. However, the two decorators have been on a different journey since then. Some (though not all) major type checkers have added support for `typing.no_type_check`, and, while it's far from being a flagship feature of the typing module, it's reasonably popular among users. `typing.no_type_check_decorator`, on the other hand, has not (to my knowledge) had support added by any major type checkers in the past eight years, and has very little usage. While there have been a few feature requests to type checkers asking them to add support for `typing.no_type_check_decorator`, none of them have received many upvotes.
At this point, I don't think it's worth it for type checkers to add support for `typing.no_type_check_decorator`, and I think it's unlikely that they ever will, or should. As such, continuing to advertise its existence in the typing module is frankly misleading to users. I therefore propose that we deprecate it, and schedule its removal. (I do not propose that we deprecate `typing.no_type_check.)
If anybody objects to these plans, please comment on the GitHub issue — it's important that we don't remove anything unless there's consensus behind doing so!
Thanks, Alex _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.orghttps://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: dev@reggx.eu
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: hauntsaninja@gmail.com
Since `no_type_check_decorator` is supported by 0 type checkers after 8 years, I think it's time to declare that one a failure. But I don't really see much of a reason to change anything with regards to `no_type_check`. It's true that `@no_type_check` is partly or wholly unsupported by several type checkers, but that goes for lots of other parts of the typing module's API as well. The hope is that most major type checkers will aim to support as much of the typing API as possible, but it's ultimately the prerogative of each type checker to decide which parts of the API they do and don't want to support. If a user of mypy is unhappy that mypy doesn't yet support PEP-695, they can use pyright instead; if a user of pyright is unhappy that pyright doesn't yet support `@no_type_check`, they can use mypy instead. This is the advantage of a decentralised system. (I'm aware that it's easier said than done for a user to "just use a different type checker", but I think the point still stands -- the type checkers are *meant* to be in competition with each other to some extent, and this is an arena in which they can compete.) Unlike `@no_type_check_decorator`, `@no_type_check` is at least partly supported by at least one major type checker, and is reasonably popular among users. It's true you can often achieve a similar effect using a `# type: ignore` or `Annotated`, and perhaps if we were writing the typing module from scratch today, we wouldn't include it. But that doesn't mean that it's worth the disruption to existing users to deprecate it now. Should we "soft-deprecate `@no_type_check`? Maybe. But I feel like we're already at a place where it's not really advertised or promoted in the typing documentation: it has a fairly short entry quite far down in the docs. And as Shantanu says, other tools like `Annotated` or `# type: ignore` comments aren't always a 1:1 replacement for `@no_type_check`. Best, Alex On Sun, Jul 2, 2023 at 10:39 PM Shantanu Jain <hauntsaninja@gmail.com> wrote:
Note that most uses of `no_type_check` I've seen are just as a function level type ignore, instead of the "my annotations aren't type hints" use case which Annotated can help with.
On Sun, 2 Jul 2023 at 11:29, ReggX <dev@reggx.eu> wrote:
Regarding @no_type_check, given that support for it is very limited and there exists an alternative (typing.Annotated), wouldn't this be a prime candidate for the Soft Deprecation marker currently in discussion ( https://github.com/python/steering-council/issues/199 )?
That is to say, it gets no warnings or other runtime effects so there are not disruptions, but gets marked as soft deprecated in docs with a hint to use Annotated instead.
Just to summarize the current status:
* mypy: supports @no_type_check on functions, but not classes ( https://github.com/python/mypy/issues/607) and does not support @no_type_check_decorator (https://github.com/python/mypy/issues/6583) * pyanalyze: does not support either @no_type_check or @no_type_check_decorator * pyre: does not support either * pyright: does not support either, and declined to add support ( https://github.com/microsoft/pyright/issues/1448) * pytype does not support either ( https://github.com/google/pytype/issues/1452; the issue asks for @no_type_check_decorator but @no_type_check isn't supported either)
Given that no type checker supports @no_type_check_decorator and few have been asked for it, I agree with deprecating it.
@no_type_check is also not well-supported; only mypy supports it, and then only for functions but not classes. However, it appears to be reasonably popular among users, so deprecating it would be disruptive. Still, perhaps we should amend the docs ( https://docs.python.org/3.12/library/typing.html#typing.no_type_check) to indicate that the feature is not widely supported in reality.
El sáb, 1 jul 2023 a las 15:38, Alex Waygood (<alex.waygood@gmail.com>) escribió:
Hi,
I recently posted a proposal to deprecate `typing.no_type_check_decorator` in Python 3.13, with a view to removing it in Python 3.15: https://github.com/python/cpython/issues/106309.
`typing.no_type_check` and `typing.no_type_check_decorator` have both been in the typing module since its introduction in Python 3.5. However, the two decorators have been on a different journey since then. Some (though not all) major type checkers have added support for `typing.no_type_check`, and, while it's far from being a flagship feature of the typing module, it's reasonably popular among users. `typing.no_type_check_decorator`, on the other hand, has not (to my knowledge) had support added by any major type checkers in the past eight years, and has very little usage. While there have been a few feature requests to type checkers asking them to add support for `typing.no_type_check_decorator`, none of them have received many upvotes.
At this point, I don't think it's worth it for type checkers to add support for `typing.no_type_check_decorator`, and I think it's unlikely that they ever will, or should. As such, continuing to advertise its existence in the typing module is frankly misleading to users. I therefore propose that we deprecate it, and schedule its removal. (I do not propose that we deprecate `typing.no_type_check.)
If anybody objects to these plans, please comment on the GitHub issue — it's important that we don't remove anything unless there's consensus behind doing so!
Thanks, Alex _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.orghttps://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: dev@reggx.eu
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: hauntsaninja@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: alex.waygood@gmail.com
I don't think that we should ever deprecate (or soft-deprecate) `no_type_check`, because multiple runtime type checkers rely on it. One example: https://github.com/search?q=repo%3Abeartype%2Fbeartype%20no_type_check&type=code But, I agree that `no_type_check_decorator` should be deprecated in 3.13. пн, 3 июл. 2023 г. в 14:27, Alex Waygood <alex.waygood@gmail.com>:
Since `no_type_check_decorator` is supported by 0 type checkers after 8 years, I think it's time to declare that one a failure. But I don't really see much of a reason to change anything with regards to `no_type_check`.
It's true that `@no_type_check` is partly or wholly unsupported by several type checkers, but that goes for lots of other parts of the typing module's API as well. The hope is that most major type checkers will aim to support as much of the typing API as possible, but it's ultimately the prerogative of each type checker to decide which parts of the API they do and don't want to support. If a user of mypy is unhappy that mypy doesn't yet support PEP-695, they can use pyright instead; if a user of pyright is unhappy that pyright doesn't yet support `@no_type_check`, they can use mypy instead. This is the advantage of a decentralised system.
(I'm aware that it's easier said than done for a user to "just use a different type checker", but I think the point still stands -- the type checkers are *meant* to be in competition with each other to some extent, and this is an arena in which they can compete.)
Unlike `@no_type_check_decorator`, `@no_type_check` is at least partly supported by at least one major type checker, and is reasonably popular among users. It's true you can often achieve a similar effect using a `# type: ignore` or `Annotated`, and perhaps if we were writing the typing module from scratch today, we wouldn't include it. But that doesn't mean that it's worth the disruption to existing users to deprecate it now.
Should we "soft-deprecate `@no_type_check`? Maybe. But I feel like we're already at a place where it's not really advertised or promoted in the typing documentation: it has a fairly short entry quite far down in the docs. And as Shantanu says, other tools like `Annotated` or `# type: ignore` comments aren't always a 1:1 replacement for `@no_type_check`.
Best, Alex
On Sun, Jul 2, 2023 at 10:39 PM Shantanu Jain <hauntsaninja@gmail.com> wrote:
Note that most uses of `no_type_check` I've seen are just as a function level type ignore, instead of the "my annotations aren't type hints" use case which Annotated can help with.
On Sun, 2 Jul 2023 at 11:29, ReggX <dev@reggx.eu> wrote:
Regarding @no_type_check, given that support for it is very limited and there exists an alternative (typing.Annotated), wouldn't this be a prime candidate for the Soft Deprecation marker currently in discussion ( https://github.com/python/steering-council/issues/199 )?
That is to say, it gets no warnings or other runtime effects so there are not disruptions, but gets marked as soft deprecated in docs with a hint to use Annotated instead.
Just to summarize the current status:
* mypy: supports @no_type_check on functions, but not classes ( https://github.com/python/mypy/issues/607) and does not support @no_type_check_decorator (https://github.com/python/mypy/issues/6583) * pyanalyze: does not support either @no_type_check or @no_type_check_decorator * pyre: does not support either * pyright: does not support either, and declined to add support ( https://github.com/microsoft/pyright/issues/1448) * pytype does not support either ( https://github.com/google/pytype/issues/1452; the issue asks for @no_type_check_decorator but @no_type_check isn't supported either)
Given that no type checker supports @no_type_check_decorator and few have been asked for it, I agree with deprecating it.
@no_type_check is also not well-supported; only mypy supports it, and then only for functions but not classes. However, it appears to be reasonably popular among users, so deprecating it would be disruptive. Still, perhaps we should amend the docs ( https://docs.python.org/3.12/library/typing.html#typing.no_type_check) to indicate that the feature is not widely supported in reality.
El sáb, 1 jul 2023 a las 15:38, Alex Waygood (<alex.waygood@gmail.com>) escribió:
Hi,
I recently posted a proposal to deprecate `typing.no_type_check_decorator` in Python 3.13, with a view to removing it in Python 3.15: https://github.com/python/cpython/issues/106309.
`typing.no_type_check` and `typing.no_type_check_decorator` have both been in the typing module since its introduction in Python 3.5. However, the two decorators have been on a different journey since then. Some (though not all) major type checkers have added support for `typing.no_type_check`, and, while it's far from being a flagship feature of the typing module, it's reasonably popular among users. `typing.no_type_check_decorator`, on the other hand, has not (to my knowledge) had support added by any major type checkers in the past eight years, and has very little usage. While there have been a few feature requests to type checkers asking them to add support for `typing.no_type_check_decorator`, none of them have received many upvotes.
At this point, I don't think it's worth it for type checkers to add support for `typing.no_type_check_decorator`, and I think it's unlikely that they ever will, or should. As such, continuing to advertise its existence in the typing module is frankly misleading to users. I therefore propose that we deprecate it, and schedule its removal. (I do not propose that we deprecate `typing.no_type_check.)
If anybody objects to these plans, please comment on the GitHub issue — it's important that we don't remove anything unless there's consensus behind doing so!
Thanks, Alex _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.orghttps://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: dev@reggx.eu
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: hauntsaninja@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: alex.waygood@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: n.a.sobolev@gmail.com
Instead, would it be possible for us to instead articulate a threshold of some type when we would feel comfortable deprecating these or other typing behaviors?
A little about how I think about deprecation and eventual removal. It's a weighing of the benefits (e.g. getting rid of footguns, reduced maintenance) against the costs (e.g. breaking users). In CPython, we want to be conservative, so we weigh the costs heavily. Weighing costs heavily often means we don't need to debate thresholds; if something is at all controversial, there's a decent chance we're being too aggressive. In the event of doubt or controversy, the Steering Council is very effective at providing final arbitration on these judgements, often via the PEP process. Deprecation timelines aren't set in stone and we can and have postponed removal, so there's a period of several years in which to make the right decisions and mitigate costs. In the case of no_type_check_decorator: Benefit: In 8 years, 0 type checkers support it. If any user tries to use it, they will be confused, because the symbol effectively does not work. Costs: Little. Unsurprisingly, we can't find usage online or in my experience. No one has chimed up in this thread. I find this a pretty straightforward decision to deprecate: there is a clear benefit and the cost is very close to zero. In the case of no_type_check: Benefit: It's inconsistently supported, so removing it could make the typing experience a little more consistent. Costs: It's used in many projects, both online and in my experience. I also find this straightforward: the only benefit is nebulous and we'd hurt users by removing it for no real reason.
by pointing to a GitHub search
I think online code search is a useful reality check, particularly so for positive evidence. No one's advocating for making decisions mechanically based on search results, but it is one of the better ways we have to get some semi-objective measurement.
soft deprecation
This is extremely new, so I'm not quite sure what this means, especially so in the context of typing. My instinct is to be cautious. I think it's fine to downgrade things like the PEP 585 deprecations into soft deprecations, but I'm a little worried about applying a new adjective to things there isn't clear consensus on, just because the new adjective doesn't have any costs.
+1 to everything Shantanu said. I'd also just like to add that, while online code searches are very useful, I agree that we shouldn't *just* rely on GitHub code searches before deprecating something. This is why I also took the step of writing to the typing-sig mailing list, to see if anybody on this list knew of any important use cases for this decorator that I was missing :-) Best, Alex On Mon, Jul 3, 2023 at 9:46 PM Shantanu Jain <hauntsaninja@gmail.com> wrote:
Instead, would it be possible for us to instead articulate a threshold of some type when we would feel comfortable deprecating these or other typing behaviors?
A little about how I think about deprecation and eventual removal. It's a weighing of the benefits (e.g. getting rid of footguns, reduced maintenance) against the costs (e.g. breaking users). In CPython, we want to be conservative, so we weigh the costs heavily. Weighing costs heavily often means we don't need to debate thresholds; if something is at all controversial, there's a decent chance we're being too aggressive.
In the event of doubt or controversy, the Steering Council is very effective at providing final arbitration on these judgements, often via the PEP process. Deprecation timelines aren't set in stone and we can and have postponed removal, so there's a period of several years in which to make the right decisions and mitigate costs.
In the case of no_type_check_decorator: Benefit: In 8 years, 0 type checkers support it. If any user tries to use it, they will be confused, because the symbol effectively does not work. Costs: Little. Unsurprisingly, we can't find usage online or in my experience. No one has chimed up in this thread.
I find this a pretty straightforward decision to deprecate: there is a clear benefit and the cost is very close to zero.
In the case of no_type_check: Benefit: It's inconsistently supported, so removing it could make the typing experience a little more consistent. Costs: It's used in many projects, both online and in my experience.
I also find this straightforward: the only benefit is nebulous and we'd hurt users by removing it for no real reason.
by pointing to a GitHub search
I think online code search is a useful reality check, particularly so for positive evidence. No one's advocating for making decisions mechanically based on search results, but it is one of the better ways we have to get some semi-objective measurement.
soft deprecation
This is extremely new, so I'm not quite sure what this means, especially so in the context of typing. My instinct is to be cautious. I think it's fine to downgrade things like the PEP 585 deprecations into soft deprecations, but I'm a little worried about applying a new adjective to things there isn't clear consensus on, just because the new adjective doesn't have any costs.
participants (6)
-
Alex Waygood -
Jelle Zijlstra -
Kevin Kirsche -
ReggX -
Shantanu Jain -
Никита Соболев