Python Private Members and Name Mangling
The second half of PCAP objective 4.2. Python has no private keyword and no access control at all. What it has is a convention - one leading underscore means "internal" and is enforced by nothing - and a mechanism: two leading underscores make the compiler rename the attribute. The rename is real and examinable; the privacy is not.
Object-Oriented Python Guide 16 of 25 Intermediate
- OSUbuntu 26.04 LTS
- Python3.14.4
- pip25.1.1
- TimeAbout 15 min
Name mangling has worked this way since Python 1 and is unchanged. There is no private, protected or public keyword in any version, and there is no plan for one.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| RUNNER01 | 192.168.0.27 | Ubuntu 26.04 LTS | Python 3.14.4 - the only machine this path needs | 2 Core | 4 GB | 50 GB |
This guide includes
Use this for the private-members half of the same objective. This matters because a double underscore hides nothing - the attribute is renamed rather than protected, and knowing the new name gets you straight back in.
- comparing one underscore, two underscores and none
- finding what the double underscore actually did, which is renaming
- seeing why the name fails from outside, and reaching it anyway
- learning why the renaming exists, which is not privacy
- finding that the single underscore is only a convention, and that mangling applies to methods too
Before you start
-
One underscore, two underscores, none
-
What the double underscore actually did
-
Why the attribute name fails from outside
-
Why the renaming exists
-
The single underscore is only a convention
-
Mangling applies to methods too
-
What the exam does with this objective