Python Does Not Fully Deliver OOP Encapsulation Functionalities
...and what we must always obey as programmers.
Using access modifiers (public, protected, and private) is fundamental to encapsulation in OOP.
This is not just about Python but applicable to OOP in general.
However, when we talk specifically about Python, we notice that it fails to deliver true encapsulation procedures, which one would want to leverage in their OOP code.
How?
Let’s understand this today!
As you may already know, class attributes in OOP can be of three types:
A public member is accessible everywhere inside and outside the base class, and it is inherited by all child classes.
A protected member is accessible everywhere inside the base class and child class(es). It is not accessible outside the class.
A private member is accessible only inside the base class.
But, with Python, there are no such strict enforcements. This is unlike many other programming languages like C++.
Thus, protected members behave exactly like public members.
What’s more, private members can be (somehow) accessed outside the class as well.
For better clarity, consider the following class implementation:
Syntactically speaking, in Python:
A public member is declared with 0 leading underscores.
A protected member is declared with 1 leading underscore.
A private member is declared with 2 leading underscores.
Next, we instantiate a class object:
Moving on, as one would expect, the public attribute is accessible outside the class:
However, in a similar way, even the protected attribute is accessible outside the class, which, ideally, should not happen:
Lastly, when declaring private members, Python performs name mangling.
It is a technique used in programming to avoid naming conflicts between different classes.
Python performs name mangling by attaching underscore-prefixed class name (_MyClass
) to all members with two leading underscores.
So, while the private member is not directly accessible using its original name, it can still be accessed with the modified name obtained from name mangling.
This is demonstrated below:
As demonstrated in all the examples above, protected members and private members (with name mangling) can be accessed like public members.
Thus, the point that every Python programmer using OOP must remember here is that Python never enforces encapsulation.
Instead, leveraging encapsulation procedures in Python mainly relies on conventions.
They are used to communicate the accessibility protocols of class members to other programmers.
Thus, it is the programmer’s responsibility to obey these conventions.
Here’s a full deep dive into Python OOP if you want to learn more about advanced OOP in Python: Object-Oriented Programming with Python for Data Scientists.
👉 Over to you: What are some other things to take care of in Python OOP?
👉 If you liked this post, don’t forget to leave a like ❤️. It helps more people discover this newsletter on Substack and tells me that you appreciate reading these daily insights.
The button is located towards the bottom of this email.
Thanks for reading!
Latest full articles
If you’re not a full subscriber, here’s what you missed last month:
Don’t Stop at Pandas and Sklearn! Get Started with Spark DataFrames and Big Data ML using PySpark.
DBSCAN++: The Faster and Scalable Alternative to DBSCAN Clustering
Federated Learning: A Critical Step Towards Privacy-Preserving Machine Learning
You Cannot Build Large Data Projects Until You Learn Data Version Control!
Deploy, Version Control, and Manage ML Models Right From Your Jupyter Notebook with Modelbit
To receive all full articles and support the Daily Dose of Data Science, consider subscribing:
👉 Tell the world what makes this newsletter special for you by leaving a review here :)
👉 If you love reading this newsletter, feel free to share it with friends!
Great explanation Avi.. Simple and crisp. Thanks
Great work buddy!
It's wonderful read.