I agree with @Reinderien that this shouldn't be a class. You can see evidence for this in your constructor:

def __init__(self, input_list:list)->list:    self.input_list = input_list    self.__iter__()

You are constructing the object (and calling the constructor) simply to callself.__iter__(). There is no reason for the creation of an object here just to sort the list. If you needed to maintain some state between sorts or something (I'm not sure why you would though), then itmay be appropriate.

I'll also point out, you're attempting to violate at least two "contracts" with your usage of__init__ and__iter__:

• __init__ must return None:

  no non-None value may be returned by__init__(); doing so will cause a TypeError to be raised at runtime.

  Now, you aren'tactually returning anything, but your type hinting is saying that you are. If you're going to use type hinting, the hints should make it clearer what types are involved, not make false claims.

• __iter__ should return an iterator:

  This method should return a new iterator object that can iterate over all the objects in the container

  The problem is, you're returning a list, and a list isn't aniterator, it's aniterable (ithas an iterator). This isn't just a theoretical problem. Note how this can bite you:

  class T:    def __iter__(self):        return [1, 2, 3]for n in T():    print(n)# TypeError: iter() returned non-iterator of type 'list'

Use of "dunder" methods can be helpful for writing clean code, but only if you aren't abusing them. Make sure to read the documentation and understand the purpose and contracts of methods before attempting to use them.

And on the subject of type hints, you could make use of aTypeVar to allow the type checker to see the consistency between the element types going in and out of your sorting function. After making your class into a standalone function, you basically have:

def selection_sort(input_list: list) -> list:

The problem with this is, it doesn't tell the checker what the relationship is between the types of elements ininput_list and that of the list thatselection_sort returns. This can lead to subtle issues where it won't be able to help you with types:

lst: List[int] = [1, 2, 3]sorted_list = selection_sort(input_list)x = sorted_list[0]  # It has no idea what type x is

You can fix this by introducing aTypeVar that tells it that the element type remains consistent. I'm also changing from usinglist toList sincelist doesn't seem to support generics yet:

from typing import List, TypeVarT = TypeVar("T")# The sort returns the same element type T that it receiveddef selection_sort(input_list: List[T]) -> List[T]:    . . .

Now, it is able to infer the type ofx, and can give you better completions and type warnings.

This is mostly pretty good. Only a couple of things:

Delete this -

    print(self.input_list)

You should leave printing to the caller.

Also - why the class at all? This really boils down to a single function. You only have one member variable, and only one method.

There's another issue - this class results in "surprising mutation". Iterating over it modifies one of its members. This is another argument for a simple function. If you keep the class, you could possibly

• Cache the sorted output, as a separate list from the input list, and/or
• store a copy of the input list instead of the input list itself.

That last point speaks to another issue - you assume that you're being passed a list, which isn't strictly necessary; all you need is an iterable. If you create a list from the input, you place fewer demands on your caller.

• python
• beginner
• algorithm
• object-oriented
• sorting