One of the things I loved about Python when I learnt it was how it dealt with `public`\`private`\protected``. It was "we're all responsible adults. No need to hide anything. We'll just use a naming convention for members that we don't expect people to directly use."

"Enforce encapsulation" suddenly became. "Respect encapsulation" in my head and a bunch of Java/C++ problems evaporated.

▲

kstrauser 7 months ago | parent [-]

I do love that about Python. The encapsulation is there but you can work around it if you’re willing to take responsibility for breaking the gentlemen’s agreement. That’s a lovely pattern.

▲

karmakurtisaani 7 months ago | parent [-]

This gets more and more horrible the larger the code base grows and the more developers get involved.

My current preference is to have everything public, but immutable.

Edit: except for functions. Private functions are a great way of keeping downstream users from touching them. Only expose what you are willing to support.

	▲	kstrauser 7 months ago \| parent [-]
		My experience has been otherwise. There’s almost never a reason to be playing with something like db_connection._socket, but in that one place in your codebase you really really need to, it’s a lifesaver to have access to it. Linters should be shouting about it and in the PR you’d need to explain why you turned off the warnings to do it anyway, with comments explaining why there was no other feasible option and this was the least bad choice. BTW, I rarely write _methods and almost never __protected attributes. _something just means “it’s here but you really shouldn’t be playing with it.” I don’t see an advantage to using __anything.