The key is that a Slice is an object, like everything else in Python.

The line cls = self.__class__ makes cls the Deck class.

What is returned is a Deck instance whose cards are the specified slice of the cards from the object executing the __getitem__ method.

In other words, this retrieves a slice of the cards in the current Deck. The slice is returned as the cards in a newly created Deck object. 

The class Deck inherits from Sequence of Cards. Therefore, Desk is a Sequence of Cards, with some added functionalities like play, deal, add_card (essentially everything that is defined in the class def of Deck) that are not available to the normal Sequence[Card] class/object. If you remove everything from the class def of Deck, it is just as good as the Sequence[Card]. And so, yes you can say Desk is a Sequence of Cards (all the time; not just initially) but not the other way around. That is how I understand it.

Oh I see what you're saying. Actually it is a clever way to avoid hard-coded initialization. cls(self.cards[key]) actually creates a new object of Deck, equivalent to the statement Deck(self.cards[key]) , however, to avoid explicitly stating the class name Deck, he fetched it from self.__class___ . Because if Deck is renamed to something else, or some other class inherits from Deck and object of that class invokes __getitem__ then it should create an instance of appropriate class. I am pretty sure that is why he did this, however I would really want others to comment on that.

Just read Jay's comment. Makes sense as a way to be extra cautious. 

This discussion is going on for quite a while, but ... we can make a teaching moment out of it.

 One can make a good case for the cls line.

 One of the basic principles of good programming style is known as DRY (Don't repeat yourself). Suppose you have some code that does a computation and you find that you need that same computation elsewhere in your program. You might be tempted to copy and paste the code. But that's bad style -- and marks whoever does it as a poor programmer. Instead of copying and pasting, extract the code and make, e.g., a function out of it. Then refer to that function from both places where you need that computation.

The reason not to copy and paste is so that if you ever need to change the code, you won't have to remember to change it everywhere you copied it.

Consider these two versions of the portion of the code in question.

if isinstance(key, slice):
    cls = self.__class__
    return cls(self.cards[key])

if isinstance(key, slice):
    return Deck(self.cards[key])

The problem with the second version is that it results from copying and pasting Deck, the class name. That violates DRY.  A problem might arise if you decided to create a class called Hand for the hand a player holds. If you did that, you would have to change Deck to Hand in two places: the class definition and this bit of code. Forgetting to change it creates a bug. (Jay made a similar point above.)

Writng the code as Hjelle did respects DRY because it refers to the class name rather than copying it.

Since Hjelle is a strong coder and cares about the quality of his code, he may have decided that not violating DRY, even in a minor case like this, was worth the extra line.

One can also make a good case against the cls line.

The second version of the code is simpler and easier to understand than the original. One of the principles of writing Pythonic code is to write code that is simple and easy to understand. So the code that Hjelle wrote is not as Pythonic as it might be.

How should the conflict between these principles be resolved in this case? You tell me.