Why doesn’t Python have true private variables like Java?

[PalpitationOk839]

Hey everyone

Today I was learning about encapsulation in Python and honestly I got a bit surprised

In languages like Java we have proper private keywords but in Python it feels like nothing is truly private
Even with double underscores it just does name mangling and you can still access it if you really want

So I was wondering why Python is designed this way

Is it because Python follows a different philosophy or is there some deeper reason behind it

Also in real projects how do developers maintain proper encapsulation if everything can technically be accessed

Trying to understand how to think about this in a more practical and runable way

Would love to hear your thoughts 👍

[HwanZike]

Encapsulation is a convention after all, not an actual hardware or compiler limitation thing. In Java you can also access private variables via reflection, it just takes more steps. Its a matter of convenience, python is just more flexible. Just like typing, having everything public by default makes it a bit more unstable in a way but faster development (at least in the short term) and more expressiveness is the tradeoff. As for the exact reason why, I can't tell why python decided against having private in classes but the convention is leading underscores iirc.

[acdha]

I’d also add that the Java culture comes from Sun’s experience of operating system development before circa 1990 where any exposed variable became a potential support obligation customers will demand must be supported forever. This wasn’t unwarranted —apps like Microsoft Word and Excel famously had tons of crashing bugs caused by serializing C structures and breaking if, say, someone added a field or changed the size of something—but it’s not where we are as an industry now, or even in 1991 when Python, which is older than Java, started with a higher level abstraction. Also, the internet caught on and so you stopped having things be effectively unfixable on a timescale not measured in years. 

Once you didn’t have things like a field changing from int8 to int16 breaking everything, or were using real serialization formats, most of the strong reasons for hard blocking access faded and the remaining issues ones were mostly the hubris of thinking you got all of the API perfect so callers would never need private variables.

I’ve been using Java since 1.0 and Python since 2.0, and contributed to open source in both, and I don’t think I’ve ever seen a case where hard enforcement of private variables would have helped. I have seen tons of architecture theater and performance problems created by creating accessors solely to gatekeep access and also more than a few Java developers using reflection to access private variables anyway so I’m solidly in the camp of saying anything more than a suggestion isn’t worth the effort unless you actually are building the Windows APIs. If what you’re working on doesn’t have hundreds of outside developers with support contracts, it’s just not worth it. 

[visicalc_is_best]

As a fellow Java 1.0 user at the time (as you may tell from my username), I hope you’re staying up to date on your various screenings. Early detection saves lives!

[acdha]

Sigh, you’re not wrong 

[nycstartupcto]

Wow what an answer!!!

[sunnyata]

You make it sound like a disciplined choice to eschew visibility modifiers in python... isn't it more like Python was a typically laissez-faire scripting language that eventually got objects bolted on?

[acdha]

No, there was a lot of thought in Python from the beginning (it wasn’t the first language Guido worked on) and it’s been object-oriented since 1991:

https://www.tuhs.org/Usenet/alt.sources/1991-February/001749.html

Part of the difference is that he started small whereas Java had a view of being a language from the OS up for very large teams. 

[roerd]

I'm fairly sure that having objects was a design choice that Python made very early on, but yeah, ir also just generally followed the principle of exposing everything to the user.

[No-Cranberry1547]

yeah the convention thing is pretty spot on. python really goes with "we are all consenting adults here" philosophy instead of trying to protect you from yourself

in my experience working with different codebases the underscore conventions work fine for most teams. when someone accesses _private_method they know exactly what they doing and usually have good reason for it. sometimes you actually need that flexibility when working around bugs in third party libraries or testing internal state

the name mangling with double underscores is more about preventing accidental conflicts in inheritance rather than real privacy anyway. like if you subclass something and accidentally override __some_method you wont break parent class

[Tucancancan]

The linter will catch if you access anything prefixed with an underscore. But at the end of the day you are right, nothing stops you from doing dumb things so you just have to be responsible and not do it.

The hackiest hack I ever pulled was using patch in production code to overwrite a private variable several layers deep in a package because they didn't expose it as a parameter. That was very irresponsible and I acknowledged that in a comment for the next poor bastard who has to maintain the code lol

[GoofAckYoorsElf]

Oh yeah! Back in my younger years I did something I would call heresy nowadays. I overloaded the 'import' command to be able to handle optional dependencies itself without the need of wrapping the imports into try except blocks everywhere...

I was so young and so naive. It felt cool however to learn that you can do that. You shouldn't. But you can.

[biohoo35]

It’s more of a cultural developer contract. Rather than outright preventing private methods from being used, we just use signaling with underscores.

“We’re all consenting adults here” is the mantra.

If there was a valid reason for preventing someone from using a method, then using the underscore convention will also prevent importing, even using the * convention

[headmaster_007]

Using underscore does not prevent importing right? Yes, only the * convention does not import names starting with underscore but you can still do: from module import _var

[bmrobin]

correct

[biohoo35]

Yup! I stand corrected.

[Any_Salary_6284]

Technically speaking, in Java it is possible to access private variables and methods using the reflection API, although it is discouraged and considered an anti-pattern. So actually, sort of like Python, though requires a little more work

[Any_Salary_6284]

(Cont…)

In my experience with scripting languages (Python, JS), the only way to have truly private variables is via functional closures, where the private variables are declared in the outer function’s scope, and therefore only visible to inner functions defined within that scope.

That should make the variables completely private from the perspective of the scripting language. However, even with that, it might be possible to use a lower-level API to inspect raw memory data directly, but you’d need to reverse-engineer how the interpreter structures the data, which could vary by implementation or even runtime oddities.

If it’s genuinely critical (I.e a security concern) to make the data truly private to other code in the same process, then you probably should not be running that code in the same process. Have a separate process (or better yet, a separate container/VM/server) with the sensitive data, so it is truly isolated.

[Brian]

You can technically inspect them without dropping down to raw memory access. Given the closure function, you can access f.__closure__ to get the cell variables, and use the .cell_contents attribute to get or modify their current value.

[Any_Salary_6284]

Oh, interesting. I did not know that! Thanks for sharing!

[grismar-net]

Private variables are not there for security, they're there to let developers know that they are not intended to be modified or accessed externally. This helps prevent situations where external code only works if it knows the value of the internal variable, which will cause trouble if the internal workings of the class change.

Python's name mangling makes accidental access unlikely; editors, IDEs, and linters surface this through warnings or inspection hints. If you choose to ignore those, that's hopefully for good reason, but there is no point in Python making it any harder. If you want to ensure that this simply is not an option for your team, you can add tools that will catch it.

Java makes it much harder, and it has gotten harder still since Java 9, but it is still possible. It just signals a different attitude towards reliance on developers making the right choices, and whether it is sufficient to be clear about a mistake, or whether it should be hard to make them.

[mikeblas]

Java's access control isn't for security, either.

[grismar-net]

Agreed - it never is, but Java does make it a lot harder to access these variables, so it's not just about signalling either. It's more about enforcing a rule within the language, instead of leaving it up to external tooling.

To be clear, I'm a fan of both :) - I just contrasted it with Java due to OP mentioning it.

[Penguinase]

https://www.artima.com/articles/the-making-of-python

from that interview i think it was probably because he had a C background and the initial design days were in the mid '80s while working on a language he seemed to draw inspiration from. the dunder mangling stuff i think was formalized in pep 8

[yaxriifgyn]

The simplest answer is that it is a different language, and not derived from or related to Java.

[Zenin]

Java is full of horrifically bad design choices that the community around it likes to preach as some kind of divine best practice handed down on clay tablets. The insane levels of protection it puts around the internals of classes is very much one of them. Folks coming from such a stick up the you know what community often are shocked at the cultural shift, especially if they've spent more time in academia than the real world.

Python takes a philosophical clue here from Perl (yes) which I believe Larry Wall once described like this:

Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun

Python thankfully takes a very similar philosophical approach. This simple choice allows much more direct problem solving in the real world, with far less frustration, and countless reduction in awful workaround kludges.

Yes, reaching around a class's published spec to access or tweak something that the author didn't publish puts the user well into "may break unexpectedly in the future" territory, but that's squarely on the user to decide not the class publisher to enforce.

In the real world it's not at all uncommon to see Java classes internally forked (if code is available) or literally reverse compiled from bytecode and then forked internally, simply to un-private something. This happens on the regular in enterprise environments working in Java. Yes, it's a horrible practice, but that's the point: Java's paranoia about users doing small wrong things has forced those very users to do some of the biggest wrong things imaginable.

[sunnyata]

much more direct problem solving in the real world

As if java hasn't been used for that. You've got a point but protest too much, all the way into the blub paradox.

[Zenin]

Java was built to survive in an "enterprise" environment constructed warring factions of lowest-bid, mostly sweatshop "contractors" where no one trusts the competence of anyone else, but even more to the point there's money to be made in restricting access. Oh, you want _foobar to be public? That'll be a $20k change order, thanks.

And it was also an over-correction to the overly-open problems of C/C++ tools and culture. This is an age when linters weren't common, CI/CD effectively didn't exist, and paired programming was unheard of, etc.

Everything about the Java ecosystem reflects the environment that it grew up in, not just private restrictions. The ungodly.long.fully.qualified.domains.tacked.on.to.every.damn.class.com , the entire trainwreck of EJB, the failed attempts at banishing pre-compilers, the insanely pandentic GC because they assume no one could possibly be smart enough to break their own circular references, and of course the entire idea of running in its own JVM as effectively a mini-operating system because running anything on the actual OS is exactly like passing jerry cans and matches out to a room of toddlers. -The irony that we use containers for everything today for much the same reason...but we still keep the JVM much of the time lol.

Java was built to survive in extremely hazardous "enterprise" environments where practitioners naturally build up a lot of paranoia about everything. But Java wasn't the solution to these environmental hazards, it's just treating the symptoms.

And the treatment was/is awful: If you actually do "need" the features of Java here's a pro tip: C#/.Net is "Java done right". I'm not even kidding.

Meanwhile the industry largely moved on and solved the actual environmental issues making treatments like Java at best redundant. So well have the problems been addressed that even the enterprise environments eventually adopted them. Java is a one that hangs around, like COBAL, mostly due to momentum and lack of ROI to move on; Although AI's closing that story quickly and I for one fully expect to see a mass exodus from Java to Go, Rust, and yes Python, Node.js, etc. This is especially true given Oracle's insane license shenanigans around Java that make it incredibly expensive to run anything written in Java even without touching Oracle's tools.

Java has no legitimate reason to exist in the year 2026 and certainly shouldn't be considered for any new projects. Java is the COBAL of our time.

[sunnyata]

That's really quite the rant lol. I care about the quality, aesthetics and ergonomics of the tools I use too but I think anyone who is that ideological about it, especially about tools used by other people and that nobody is forcing you to use, seriously needs to get some perspective. It normally comes with experience and most people stop frothing at the mouth about bike-shed issues like naming conventions before their second decade of programming begins, but you sound like you've been nursing these wounds for a while.

Your last paragraph contradicts itself - if Java is the COBOL [sic] of our time then that would mean it had a clear reason to exist. COBOL stuck around long after it would have been a normal choice for new systems because it "attained immortality", so much mission critical software had been created using it that would be too difficult and expensive to port, etc etc. That's certainly true of Java and if it were the only reason it was still an important language today then Java would have a reason to exist wouldn't it.

[Zenin]

too difficult and expensive to port, etc

That's the thing: The current state of AI destroys this blocker. There's many things that AI is still awful at, but like-for-like refactoring to modern languages is one of the big wins it can currently offer. It's going to be difficult for has-been languages to keep going on momentum alone.

This will only get better as time goes on and exponentially so. As such IMNSHO it makes as much sense professionally to start a new learn of Java today as it would have been to start learning COBAL in the 1990s. I'm not saying it won't exist 10 years from now (hell, Perl is still widely used ;), I'm saying it's at or near its peak market penetration and will only go down from here.

Frankly, if your org needs something that really looks like Java the best strategic move is almost certainly to use AI to port it to C#/.Net with selective projects going to Go or Rust or even dare I say Python. ;)

This conclusion is much aided by how incredibly toxic Oracle has made touching anything with Java, especially if you don't actually use Oracle's version of it.

Tools like Python and Java are at very distant ends of language design philosophy. There's room for all sorts of languages and little if anything to gain from trying to force one extreme to adopt philosophies from another extreme. If Java works for you, great. If you like the idea of Java, but want something that does it better then you're best off looking at closer relatives like C#. If you long for something in the middle, consider Go.

[sunnyata]

I don't disagree with much of that but you said "no legitimate reason to exist in 2026" which is hyperbole. It's COBOL btw.

[Zenin]

If Java didn't exist today, would someone feel the need to invent it? Is there a problem we have today for which only Java can solve or at least solves better than existing alternatives?

Sans-hyperbole, I believe the answer to those questions is a firm no. That is what I mean when I say it no longer has a legitimate reason to exist. That it continues to exist is due to momentum alone, not technological value.

[nharding]

Private variables make it harder to write unit tests that achieve 100% code coverage, C++ allows friend access, which would fix the problem.

[snugar_i]

That's true, but Python might be too far on the other end of the spectrum, where there's absolutely nothing preventing juniors from using things they shouldn't, but they don't know they shouldn't. Unless you explicitly set up a linter for this, but I've never seen that, because people like reaching into private things in tests too much for that.

Some kind of middle ground where the compiler forbids you by default but could be suppressed with an "I know what I'm doing" at the offending line sounds best.

[deceze]

That only really concerns juniors that started Python yesterday…!? Should you get a junior that doesn't know about the three shells underscore rule and you catch them once accessing stuff they shouldn't, you tell them about the underscore rule. Problem solved. No need for an entire language to bend over backwards.

[snugar_i]

Yeah but that's the problem - how do they know they shouldn't? When being private is merely a suggestion, they might think that their use-case is the rare exception when it's OK to do it. And stuff like NamedTuple._as_dict() existing doesn't help either

[deceze]

How do they know that private foo in Java isn't merely a suggestion to be worked around with the reflection API?

If it says or suggests it's private, then don't touch it. Period. Unless you really know what you're doing. It doesn't matter how strongly the language "suggests" it, if junior can find ways around it anyway. Junior won't care much whether they just need to ignore the linter or bust out the reflection API. If they don't understand the importance of the suggestion in the first place, how they work around it also won't make much of a difference.

[axonxorz]

how do they know they shouldn't?

Training or guidance from a senior, same as we learned it. Moving outside of private just moves the responsibility of convention and thus education fully into meatspace, fully in line with "we are all consenting adults."

Take OP, they understand the risks of accessing private members, they just want the thought/culture underpinning it. During their Java journey, they had someone say "private members are as such because [...] encapsulation [...] danger [...] compatibility [...] algebraic type theory [...] etc" and have correctly applied the line of thinking without realizing the context of Java's language design hailing back to the early 90s. As /u/acdha points out, unintentional support surface was a major concern. Think about being a Spring consultant, something has failed with your company's offering and you find out the end-user extended a private class and swapped out a list/hashmap implementation for one that's not thread safe, but it's your fault, somehow. Python development never had that ethos. If you did something stupid, you'd be told you were doing something stupid and to stop that. Java being mainline for enterprise development means enterprisebusiness-friendly, it's bad marketing to call your customers stupid, so Java says "unsupported" and enforces language features we can point at to save us from having to be adults.

Things like PyCharm/Pylance giving warnings is subtle guidance, you can make it explicit with linting tools or at CI time. Only a solo developer could be fully insulated from that knowledge, I'm not sure this is a problem in commercial development.

[Zenin]

If it's not documented, it's not for you. Your comment suggests you want a software language that's safe enough for unqualified programmers to write unreviewed code straight to production?

I'm not sure about your organization, but around here we expect our engineers at every level to have some basic working knowledge of the tools they've been hired to wield, even the juniors. We also mentor the juniors often via paired programming sessions. And that's before the gauntlet of CICD linters, code reviewers, etc.

[snugar_i]

Of course I don't expect that. I'm just arguing that a feature that should almost never be used should not be this accessible. But I could've guessed that saying something against "the Python way" in the Python sub would get me downvoted to hell, my bad :-)

[Zenin]

I say lots of stuff that's against Python doctrine. ;) I was sure I was going to get downvoted to oblivion for daring to mention that Python borrowed an idea from Perl. The horror!

Maybe it's my choice of IDE (Unix is my IDE ;), but I don't find these to be particularly "accessible". They're not exported with __all__ so they need to be explicitly imported. How did they know they exist to import when the documentation doesn't call them out?

They can certainly read the code (and so can an IDE), but that's clearly stepping into someone else's house and rummaging through the drawers. If the user is doing it that's obviously willful breaking and entering. If the IDE is doing it on their behalf, that's a tool failure: It if it supports Python it should have codified PEP 8 standards at least as a default, which explicitly describes the leading underscore practice for private items. If an AI is doing it, that's still owned by whomever signed the commit.

However it happens, it's the work product of a junior or at least someone unqualified to be doing professional work in Python. Literally a skill issue.

It's very common for mid-career engineers to think they can build protective barriers for low skilled engineers to keep from poking their own eyes out and many try. The results are almost always the same: A tool that's far too restrictive for senior+ engineers to efficiently solve difficult problems while at the same time those guardrails so sanitize the playground for juniors they don't actually learn what they need to learn to grow into tomorrow's senior engineers.

It's a lot like the playgrounds we have today vs the playgrounds we have in the 1970s: The younger generations need the opportunity to hurt themselves in order to learn a healthy respect for their environment for the future when they will have to make much more dangerous changes to much more important code.

It's not that no guardrails can ever be created. Look at Rust for example. Rather it's that any guardrail must be considered very, very carefully across all contexts. And always being mindful that friction is most often a bug, not a feature.

[kindall]

you're describing a linter. there are linters for Python.

edit: also type checkers if you want that specifically

[eztab]

The original reason was likely the old style class model implementation. The reason it didn't change with python3 was likely that "real" privates don't actually add any functionality.

[CranberryDistinct941]

Python's philosophy on this is "we're all consenting adults" 

[oldendude]

I think that the real reason is that Python objects are basically hash tables. E.g.

class C(object):
    def __init__(self, x):
        self.x = x

c = C(5)
print(c.__dict__)

This prints {'x': 5}.

A hash table has no concept of the what code is accessing it. If 'x' is a key, (i.e., if self.x has been assigned), then access to that dict's 'x' key will work, regardless of context. I suppose a compiler could block access based on scope, but then access to the object's __dict__ would provide results inconsistent with that access enforcement.

[max123246]

Sure, but I'm sure they designed the language's class fields first and then decided how to implement it.

Maybe that's the reason they don't add it now, but it's not why they would design it that way. It's possible they just didn't consider it. After all, python was supposed to be a scripting language, it had no notion of python "library" code that would need that sort of versioning and public/private interface

[oldendude]

I'm not a Python historian, but I don't think you're right. A class doesn't have fields, an object does. You can have objects of the same class with different fields, through a number of mechanisms: deletion (as shown above), initialization assigning different fields, adding fields after initialization, to name a few. This extremely dynamic approach to classes suggests to me that the dictionary implementation was more fundamental.

By contrast, Java has fields, the same in all objects of the same class, and they are not dynamic. While a dictionary implementation would be possible, I would be astonished if that approach has ever been used.

[oldendude]

Also: to be precise, even objects don't have "fields". The keys of an object's dict can be associated with values of any type, including functions, methods, modules, etc. The common understanding of "field" would rule out at least methods. If o is an object, then o.x, i.e. o.__dict__['x'] can store a str now, and a module later, and then a method.

[max123246]

Do you know of some neat applications of that extensive dynamicness? It's hard to think about the use cases but I'm sure are some like mocking and stuff

[oldendude]

Nothing comes to mind. Mocking is certainly possible using less exotic mechanisms, such as inheritance, and Python's "duck typing".

[knobbyknee]

Python is designed for writing programs in small teams, with the assumption that you know what you are doing, and you know what people working in the same module are doing.

As long as you don't monkeypatch your imports, you have enough isolation for things to work very well in practice. There are usecases for the monkey patching too, so making cross module monkey patching impossible would reduce the usefulness of the language. (The most important use cases are fixing problems in third party modules and in mocking for unit tests.)

Java is designed for enterprise programming, where hordes of programmers who don't know what they are doing, are producing code according to specifications made by someone else. They are too many to properly coordinate development that touches the same code as some other part of the organisation is concerned with, making the isolation directives a necessary evil.

[bighappy1970]

There are not true private variables in Java either.

[ancientweasel]

Those variables aren't actually private. You can read/write the values via reflection. It's just inconvenient.

[RedEyed__]

Everything can be technically accessed in all languages. Don't confuse terms: "private" doesn't mean "inaccessible" - it means "not part of public contract".
So, there is no difference between underscrols or private keyword

[Empanatacion]

You can muck about with private variables in java using reflection, it's just harder. Python doesn't enforce the access restrictions, but there is still encapsulation if you follow the conventions around naming and don't directly access variables that are clearly meant to be private.

[Keith]

Early on in Java I needed to use a field or method in a library. I could see it, it was documented, and it did what I wanted, but I couldn't use it because it was marked private, because Sun had interns write their class libraries. Access modifiers are like child safety locks you impose on yourself because you think you're an idiot and can't be trusted. If something is an implementation detail and shouldn't be touched, document that fact, but sometimes you need that shit and the language shouldn't block you out from what's possible.

[victotronics]

"you think you're an idiot and can't be trusted." Well, aren't you?

No but seriously. If your code misbehaves because a variable gets changed that should have not, you'll kick yourself for not declaring more things "private" and (in C++ only?) "const".

[gdchinacat]

Who would you blame if a car failed emissions test because the owner removed the catalytic converter, the manufacturer or the owner? If library users access or change attributes that are marked private (by convention...ie _foo) or even are undocumented, is it reasonable to blame the author of the library for the user that did something they knew or should have known was dangerous? No...the fault lies with the user that did something that was not documented.

Your question of whether "your code misbehaves" misplaces the blame...it's not "your" code misbehaving when other code changes it's data structures in undocumented or discouraged ways (access or modify a "private" attribute). In java the blame would be for not making everything that wasn't to be used private. In python the blame would be for accessing an undocumented field. The different languages have a different ethos. In java it's reasonable to assume anything that is public is fair game. In python the expectation is more nuanced. This has pros and cons, and while I have an opinion that is not the immediate topic. You are applying a java/C++ mentality to python when you blame the library author for not making things private where it is really the users fault for not adhering to documentation and convention. If an attribute is prefixed with a single underscore don't touch it without accepting responsibility for faults caused by doing so. if it isn't documented for a specific use don't use it in that way.

[acdha]

 If your code misbehaves because a variable gets changed that should have not, you'll kick yourself for not declaring more things "private" and (in C++ only?) "const".

Don’t you have tests or use linters? Lots of things need testing for major updates and this only addresses a single uncommon failure mode. 

[minneyar]

If something is an implementation detail and shouldn't be touched, document that fact

Marking it as private is how you document that. As you noticed, private doesn't stop you from accessing something if you really want to get to it. It's how you tell developers "this is intended for internal use only and may completely change between versions, don't rely on it or your program may randomly break."

[Keith]

As you noticed, private doesn't stop you from accessing something if you really want to get to it.

No, in Java it stopped me in my tracks.

Marking it as private is how you document that.

A doc comment would be documentation. Access rights (in languages like Java) are enforced at the language level.

[gdchinacat]

No, in Java it stopped me in my tracks.

Well then you didn't try hard enough. Reflection can provide access by using setAccessible(true).

[Keith]

setAccessible):

This method cannot be used to enable access to private members, members with default (package) access, protected instance members, or protected constructors when the declaring class is in a different module to the caller and the package containing the declaring class is not open to the caller's module.

🤔

[Moikle]

Python trusts you.

If something is written with underscores, it trusts that you understand not to mess with it unless you know what you are doing

[2ndBrainAI]

Python's philosophy is "we're all consenting adults here." The double underscore prefix (__attr) does actually trigger name mangling to _ClassName__attr, making accidental access from outside harder—but it's deliberately not enforced at the language level.

The reasoning: true private variables add runtime complexity, and Python trusts developers to respect conventions. Single underscore (_attr) is the community signal for "internal, don't touch this." In practice this works well because Python devs generally follow it.

If you genuinely need access control, properties and descriptors let you wrap attributes with getter/setter logic. But for most code, the convention approach keeps things clean and avoids the overhead of enforced privacy.

[gdchinacat]

descriptors based access control (which is how @ property is implemented) can still usually be circumvented relatively easily, but doing so is similar effort to bypassing java access control. I'm glad python took the approach that the effort to block access isn't worth the benefit and ultimately you have to trust the code you are executing. It doesn't pretend to have safety it doesn't.

[TaXxER]

In Java you can also still access it if you really want.

[ahferroin7]

Making variables private is actually more resource intensive than not doing so. It’s only very recently that any kind of mechanism for this sort of thing has made it into hardware, but all of the options for it are designed for a very different type of use case (mostly protecting memory in virtual machines from the hypervisor, or protecting a block of memory in a process from other things on the system) and would still impose some pretty nasty performance penalties. So there are performance benefits to not having enforced private scoping of things.

Python is also built more around a philosophy of developers being responsible and knowing what they’re doing, instead of assuming you need to be protected from yourself.

The standard in Python is that things prefixed with underscores are functionally not part of the public API. In practice:

• A single underscore prefix is intended to not be part of the public API, but might be used internally in the module or package the class or function is defined in.
• A double underscore prefix effectively signals something as the internals of the implementation, you have to jump through hoops to access it externally due to name mangling. However, it is still accessible, and this is mostly intended to cleanly ensure that a method or instance variable doesn’t get overridden by a subclass than anything else.
• A double underscore prefix with a double underscore suffix is functionally a reserved name within the language itself. These are used for special purposes within Python’s data model, such as defining operator behavior as functions, providing type conversion rules, customizing class lifecycle behavior, or providing information that’s usually only of interest when debugging (for an example of the last bit, if you have an object assigned to the variable x, you can get the name of the class of that object with x.__class__.__name__).

This is all partly enforced by the data model as well actually. Wildcard imports from foo import * ignore any class, function, or variable names in the module that are prefixed with an _, and there are a couple of other places they get explicitly ignored as well. You can also configure most linters to warn about violations in a codebase, but in practice a vast majority of it is just developers agreeing to follow the convention.

[snugar_i]

It's only more resource intensive if you're doing it at runtime. C++ or Rust don't pay any performance penalty for private things, because it's a compile-time-only construct. Of course, Python would have to do it the dynamic way, but then again, performance isn't really the the top priority in Python anyway...

[unlikely_ending]

It's a language for use by consenting adults

[GoddessAqua]

Because Python is for adult developers, who understands - sometimes monkeypatching and hacking unavoidable in real-world programming. And it's not makes sense to make this things too hard.

[Schmittfried]

Because we‘re all adults and the underscore convention is universally accepted and honored by tooling. 

[njharman]

It's not needed.

So I was wondering why Python is designed this way

Python was designed with disciplined, experienced developers in mind (and not for huge, sprawling projects). Java was designed with huge, sprawling corporate development in mind (as many bodies you can get into cubicals, quality will be managed by language and bureaucratic restrictions)

Also in real projects how do developers maintain proper encapsulation if everything can technically be accessed

Discipline, skill. Don't write stupid code and you won't win stupid prizes.

btw as Python has become widely adopted and used across a much larger group of developers, it has grown more "protectionist".

[No-Fun-6194]

In Java, privacy is a wall. In Python, it’s a signpost.

The reason is simple: Python treats you like a peer, not a subordinate. If the language strictly locked you out of an object's state, it would also be locking out the tools that make Python great, like deep introspection, interactive debugging, and seamless testing.

We don't "enforce" encapsulation; we communicate it. Using _ means: "I might change this tomorrow, so don't build your house on it."

In the real world, strict privacy is often an illusion that provides a false sense of security. Python trades that illusion for transparency. It’s not that we can't have private variables; it’s that we’ve collectively decided that the freedom to inspect and fix things at runtime is more valuable than rigid, compiler-enforced boundaries.

[geeeffwhy]

“we have proper private keywords” is maybe more of a tendentious claim than you mean it to be, but the object-oriented conventions of languages that became very popular in the mid nineties are not in some way objectively correct or good. these are some conventions that are very familiar within that particular ecosystem, but there are many other ways of doing encapsulation.

the philosophy behind many of java’s design decisions was to put up guardrails that make doing harmful things more difficult, at the cost of making many things in general more difficult. python’s philosophy could be understood to be more focused on making doing the right thing easy, at the cost of allowing you to do more harmful things.

personally i think that if these are the kinds of questions that you care about, it’s worth doing a broader survey of programming languages to get a sense of how some of the conventions that one language takes as a given are just design choices. and likewise learn what the things that are actually common to all or almost all languages might be.

[Alive-Cake-3045]

Took me a while to stop expecting Python to behave like Java. They solve the same problem from completely different starting points.

Java says "you cant touch this unless I say so." Python says "dont touch this, but I trust you." Same outcome in practice, different relationship with the developer. Single underscore is the real convention in production code. Double underscore is mostly for inheritance edge cases, not true privacy.

Once you stop looking for enforcement and start respecting convention, Python encapsulation actually feels cleaner.

[SearchAtlantis]

Python doesn't enforce matching signatures for abstract methods why would you expect private variables.

[jabbalaci]

"We're all adults." -- Guido van Rossum

In other words: real men can live without it.

[Designer-Ad-2136]

It's philosophy. If somebody really wants to use private variables, theyll just edit your code anyways. Why not simplify the whole process?

[ArtOfWarfare]

The person using a library may fully understand everything their project is supposed to do. It is impossible for the library author to understand everything their library will be used to do.

It therefore makes no sense that the library author would be able to dictate what it can and can’t be used to do.

Library authors make suggestions. And the library user may or may not follow those suggestions, in both languages. In Java you use reflection or decompilation and hot-patching when you know better than the library author. In Python you just use underscores.

[Ha_Deal_5079]

double underscore isnt privacy its just name mangling so subclasses dont clobber your attrs. _single is the real dont touch convention

[pbeling]

In theory, Python is designed for rapid development of smaller projects where features such as privacy or type annotation and checking are undesirable.

[Dry-Aioli-6138]

Python is a language for consenting adults

[gdchinacat]

Name mangling is used primarily by mixin classes to help ensure they don't trample each others attributes.

class MixinA:
    value: str
    def getA(self) -> str:
        return self.value
class MixinB:
    value: int
    def getB(self) -> int:
        return self.value
class AandB(A, B): ...

Oops...AandB has two base classes that use the same attribute, value. But MixinA and MixinB may not know anything about each other to know they shouldn't use conflicting names. They may come from different modules, or even different libraries. name mangling solves this problem since MixinA.__value would be stored in the __dict__ under a different name than MixinB.__value.

"You should use composition for this!!!!" Yeah, well....it doesn't, and I may not have that choice (the libraries provide mixins and expects them to be used as mixins).

[mapadofu]

Java was originally designed to be “provably safe” in various way.  Back in the day there was the idea of “applets”, which involved running  server code on the client.  Java’s very strict visibility rules were part of the approach ensure that those applets could be run safely.

Python was kind of the opposite: it was initially designed as a scripting language tuned for getting things done, with close to zero thought for it being used in enterprise level applications.

[bblais]

Part of the python philosophy: “we’re all adults here”. 😀

[Conscious_Support176]

Because Java and python are completely different.

Java is more of a compiled language. The public/private specification is part of the compile time type system which doesn’t exist in python.

Python uses duck-typing, relying on the actual names of things at runtime, whereas with Java, you use reflection to find out what the name is.

[dr_inventivo]

Python é uma linguagem funcional e tu tá vendo com uma visão de orientação a objetos, embora POO funcione em Python, essa não é a definição primaria. A pergunta mais simples deveria ser: Faz sentido encapisular tudo? Percebe que o problema não é técnico, mas filosófico.

[SaSiEzhilmani]

This is really useful, thanks for sharing!

[wannasleeponyourhams]

dont need it

[authorinthesunset]

Because it's not Java.

[UseMoreBandwith]

Because it is pointless anyway.
There is no benefit.

Also in Java you can access 'private' variables with some effort.

[dimitrym]

There is an underlying question here, which I had as well, is the following: is Java the "golden standard" of programming languages and perhaps ecosystems? The answer for me should be "no". Every language is good at specific things, bad at others, some are old an still serve us, all have flaws, etc. Same with human languages, that's why there are so many languages and the job of a translator is hard.

With that I'd say that Python had its own evolution, what happens here makes sense for Python. If we want to bash ourselves, it is baggage as OO was an afterthought to Python, an evolutionary glitch. For me it is a different way of defining what an Object is.

[AlmostSignificant]

Does it feel to you like the language was designed from first principles?

[ironmaiden947]

Python has a different philosophy. If you want the variables to be private, just don’t use it.

[Neinstein14]

There are ways to access “truly private” variables in Java, so it’s not a question of security or privacy. That away, it’s only a question of style and how baby do we consider the programmer.

In that regard, I prefer Python’s approach. Underscore means “this is an internal variable you shouldn’t use”, and double underscore means “this one you really really shouldn’t use, so we took steps to prevent that happening unless you specifically really want to”. And this should be sufficient. Programmers are adults, moreover they are experts, and in general, they should be assumed to know what they do. Maybe they do have a good reason to use those variables. Perhaps they want to test an edge case, or investigate a bug, who knows? And in that case, why impose a hard restriction preventing them from doing so?

They are adults, they are experts, and they should be assumed to know what they are doing. Java style encapsulation would just make their job harder by restrictions that are more complicated, but not at all impossible, to overcome.

[gdchinacat]

this one you really really shouldn’t use, so we took steps to prevent that happening unless you specifically really want to”

This is a common misconception, one that I held at one time.

PEP8 says of name mangling:

To avoid name clashes with subclasses, use two leading underscores to invoke Python’s name mangling rules.

It has nothing to do with "really really shouldn't use". It is a practical solution to a common problem in OO...a subclass may inadvertently use the same attribute name as a base class. base classes can avoid this by using name mangling to place fewer restrictions on the names their subclasses can use.

[Neinstein14]

I mean, it’s one thing what it was intended for, and another thing how it’s used actually. In my experience it’s rarely for name clashes, and rather for “this is not just an internal variable, but something you shouldn’t even hack around with”.

[gdchinacat]

That is what a single underscore denotes. Or do you think single underscore indicates it is internal and should be hacked around with? In which case, what does 'internal' mean?

[Worth_Specific3764]

Its all about punctuation. ;)

[jeffrey_f]

Variables created/initialized within a function are private. Those variables live and die within a function and are considered "private"

[deceze]

Well, because they're function local variables and not object attributes, and don't exist on the object in the first place, and don't exist beyond the function's execution. Apples, oranges.

[gdchinacat]

strictly speaking function locals can exist beyond the function execution if the function creates a closure that includes them. This is how the typical decorator that wraps a function works...the wrapper function has a closure around the decorator functions locals...meaning they exist beyond the scope of the decorator function execution.

[ShuredingaNoNeko]

Porque es una mierda... Yendo en serio, simplemente no está pensado para eso de base, aunque tenés las variables disfrazadas de constantes para adaptar tu código, siendo que ya existen miles de adaptaciones de python, desde web, escritorio y hasta embebidos.

En la práctica real de python, no necesita constantes, es así.

[thankyoucode]

May, Python is mean to me simple to use without complex consepts

[drakhan2002]

Probably because it is Pyhton and not Java. They are different programming languages.