Why yield from instead of return? For the delayed evaluation of fields(self)? That’s the only potential advantage I see, although it can also be a disadvantage. And there are the other disadvantages of being slower to Iterate through the extra layer and being four characters more code.
Ah, yes in this case I guess you could just return the generator and you don’t need the yield from.
I agree with you! My point being “porque no los dos”.
It SHOULD be expressible in the type system in general. My point is even in that future world, the merit here (as it is with dataclasses in general) is not repeating yourself over and over and over and over (and the reason I support this is because when you have to repeat yourself over and over that’s ripe for subtle bugs/digressions)
Because of the reasons I mentioned above - it’s not particularly verbose, and for something that’s occasionally needed, having to write it yourself is acceptable. There’s no need to add every possible convenience to dataclasses, they are extensible by design. Very few dataclasses in my experience would benefit from unpacking support.
4 Likes
As far as I know, the type system doesn’t have a way to express a fixed length iterator whose member types are known.
It remains the case that you can unpack a tuple, a tuple can have its members typed, and methods can return tuples. I would tend to solve this, for a strictly typed codebase, with
@dataclass
class PetShop:
pets: list[Pet]
owner: str
def astuple(self) -> tuple[str, list[Pet]]:
return (self.owner, self.pets)
...
shop: PetShop
owner, pets = shop.astuple()
Getting strictly typed code often involves accommodating type checkers, either with your implementation choices, as above, or else with your hint related comments and casts.
Trying to argue for a feature because it offers better typing support is fine if you can express the types which should be used. Maybe someone can make the case for this and describe what the return type of __iter__ should be. But if you can’t describe the type, saying this will lead to better typing support is wishcasting onto typeshed and type checkers, and we should be careful to avoid doing that.
I don’t think the typing argument has much weight but I don’t really think that’s a reason to reject the feature. Just be realistic about what would happen if this were implemented. I’m pretty sure the return type would be Iterator[<Union of Field Types>].
2 Likes
To wit, I’ve never seen a dataclass use match_args or weakref_slot. Maybe once or twice I’ve seen order.
My main point about typing support is that if people are creating dataclass-likes that include an __iter__ method and would like those to be typed correctly then that’s an issue for dataclass_transform. Adding it to dataclasses should be because it’s generally useful to have for dataclasses specifically, not that it’s necessary in order for such a thing to be recognised by type checkers and other tools.
You could consider contributing this feature to attrs, and then to the attrs Mypy plugin (which is shipped with Mypy). I think that’s the easiest way this gets done without a PEP, modulo pyright support.
3 Likes