Alex Waygood <[email protected]> added the comment:
Consider the typeshed stub for `concurrent.futures.DoneAndNotDoneFutures`. At
runtime this is a `collections.namedtuple`, but in the stub, we need it to be
generic to allow precise type inference. But we can't have a generic
NamedTuple, so the stub is currently this:
```
class DoneAndNotDoneFutures(Sequence[set[Future[_T]]]):
@property
def done(self) -> set[Future[_T]]: ...
@property
def not_done(self) -> set[Future[_T]]: ...
def __new__(_cls, done: set[Future[_T]], not_done: set[Future[_T]]) ->
DoneAndNotDoneFutures[_T]: ...
def __len__(self) -> int: ...
@overload
def __getitem__(self, __i: SupportsIndex) -> set[Future[_T]]: ...
@overload
def __getitem__(self, __s: slice) -> DoneAndNotDoneFutures[_T]: ...
```
Until two days ago, this stub actually had a bug: `done` and `not_done` were
both given as writeable attributes, whereas they are read-only properties at
runtime.
With generic NamedTuples, we could write the stub for the class far more simply
(and more accurately) like this:
```
class DoneAndNotDoneFutures(NamedTuple, Generic[_T]):
done: set[Future[_T]]
not_done: set[Future[_T]]
```
And in code that actually needs to run at runtime, I frequently find it
frustrating that I have to use dataclasses instead of NamedTuples if I want a
simple class that just happens to be generic. dataclasses are great, but for
small, lightweight classes, I prefer to use NamedTuples where possible. I often
find that I don't need to use the full range of features dataclasses provide;
and NamedTuples are often more performant than dataclasses, especially in cases
where there's a lot of tuple unpacking.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue43923>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
