No checks are done on how many arguments concrete implementations take. So there is nothing stopping your from doing this already.

Just define those methods to take whatever parameters you need to accept:

class View(metaclass=ABCMeta):
    @abstractmethod
    def set(self):
        pass

    @abstractmethod
    def get(self):
        pass


class ConcreteView1(View):
    def set(self, param1):
        # implemenation

    def get(self, param1, param2):
        # implemenation


class ConcreteView2(View):
    def set(self):
        # implemenation

    def get(self, param1, param2):
        # implemenation

Other tools, such as linters, are a different matter. They could (rightly) claim that the above code violates the Livkov Substitution Principle, because you the subclasses and parent class take different arguments. But it is not Python itself that then tells you about this.

Pretty good!

Overall you have reasonable types, especially Array (though that should only be declared once). But your use of kwargs and setattr interferes with that type safety. There are type-safe ways around this: one way would be for Rational to be a @dataclass, and for its super to call into fields() or asdict(). Or without dataclasses, maybe __dict__ would work (so long as Rational stores offset, enumerator and denominator as members from its own constructor).

Though it's unlikely for eval to collide with the built-in eval, it's enough to confuse some syntax highlighters etc. Probably best to rename this.

This:

    powers_of_x = [x**i for i in range(len(self.enumerator))]

can be vectorised as

    powers_of_x = x ** np.arange(len(self.enumerator))

The __main__ guard is not enough to exclude P, etc. from the global namespace. That code should be moved to a main function.

Don't assert in production code; raise an exception instead.

In the end, I settled on providing the following:

class BaseAsyncSocketHandler:

    async def _send(self, data: bytes) -> int:
        ...

    @abc.abstractmethod
    async def send(self, *args, **kwargs) -> int:
        pass

This way the user can implement subsets of the send method while using the base send method provided by the socket wrapper. As to why I wanted to use send instead of just creating another class method like send_event, I think I mostly just wanted the interface to the class to remain compact and usable while allowing for different socket methodologies.

The very core of what you're trying to achieve goes against the core principle of polymorphism: interchangeability.

The concept of polymorphism is having the ability to write code that handles an object of type A and not having to care whether the actual object is of type A or any of its derived types (B, C, or any of their derived types recursively).
Having different signatures for different derived types breaks the ability to polymorphically treat these as indiscriminate A objects.

Essentially, polymorphism should allow you to write code that does this (I'm switching to C# because I'm more familiar with the syntax, but this point is not language-specific):

public void DoSomething(A myA)
{
    A.Foo(myValue1, myValue2, myValue3);
}

And this code should work for all of these use cases:

DoSomething(new A());
DoSomething(new B());
DoSomething(new C());

Needing to know the specific subtype being used, while the language does allow you to do so, is polymorphism abuse and indicative of bad design and something for which inheritance was not the right tool for the job.

Without repeating very common explanations found online in many guides and blog posts, look up what a Liskov Substitution Principle (LSP) violation is, and what an Open-Closed Principle (OCP) violation is. Your if isinstance(child_cls, B) is an instance of an LSP violation, and creating a chain of if is subtype checks is an OCP violation (the two principles are spiritually linked because they touch on similar topics.
This is precisely the problem you are creating by designing your derived types in a way that a consumer needs to know whether it's B or C.

The problem here is that I can't give you the answer, because I can't tell what it is that you're trying to achieve in practice. You've told me how you want to implement your code, you've not told me why, or what you're hoping to achieve.

The only thing I can say for a fact here is that what you're trying to achieve is not achievable using polymorphism, by the very core definition of what polymorphism is. You need to go back to the drawing board on this one, research OOP concepts (I suggest revisiting what polymorphism is, and looking up SOLID guidelines and what to avoid), and then use that newfound knowledge to come up with a better solution.

What you're trying to do will just work—but it's a very bad idea.

In general, you don't want to change the signature of a method in incompatible ways when overriding. That's part of the Liskov Substitution Principle.

In Python, there are often good reasons to violate that—inheritance isn't always about subtyping.

But when you're using ABCs to define an interface, that's explicitly about subtyping. That's the sole purpose of ABC subclasses and abstractmethod decorators, so using them to mean anything else is at best highly misleading.

In more detail:

By inheriting from Agent, you are declaring that any instance of Clever_Agent can be used as if it were an Agent. That includes being able to call my_clever_agent.perceive_world(my_observation). In fact, it doesn't just include that; that's the entirely of what it means! If that call will always fail, then no Clever_Agent is an Agent, so it shouldn't claim to be.

In some languages, you occasionally need to fake your way around interface checking, so you can later type-switch and/or "dynamic-cast" back to the actual type. But in Python, that's never necessary. There's no such thing as "a list of Agents", just a list of anything-at-alls. (Unless you're using optional static type checking—but in that case, if you need to get around the static type checking, don't declare a static type just to give yourself a hurdle to get around.)

In Python, you can extend a method beyond its superclass method by adding optional parameters, and that's perfectly valid, because it's still compatible with the explicitly-declared type. For example, this would be a perfectly reasonable thing to do:

class Clever_Agent(Agent):
    def perceive_world(self, observation, prediction=None):
        print('I see %s' % observation)
        if prediction is None:
            print('I have no predictions about what will happen next')
        else:
            print('I think I am going to see %s happen next' % prediction)

Or even this might be reasonable:

class Agent(ABC):
    @abstractmethod
    def perceive_world(self, observation, prediction):
        pass

class Dumb_agent(Agent):
    def perceive_world(self, observation, prediction=None):
        print('I see %s' % observation)
        if prediction is not None:
            print('I am too dumb to make a prediction, but I tried anyway')

class Clever_Agent(Agent):
    def perceive_world(self, observation, prediction):
        print('I see %s' % observation)
        print('I think I am going to see %s happen next' % prediction)

Before abc was introduced you would see this frequently.

class Base(object):
    def go(self):
        raise NotImplementedError("Please Implement this method")


class Specialized(Base):
    def go(self):
        print "Consider me implemented"