You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To annotate a generator yielding an int, it’s
--> Generator[int, None, None]
That's really quite ugly.
It should be Generator[int]
Passing None does not fit the rest of Python where arguments are optional. Also in the rest of Python, the common cases are the default. This makes an unlikely case most prominent over the far more common case. It’s Python’s job to provide syntactic sugar to deal with the low-level details, not the user. This looks more like C.
“Alternatively, annotate your generator as having a return type of either Iterable[YieldType] or Iterator[YieldType]”
Yes a generator is an iterator and an iterator is an iterable but then why not set everything as Any? Are we annotating the types or not? That advice makes a mockery of the whole idea. Makes Python harder to teach for no good reason. "Put the type the function returns, unless it's a generator then do this..."
Several people have pointed this out before, their bugs got closed without explanation. One suggested making a bug here, so this is it. Enjoy.
There's a good reason that Generator has three type parameters. If you omit type arguments, they will be assumed to be Any (by PEP 484 rules), and I don't think that's what you want.
It sounds like what you're looking for is a simplified version of Generator that assumes the last two type arguments are None. One option is to create a type alias such as SimpleGenerator = Generator[T, None, None]. Another option, as others have suggested, is to use Iterable[YieldType] or Iterator[YieldType].
There has been some discussion about adding support for default type arguments, but nothing has been finalized. If default type arguments are added to the type, it would be possible to omit type arguments without having them default to Any.
#307 proposes supporting defaults for TypeVars. Generator is definitely one of the most compelling use cases. However, I don't think we should special-case just Generator, especially with the workarounds @erictraut lists, so I'll close this issue as a duplicate.
If you're interested in pursuing this, we should discuss it further in #307 and write a PEP.
There's a good reason that Generator has three type parameters. If you omit type arguments, they will be assumed to be Any (by PEP 484 rules), and I don't think that's what you want.
Why would Any be a problem here if they are never used?
One option is to create a type alias such as SimpleGenerator = Generator[T, None, None].
Alias is better advise, that probably should be in the documentation in my opinion.
from typing import Generator
IntGenerator = Generator[int, None, None]
To annotate a generator yielding an int, it’s
--> Generator[int, None, None]
That's really quite ugly.
It should be Generator[int]
Passing None does not fit the rest of Python where arguments are optional. Also in the rest of Python, the common cases are the default. This makes an unlikely case most prominent over the far more common case. It’s Python’s job to provide syntactic sugar to deal with the low-level details, not the user. This looks more like C.
https://docs.python.org/3/library/typing.html#typing.Generator
“Alternatively, annotate your generator as having a return type of either Iterable[YieldType] or Iterator[YieldType]”
Yes a generator is an iterator and an iterator is an iterable but then why not set everything as Any? Are we annotating the types or not? That advice makes a mockery of the whole idea. Makes Python harder to teach for no good reason. "Put the type the function returns, unless it's a generator then do this..."
Several people have pointed this out before, their bugs got closed without explanation. One suggested making a bug here, so this is it. Enjoy.
python/mypy#4221
https://bugs.python.org/issue31700
I'm hoping this bug gets closed because someone's already fixed it in a development version 😎.
Cheers.
The text was updated successfully, but these errors were encountered: