If 'explicit is better than implicit', why aren't there explicit access modifiers in Python: Public, Protected, Private, etc.? I know that the idea is that the programmer should know what to do through a hint - no need to use 'brute force'. But IMO 'Encapsulation' or 'information hiding' isn't just to keep people out, it's a question of organization and structure: your development layers should have self-defining, clearly delimited scopes and borders, just like physical systems do. Can someone please help me out here with a solid  explanation as to why access restrictions are implied rather than explicit in Python, a language that otherwise seems close to perfect?Edit: So far I have seen 3 proposed answers, and I realized that there are 2 parts to my question:Why aren't there key words, for example private def myFunc():     dostuff....instead of IMO the ugly and hard to type underscores. But that's not the important point.More importantly: Why are these access modifiers only 'recommendations' or hints and not enforced. It will be hard to change later? It's very simple to change 'protected' to 'public' - and if you have a convoluted inheritance chain that makes it difficult, you have a poor design - your design should be refined rather than relying on a language feature that makes it easy to write poorly structured code. When access modifiers are enforced, your code is automatically compartmentalized - you KNOW that certain segments are out of scope so you don't have to deal with them except if and when it's necessary. And, if your design is no good and you find yourself constantly moving things into and out of different scopes, the language can help you to clean up your act.As much as I love Python, I'm finding this 2nd point to be a serious deficiency. And I have yet to see a good answer for this.
Why aren't there explicit access modifiers in Python:
python;access modifiers
Explicit is better than implicit is only one of the maxims in Python's design philosophy. Simple is better than complex is there too. And, although it's not in the Zen of Python, We're all consenting adults here is another.That second rule is perhaps the most important here. When I design a class, I have some idea of how it's going to be used. But I can't possibly predict all possible uses. It may be that some future use of my code requires access to the variables I've thought of as private. Why should I make it hard - or even impossible - to access these, if a future programmer (or even a future me) needs them? The best thing to do is to mark them with a warning - as Joonas notes, a single underscore prefix is the standard - that they are internal, and might change; but forbidding access altogether seems unnecessary.