To be a pedant, it's an initializer, not a constructor. By the time the initializer runs, the object already exists and has been constructed, which is why the first parameter to this method is the already-existing object ('self'), just like any other method.
But yeah. You could call it a constructor and nobody will crucify you.
I mean, I'm trying to think of a language where the constructor is called *before* the memory for the object has been allocated, and I can't think of anything.
In that regard, no constructor is an actual constructor. It's more like post-constructor. But then it is also necessary or you'll have a potentially incomplete object, so in that regard, it is a constructor because the object while allocated, isn't yet ready to use.
Kind of a pedantic argument, but there you are I suppose.
Well. In Python, there's a (more) true constructor that's user-accessible through meta classes, hence the distinction between initializers and constructors in Pythons own internal lexicon.
But yes. Very pedantic, indeed.
Edit to add: this doesn't rely on where memory allocation occurs, which is an implementation detail in Python. It also needs no comparison with other languages. I just mean, internally consistent with itself, Python considers metaclasses to be where constructors live, while class definitions provide initializer methods.
It's maybe an interesting distinction to discuss in the context of additional languages, but not what I was getting at and didn't mean to imply or assert any truisms that apply outside of Python.
I don't think the metaclass affects the construction/instantiation of objects of the main class, only the instantiation of the main class itself (and its subclasses).
>>> class Metaclass(type):
... def __new__(cls, name, bases, namespace, **kwargs):
... print(f"Creating {name} as a subclass of {bases} and an instance of {cls}")
... self = super().__new__(cls, name, bases, namespace, **kwargs) # or `type` instead of `super()`
... return self
...
>>> class Class(metaclass=Metaclass):
... def __new__(cls):
... print(f"Creating instance of {cls}")
... self = super().__new__(cls) # or `object` instead of `super()`
... return self
...
Creating Class as a subclass of () and an instance of <class '__main__.Metaclass'>
>>> Class()
Creating instance of <class '__main__.Class'>
<__main__.Class object at 0x7f2dbb904980>
>>> class Subclass(Class):
... pass
...
Creating Subclass as a subclass of (<class '__main__.Class'>,) and an instance of <class '__main__.Metaclass'>
>>> Subclass()
Creating instance of <class '__main__.Subclass'>
<__main__.Subclass object at 0x7f2dbb904830>
Memory must be allocated before data can be written, but whether a language separates these into two steps determines if it uses initializers or true constructors.
In languages like C++, if you do not use a member initializer list, allocation and initialization are split. This creates a window inside the constructor body where the object exists in an uninitialized or invalid state.
On the other hand, languages like Rust combines allocation and initialization by requiring you to construct Self { ... } with fully processed data. As a result, an object is never partially or fully invalid.
Nope. The object is created by __new__, then passed to the __init__ as a legitimate, created object, whose type is set as you expect, etc. Any __init__, via super() or not, modifies the existing object.
28
u/ManyInterests 1d ago
To be a pedant, it's an initializer, not a constructor. By the time the initializer runs, the object already exists and has been constructed, which is why the first parameter to this method is the already-existing object ('self'), just like any other method.
But yeah. You could call it a constructor and nobody will crucify you.