Data Classes for Representation

hi, another really outstanding course. my question relates to the section ‘Data Classes for Representation’. I did not understand, why you add your own .repr() method to deck and violate the principle that it should return code that can recreate an object. Why not add an appropriate .str method instead ?

Thanks a lot

Hi @dotnet, there are a few more details about this example in the written tutorial: realpython.com/python-data-classes/#you-need-representation

As you note, the better choice is usually to reserve .__repr__() for a representation that can recreate an object.

However, these cards are typically handled as a list of cards (i.e. a deck of cards) rather than individually. When you call str() on a regular Python list, it will use repr() on each individual element. So changing .__str__() of a card doesn’t help the representation of a deck.

The best way to get a decent string representation of a deck of cards is probably to define a custom list class representing a deck, maybe with collections.UserList. However, a simpler, more pragmatic approach, was chosen here: prioritize str() of a deck of cards over repr() of an individual card.

hi,

me again :-).

in my programm i use the following Deck definition (using .str() instead of .repr) and it works:

@dataclasses.dataclass class Deck: cards: list[PlayingCard] = dataclasses.field(default_factory=make_french_deck)

def __str__(self) -> str:
    cards = ', '.join(f'{c!s}' for c in self.cards)
    return f'{self.__class__.__name__}({cards})'

Hi again, @dotnet :)

Yes, I agree. That is a more pythonic implementation. It works but it leaves the representation of Deck very verbose (which it needs to be in order to be code that reproduces the deck).

As noted in the text, I opted to go for a solution that’s more convenient to play with interactively. Whether this is a good idea or not completely depends on your problem at hand as well as your preferred workflow.

The differences are on the margins anyway. For example, by keeping the implementation on .__str__() instead of .__repr__() you need to do something to get the compact representation. For example, calling str():

>>> str(Deck())
'Deck(♣2, ♣3, ♣4, ♣5, ♣6, ♣7, ♣8, ♣9, ♣10, ♣J, ♣Q, ♣K, ♣A, ♦2, ♦3, ♦4, ♦5, ♦6, ♦7, ♦8, ♦9, ♦10, ♦J, ♦Q, ♦K, ♦A, ♥2, ♥3, ♥4, ♥5, ♥6, ♥7, ♥8, ♥9, ♥10, ♥J, ♥Q, ♥K, ♥A, ♠2, ♠3, ♠4, ♠5, ♠6, ♠7, ♠8, ♠9, ♠10, ♠J, ♠Q, ♠K, ♠A)'

If you never use the capability of recreating a deck from its repr, then it might be worth it to override .__repr__() and avoid this:

>>> Deck()
Deck(cards=[PlayingCard(rank='2', suit='♣'), PlayingCard(rank='3', suit='♣'), PlayingCard(rank='4', suit='♣'), PlayingCard(rank='5', suit='♣'), PlayingCard(rank='6', suit='♣'), PlayingCard(rank='7', suit='♣'), PlayingCard(rank='8', suit='♣'), PlayingCard(rank='9', suit='♣'), PlayingCard(rank='10', suit='♣'), PlayingCard(rank='J', suit='♣'), PlayingCard(rank='Q', suit='♣'), PlayingCard(rank='K', suit='♣'), PlayingCard(rank='A', suit='♣'), PlayingCard(rank='2', suit='♦'), PlayingCard(rank='3', suit='♦'), PlayingCard(rank='4', suit='♦'), PlayingCard(rank='5', suit='♦'), PlayingCard(rank='6', suit='♦'), PlayingCard(rank='7', suit='♦'), PlayingCard(rank='8', suit='♦'), PlayingCard(rank='9', suit='♦'), PlayingCard(rank='10', suit='♦'), PlayingCard(rank='J', suit='♦'), PlayingCard(rank='Q', suit='♦'), PlayingCard(rank='K', suit='♦'), PlayingCard(rank='A', suit='♦'), PlayingCard(rank='2', suit='♥'), PlayingCard(rank='3', suit='♥'), PlayingCard(rank='4', suit='♥'), PlayingCard(rank='5', suit='♥'), PlayingCard(rank='6', suit='♥'), PlayingCard(rank='7', suit='♥'), PlayingCard(rank='8', suit='♥'), PlayingCard(rank='9', suit='♥'), PlayingCard(rank='10', suit='♥'), PlayingCard(rank='J', suit='♥'), PlayingCard(rank='Q', suit='♥'), PlayingCard(rank='K', suit='♥'), PlayingCard(rank='A', suit='♥'), PlayingCard(rank='2', suit='♠'), PlayingCard(rank='3', suit='♠'), PlayingCard(rank='4', suit='♠'), PlayingCard(rank='5', suit='♠'), PlayingCard(rank='6', suit='♠'), PlayingCard(rank='7', suit='♠'), PlayingCard(rank='8', suit='♠'), PlayingCard(rank='9', suit='♠'), PlayingCard(rank='10', suit='♠'), PlayingCard(rank='J', suit='♠'), PlayingCard(rank='Q', suit='♠'), PlayingCard(rank='K', suit='♠'), PlayingCard(rank='A', suit='♠')])

I’ll note here that it’s not necessarily the extra keypresses that is the challenge. It’s that it breaks the flow of working interactively, when I need to always think about which object is returned and then treat different objects differently.

That said, I would probably not make the same kinds of trade-offs in a library package where it’s better to avoid surprises for users.

I’ve added a short paragraph in the original text tutorial emphasizing this point.