Update pep-0718.rst#1
Conversation
Added more motivation and other small changes
for more information, see https://pre-commit.ci
|
@Gobot1234 maybe is better that you give me merge rights |
|
Sorry I somehow missed this PR being opened. Will review in a few |
|
|
||
|
|
||
|
|
||
| At runtime ``list[int]`` returns a ``GenericAlias`` that is later evaluated to an |
There was a problem hiding this comment.
| At runtime ``list[int]`` returns a ``GenericAlias`` that is later evaluated to an | |
| At runtime ``list[int]`` returns a ``GenericAlias`` that can be later called, returning an |
| This PEP opens the door to overloading based on type variables: | ||
|
|
||
| .. code-block:: python | ||
| @overload |
There was a problem hiding this comment.
| @overload | |
| @overload |
needs this to render properly
There was a problem hiding this comment.
todo, don´t see it in my editor
| For overloading resolution a new step will be required previous to any other, where the resolver | ||
| will match only the overloads where the subscription may succeed. For instance | ||
| if we have an overload make[*Ts], one with make[T], and one with just make, then a call to make[int] | ||
| will only consider the first and second, and a call to make[int, str] will only consider the first. |
There was a problem hiding this comment.
This should go after the definition I think. Also add back ticks here
| Generators would benefit inmensely from this feature as they can't be properly typed in many scenarios, | ||
| specially when they make use of the method ``.send``: | ||
|
|
||
| For example in a function that accumulates different types: |
| from typing import Generator, cast, Protocol, TypeVar | ||
|
|
||
| T = TypeVar("T") |
There was a problem hiding this comment.
i think is required for SupportAdd, mind that is not a container type so SupportsAdd[T] is not what we want.
or at least my linter like this version better
| Currently you have to use an assignment to provide a precise type: | ||
| def make_accumulator[T: SupportsAdd]() -> Generator[T, T]: | ||
| """ adds all elemenst using the addition operator """ | ||
| acc = yield cast(T, None) |
There was a problem hiding this comment.
None? is not really yielded in any usefull maner is for priming the generator only , that's why the cast is there
| functions where their signature is narrowed to different paths in different | ||
| parts of the code. | ||
|
|
||
| Another use case would be bounding direclty at the ``.send`` |
There was a problem hiding this comment.
but may be generic after this pep ?
| functions where their signature is narrowed to different paths in different | ||
| parts of the code. | ||
|
|
||
| Another use case would be bounding direclty at the ``.send`` |
There was a problem hiding this comment.
maybe doesn´t make much sense now that i'm thinking about it...
| This PEP opens the door to overloading based on type variables: | ||
|
|
||
| .. code-block:: python | ||
| @overload |
There was a problem hiding this comment.
todo, don´t see it in my editor
| For overloading resolution a new step will be required previous to any other, where the resolver | ||
| will match only the overloads where the subscription may succeed. For instance | ||
| if we have an overload make[*Ts], one with make[T], and one with just make, then a call to make[int] | ||
| will only consider the first and second, and a call to make[int, str] will only consider the first. |
for more information, see https://pre-commit.ci
|
Thanks, will have a look at the rest in the morning (utc) |
| Currently you have to use an assignment to provide a precise type: | ||
| def make_accumulator[T: SupportsAdd]() -> Generator[T, T]: | ||
| """ adds all elemenst using the addition operator """ | ||
| acc = yield cast(T, None) |
There was a problem hiding this comment.
I don't think this is a good example if you have to use cast, there's no harm in specifying it's Generator[T | None, T]
| def log_and_yield[T: SupportsAdd](log: Callable) -> Generator[T, T]: | ||
| value = yield cast(T, None) |
There was a problem hiding this comment.
| def log_and_yield[T: SupportsAdd](log: Callable) -> Generator[T, T]: | |
| value = yield cast(T, None) | |
| def log_and_yield[T: SupportsAdd](log: Callable[[T], Any]) -> Generator[T | None, T]: | |
| value = yield None |
|
I've made some updates to the code. I do have some reservations about the generator section as it seems kind of contrived, do you have any full examples where this would be useful. Looking at the code it seems like you could just wait to create the generators after you have a first value to feed into it to avoid the cast |
|
sorry, I was a bit disconnected this months, i saw there is recently some updates on the pep, let me know if you need help, probably this pr can be closed as you already included the changes, and btw many thanks! |
2 participants
Still is a bit WIP, but you can start reviewing if you wish