You can reduce the amount of code:

• Throw away get_ methods, just use .name not .get_name()

• Throw away to_tuple and to_list by implementing __len__ to make the class iterable.

• Throw away __init__ and __repr__ by using dataclasses.

  __str__ can stay because your format is more 'str-like' than dataclasses's generated __repr__.

• Throw away __eq__, __lt__, __le__, __gt__, and __ge__ by using the eq and order options available in dataclasses.

  We will also need to tell dataclasses name should not be used in any of the comparison operators.

import dataclasses


@dataclasses.dataclass(eq=True, order=True)
class Person:
    name: str = dataclasses.field(compare=False)
    age: int
    height: int
    weight: int

    def __str__(self):
        return f"{self.name}, {self.age} years, {self.height} cm, {self.weight} kg"

    def __len__(self) -> int:
        return len(dataclasses.fields(self))

    def __getitem__(self, index: int) -> str | int:
        return getattr(self, dataclasses.fields(self)[index].name)

    def __int__(self):
        return int(self.age)

    def __float__(self):
        return float(self.age)


FOO = Person("foo", 1, 1, 1)
BAR = Person("bar", 2, 2, 2)

print(FOO)
print(repr(FOO))
print(FOO == BAR)
print(FOO < BAR)
print(FOO <= BAR)
print(FOO > BAR)
print(FOO >= BAR)
print(FOO[0])
print(int(FOO))
print(float(FOO))
print(tuple(FOO))
print(list(FOO))

I would then urge you to remove __len__, __getitem__, __int__, __float__, and order=True as I see no reason to make a person an iterable, a number, or ordered.

age is a poor choice of attribute, as it is constantly changing over the lifetime of the data (which might be many years in a long-running server, or if persisted to a database).

It's better to store birth date, and compute the age when it's needed.

1. The comparison dunder methods are not required for sorting Person by name, age, height or weight. It also leads to confusing behavior as semantically Person is not inherently sortable.
2. Not sure why dunder methods for conversion to int and float. Why should casting a Person to int even be permitted in the first place? This also has potential to confuse readers of your code.
3. Same with to_list, to_tuple etc.
4. Consider using dataclasses to get __repr__ and __str__ for free.

Your Person class can be as simple as:

@dataclass
class Person():
    
    name : str
    age : int
    height : float
    weight : float

type annotation

def create_persons_list(n=10, sort_key='height'):

Maybe you need that particular function name? But I don't think so. Prefer:

def create_persons(n: int = 10, sort_key: str = "height") -> list[Person]:

Better yet, us what you just created, like def create_graduating_class.

The annotation is meaningful to humans, to IDEs, and to mypy.

    person_objects = [
        (
            Person(
                np.random.choice(NAMES),
                np.random.randint(18, 101),
                np.random.randint(150, 201),
                np.random.randint(45, 101),
            )
        )
        for _ in range(n)
    ]

In python, everything is an object. So that suffix isn't helpful. Prefer to just assign persons = .... (Maybe people? Whatever.)

useless getters

    def get_name( ...
    def get_age( ...
    def get_height( ...
    def get_weight( ...

This isn't java. We're all adults here.

We only need the getters because you declared four attributes as _private. Consider ditching the getters and defining four public attributes in the ctor:

        self.name = name
        self.age = age
        self.height = height
        self.weight = weight

If you need to prohibit mutation, such as self._age += 1 on someone's birthday, fine. First document that immutability requirement so we understand the "why", then use a property decorator in the usual way. Then you will get an appropriate diagnostic:

    @property
    def age(self):
        return self._age
    ...
p = Person()
p.age += 1  # --> AttributeError: property 'age' of 'Person' object has no setter

But why are we writing tedious code like this at all? Prefer @dataclass, or an immutable namedtuple.

unused local

def create_persons_list( ...
    ...
    x = Person()

Please delete x.

1. It isn't used.
2. The other x down within lambda scope risks being confused with it.

attrgetter

    elif sort_key == 'weight':
        return mergesort(person_objects, key=lambda x: x.get_weight())

A lambda is an unnamed (anonymous) function.

But you wrote one for something that already has a name: attrgetter.

Prefer key=attrgetter(sort_key), without all those copy-n-pasted else clauses. Or perhaps key=attrgetter(f"_{sort_key}"). Or perhaps even methodcaller: key=methodcaller(f"get_{sort_key}").

total_order

    def __lt__(self, other):
        ...
    def __le__(self, other):
        ...
    def __gt__(self, other):
        ...
    def __ge__(self, other):

Write just one of those, and let the @total_ordering decorator sweat the details on the rest.

representation dunders

The __str__ method is nice enough.

DRY up __repr__ with:

        return f"{self}\n"

But wait! Consider altering the text it returns. Maybe repr(person) is working adequately for you? It is supposed to be a string that when pasted into the REPL will produce a new Person object. Try it with some namedtuple you define, to see the difference.

Similarly, DRY up to_list with:

    return list(self.to_tuple())

Or consider deleting that method, as we see no calling code which motivates it. In python, we use list for arbitrary number of "same" kind of thing, and we use tuple for fixed-length collection of different things where the meaning of an item is dictated by its position. For example in an (x, y) Point, both the [0] and [1] indexes are for floats, but the meanings of those floats are entirely different. Your to_tuple method does exactly the Right Thing in this regard.

notion of equality

    def __eq__(self, other):
        return (self._age, self._height, self._weight) == (other._age, other._height, other._weight)

Consider

alice = Person("Alice", 10, 135, 30)
bob   = Person("Bob",   10, 135, 30)
alice == bob

That seems a weird enough notion of "equals" that it at least warrants a """docstring""" explaining the business domain where that makes sense.

I am sad we didn't go with a namedtuple. If you require business logic that offers surprisingly different behavior from the familiar example of a tuple, fine. But at least document it.

make it comparable, sortable, subscriptable, iterable, and castable (to float, int, and string). I want to define everything once that no code is repeated - i.e. have D.R.Y. code.

I would be inclined to not give your class any of those properties (comparable, sortable, subscriptable, iterable, or castable). Since you seem to like initialisms, omitting those features would be more consistent with the "Keep it simple, Stupid" (KISS) and "You aren't going to need it" (YAGNI) principles. Somewhat also with the Principle of least astonishment (POLA).

Consider:

• What use do you imagine anyone might have for converting a Person to an int? Why do you suppose that the int they would want is the age property, as opposed to height or weight, or something altogether different such as a hash code? Why wouldn't they just say what they mean by reading the property value they want?

• Why do you suppose anyone would want to access the properties by index, or to iterate over their values? That would be nonsense for anyone who doesn't already know that the object is a Person, so as to be able to map indices to particular properties, and if you do know it's a person then accessing its properties directly, by name, would be more Pythonic.

• Why do you think the particular sort and comparison order you are implementing is so natural that it should be baked into the class? It's better not to have a built-in order at all than to have an arbitrary one. And a consequence of choosing the particular order you have done is a rather surprising implementation of __eq__(). In no way would I expect that two instances could be considered equal when their names differ, so this violates the POLA.

• Do you genuinely imagine that obtaining a list or tuple of an instance's properties are things that users of this class are so likely to want that it makes sense to build that into your class? And if so, that the order you have chosen will be suitable?

The DRY principle does not imply that you need to provide every functionality that you imagine someone else might want. That's a losing proposition, because your imagination is not nearly good enough (mine either). DRY is about minimizing repetition in your own code, mainly by good design and especially by factoring common code into reusable units to avoid repeating it.

In general, choose class features that yield a coherent result that is as natural and intuitive as possible to use. Within those guidelines, ensure that it has all the features that you need it to have, preferably from a holistic viewpoint of the overall design of the module, package, or application. Then stop.

There are a couple of DRYness consideration in the code that would leave, however:

• The if / elif / else chain in your create_persons_list() function is a bit wet because the mergesort() call is repeated with only changes in the specified key.

• you could dry out your code a little by removing its __str__ method. The default __str__() defers to __repr__(), which in your code produces the same output (plus a newline, which should be removed anyway). But really, __repr__() serves a different purpose than __str__(), the former is meant to be informative for development and debugging, whereas the latter, if it differs, is meant to be informative to human users. If you want the user-readable __str__(), then a better resolution might be to make __repr__() emit something more conventional.

If you left both to_list() and to_tuple() then that would present another dryness issue. You have repeated the element order in those functions, and it would be DRYer (and prevent them falling out of sync) to implement one in terms of the other.

Additionally, it is not conventional or Pythonic to endow classes with get_foo() property getter methods (and omitting setter methods does not prevent modifying instances' properties). Objects properties are Pythonically accessed directly by their names, e.g. a_person.age, another.height.

After all that dross is polished off, this is what's left of Person:

class Person():
    
    def __init__(self, name, age, height, weight):
        self.name = name
        self.age = age
        self.height = height
        self.weight = weight

    def __repr__(self):
        return f"Person('{self.name}', {self.age}, {self.height}, {self.weight})"

    def __str__(self):
        return f"{self.name}, {self.age} years, {self.height} cm, {self.weight} kg"

Only a few minor modifications are required elsewhere in your code:

def create_persons_list(n=10, sort_key='height'):
    
    person_objects = [(Person(np.random.choice(NAMES), np.random.randint(18, 101), np.random.randint(150, 201), np.random.randint(45, 101))) for _ in range(n)]

    if sort_key == 'name':
        return mergesort(person_objects, key=lambda x: x.name)
    elif sort_key == 'age':
        return mergesort(person_objects, key=lambda x: x.age)
    elif sort_key == 'height':
        return mergesort(person_objects, key=lambda x: x.height)
    elif sort_key == 'weight':
        return mergesort(person_objects, key=lambda x: x.weight)
    else:
        raise ValueError(f'unknown sort key: {key}')

... but if you really want to DRY that out, then something more like this would be better in that regard:

def create_persons_list(n=10, sort_key='height'):
    # Note: using this dict is dryer, but one could get dryer still
    # by leveraging getattr()
    keys = {
      'name':   lambda x: x.name,
      'age':    lambda x: x.age,
      'height': lambda x: x.height,
      'weight': lambda x: x.weight
    }
    
    person_objects = [(Person(np.random.choice(NAMES), np.random.randint(18, 101), np.random.randint(150, 201), np.random.randint(45, 101))) for _ in range(n)]

    # Note: this will raise a KeyError if the specified key is not among those
    # supported.  That creates a bit of a pun on the word "key", and it might
    # be advisable to rescue it to raise a ValueError (or some other) instead 
    return mergesort(person_objects, key=keys[sort_key])