Requiring super().__init__() in subclass initialization of Agent and Model

[EwoutH]

Spin off discussion of #1937.

Basically: Do we or do we not require users to call super().__init__() in the subclass initialization of Agent and Model?

Not on a laptop right now, so can’t make a proper topic start, but here are ChatGPT’s thoughts:

In the Mesa agent-based modeling (ABM) library, a fundamental aspect of designing agents and models involves subclassing the core Agent and Model classes. A recent proposal suggests evaluating the necessity and implications of mandating the use of super().__init__() when initializing subclasses of Agent and Model. This proposal also raises the possibility of moving initializations to the __new__ method.

Considerations:

1. Python's Object-Oriented Paradigm: Python's approach to object-oriented programming inherently supports and encourages the use of super() to initialize parent classes. This practice ensures that the initialization code in the base class (here, Agent and Model) is executed, allowing these base classes to properly set up their instances.

2. Inheritance and Code Reusability: Requiring super().__init__() reinforces good programming practices, particularly in inheritance hierarchies. It ensures that any initialization logic in the base classes is not accidentally bypassed, which can be crucial for the functionality and stability of the subclasses.

3. Consistency and Readability: Standardizing the initialization pattern across the library could enhance consistency and readability of the code. Developers familiar with the library would have clear expectations about the initialization process of subclasses.

4. Impact on Current Implementations: Implementing this change would have implications for existing codebases using Mesa. It would require refactoring and might introduce compatibility issues.

5. Alternatives like __new__ Method: Moving initialization logic to the __new__ method is unconventional for Python classes, especially for high-level application logic. While __new__ is responsible for instance creation, __init__ is designed for instance initialization. Overloading __new__ could lead to confusing patterns and potentially unexpected behavior, especially for users less familiar with Python's deeper object-oriented mechanics.

Discussion Points:

• Feasibility and Best Practices: Is mandating super().__init__() the best practice in the context of Mesa's design philosophy and user base? How does it align with Python's broader object-oriented design principles?

• Impact Analysis: What would be the impact on existing models and agents if this change were implemented? How significant would the refactoring effort be for the Mesa community?

• Alternative Approaches: Are there any compelling reasons to consider alternatives like __new__ for initialization, despite their unconventional nature in Python?

• Community Feedback: It is also essential to gather feedback from the Mesa community, including contributors and users, to understand the practical implications and preferences.

Conclusion:

This discussion aims to explore the merits and potential challenges of requiring super().__init__() calls in Mesa's subclassing mechanism. A thorough examination of this proposal's alignment with Python's object-oriented principles, its impact on existing codebases, and community preferences will be critical in making an informed decision.

[quaquel]

For Agent it is already required, otherwise unique_id is not set, nor is the instance added to model._agents. So, requiring it also for Model is fine and proper Python practice anyway. For me, what is proper in Python supersedes any mesa or ABM-specific concerns.

[quaquel]

Why would RNG be part of instance creation? In my view, the moment you are assigning values to attributes on an instance (i.e., obj._seed = kwargs.get("seed") and obj.random = random.Random(obj._seed)), you are initializing an instance, and thus this belongs to __init__

To be clear, practicality beats purity, and I don't strongly care either way about this.

Where an argument might be made for using __new__ is in assigning an immutable unique_id to agents (although this would be a backward incompatible change).

[Corvince]

I also don't really care, but just out of curiosity, why do you think this is "proper Python", is there a reference for this?

Also I think our concept is a bit unusual so personally I have difficulties to assess what is "normal". I haven't used any other library where you mainly subclass predefined classes. If I subclass my own classes I would definitely use super(), but I think here the situation is a bit different. We somehow really need users to call super(), then why not take care of that for users by utilizing new?

Also, there is subclass_init, but I haven't dug into that yet.

[quaquel]

I had not heard of __init_subclass__ before, but it seems exactly meant for this use case.

__new__ is a constructor. It creates the instance but does not initialize anything. __init__ initializes an instance. __init_subclass__ is among other use cases for "some initialization code running after class creation". The initialization code here being unique_id, _agents, RNG, and perhaps other stuff.

[rht]

Why would RNG be part of instance creation?
new is a constructor. It creates the instance but does not initialize anything.
...
Where an argument might be made for using new is in assigning an immutable unique_id to agents (although this would be a backward incompatible change).

After having conversation with ChatGPT, this is what ChatGPT said:

Certainly! Let's consider a case where you want to create an immutable class, and you want to enforce that the value of the instance cannot be changed after it has been initialized. In this scenario, you might use new to create the instance with the initial value, and init to prevent any subsequent changes to that value.

In the case of the RNG seed, it may be considered immutable, and so would be fair to be initialized in __new__.

But considering additional use cases I have encountered, I find model.random being immutable to random.Random(...) be problematic, because I can't replace it with np.random.default_rng(...) or any custom RNG. At the very least, in my view, model.random needs to be mutable.

[rht]

Turns out that what ChatGPT said was inconsistent with my finding:

In [1]: import mesa
m
In [2]: a = mesa.Model()

In [3]: a.random
Out[3]: <random.Random at 0x3f1b270>

In [4]: a.random = 2

In [5]: a.random
Out[5]: 2

In [6]: a._seed
Out[6]: 0.7164919499297581

In [7]: a._seed = 3

In [8]: a._seed
Out[8]: 3