Sebastian Rittau comments

Results 518 comments of


                                            Sebastian Rittau

Question about stub symbols that begin with underscore

In theory, there is the [@type_check_only](https://docs.python.org/3/library/typing.html?highlight=type_check_only#typing.type_check_only) decorator, but that has never gained traction.

Question about stub symbols that begin with underscore

I'd like to see something like this formalized. But as it concerns stubs and type checkers in general, we should probably move this discussion to typing-sig.

Language specifications for strings

There are currently two ways that this could be implemented. Using `NewType`, which constrains the type: ```python from typing import NewType, cast HTMLString = NewType("HTMLString", str) def print_html(html: HTMLString) ->...

Make support for type comments optional

I don't think this change should be dependent on lazy evaluation and generics in the stdlib. Lazy evaluation is already available in all supported Python versions through `from __future__ import...

`type` and `disallow-any-generics`

We should at least fix this in typeshed and add a warning to flake8-pyi, although I agree that the type checker behavior seems inconsistent as well.

`typing.TYPE_CHECKER` object to change types depending on which type checker is being run

There was a related discussion in #1129 about feature flags or a similar field.

Allow `NotRequired[]` to be passed as a `TypeVar`

I am not sure I understand what you are trying to achieve here. `NotRequired` is currently only applicable to `TypedDict` fields and have no meaning outside them.

Both `typing.ByteString` and `typing.Text` are deprecated and slated for removal in Python 3.14

I think these issues have been fixed in HEAD.

Remove the performance regression comments

We could also define a threshold when to show this output. For example, if it got 1.5x slower or 1.5x faster to highlight potential problems. But in general I agree.

Warn on `Callable[<parameter_list>, None]` and `Callable[<parameter_list>, Any]` as parameter annotations

I'd personally split these two cases. `None` is probably always a mistake, while I can imagine use cases for `Any`.