Is Python's understanding of privacy misguided?

Question

Following up on this discussion:

https://www.sololearn.com/discuss/1735413/

David Carroll, swim

Is something objectively bad about the way Python deals with privacy in OOP?

The point of encapsulation, abstraction, data hiding and all that is foremost to ensure that code units can be easily used, maintained or exchanged without effects all over the code, right?

Python has the convention: 'Whatever starts with an underscore, doesn't belong to the interface and shouldn't be accessed.'

I personally find this easy to understand, and from my perspective I can not recognize how that should lead to trouble in real life.

Sure, in theory people might violate it and do damage - but you can do plenty of damage with every language if you want to - think pointers, crement operators or makros in C(++) for example.

To me, a strong dislike against Python's understanding of privacy looks a lot like 'I don't like it because I'm not used to it.'

But I am a beginner after all, so I wonder if I'm missing something ...

Answer 1

I haven't followed all the discussion but to me it seems that Python puts more trust in its programmers to not violate its conventions. Maybe this is similar to C/C++ but then, the latter are more low-level languages.

Answer 2

~ swim ~ about point 8, don't you think Python would allow people to focus on higher order problems than having to spend too much time on details 'under the hood'? While I don't see anyone using Python for mission critical, high performance computing in the near future, in fields like data science and AI (that doesn't need the performance), Python (mainly due to its libraries) would be an absolute dream.

Answer 3

Hey bro,if I declare a method or variable private it can't be accessed from other classes...
Sure I want this .....Without any violation....Python doesn't control access just conventions...😑

Answer 4

~ swim ~, now I'm not sure if I laid out my analogy understandably. 😅

I was equating Python's _ convention with the red traffic light, and the gate with Java's or C's 'private'.

Py just gives a visual cue 'Don't cross', J&C actually put something in front of you which you can't (easily) pass.

Python's idea is that programmers in a team work with each other, not against each other ('consenting adults') and that in such a setting the 'red light' should suffice. (Well, it would suffice for me!)

Depending on nature, some might prefer the more fierce restriction, other's prefer to be just told. That's okay, opinions may differ.

However, from you, David and others it often sounds like you're looking down on Python, looking down on it presumably from a professional standpoint.

So this is not about opinion and if one has to agree with the other - I'd like to hear arguments why _ *objectively* is inferior.

Answer 5

I think the _-convention is fine. It is defacto private.

If you program in python you will be aware of the convention, so if you still end up using a private member it's your own problem if something doesn't work. You can shoot yourself in the foot with reflection in most languages if you choose to.

Access Modifiers are not a security feature anyway. Unless I see some stats I'd say writing "_" instead of "private" does not produce more bugs in production code.

Answer 6

~ swim ~, thank you for your extensive answer, but some of the points don't really deal with the aspect of privacy (my question) but elaborate on a lot of things you generally dislike about Python.

Point 1, 6 and maybe 3 remain.

'... defeats the very purpose of encapsulation.'

I think this goes too far!

Imagine a road crossing a railroad track. We want to prevent accidents.

A railroad gate quite well prevents accidents because you can't pass.

A red traffic light on the other hand is less safe since you could ignore it.

But does it 'defeat the very purpose?' I sincerely doubt that!

Okay, so a less restrictive type system may end up devalidating the state of your object, since wrong data comes in.

But what prevents you from taking care of that from within the getter/property function? There are a lot of ways, aren't there?

You can for example just check for the type with 'if type is xy' , or 'if isinstance(arg, type)'. If it doesn't fit, you either convert or reject it.

Answer 7

7fs5