As with most script languages, you can hit the ground running in a very procedural sort of way, as you don’t even have to define a main entry point. You just start coding.
But Python certainly has an object model. If I’m not mistaken, everything in Python is an object. Like even functions.
I suppose there are some aspects of the class implementation that feel a little tacked on? Like the way you need to manage the self reference manually where it may be implicitly handled for you in other languages. At least the way you call super() now is a lot less kludgy.
One thing I miss a bit in Python is method overloading. In a general sense, function overloading is not an OOP feature per se, but I find it useful in OOP, particularly with object initializers. You can sort of achieve it with @functools.singledispatch but it’s pretty janky. For initialization, I prefer keeping the __init__ method pretty rudimentary and writing factory functions to do more complex initializations. And with @dataclass, you can forego writing an __init__ altogether if you do it that way.
As with most script languages, you can hit the ground running in a very procedural sort of way, as you don’t even have to define a main entry point. You just start coding.
But Python certainly has an object model. If I’m not mistaken, everything in Python is an object. Like even functions.
I suppose there are some aspects of the class implementation that feel a little tacked on? Like the way you need to manage the self reference manually where it may be implicitly handled for you in other languages. At least the way you call
super()now is a lot less kludgy.One thing I miss a bit in Python is method overloading. In a general sense, function overloading is not an OOP feature per se, but I find it useful in OOP, particularly with object initializers. You can sort of achieve it with
@functools.singledispatchbut it’s pretty janky. For initialization, I prefer keeping the__init__method pretty rudimentary and writing factory functions to do more complex initializations. And with@dataclass, you can forego writing an__init__altogether if you do it that way.