Is it bad practice NOT to use private methods and functions in Python?

user_11197957 0
Viewed 926

Background

A few weeks ago, I completed a technical test in Python. While the overall feedback from the test was very positive, one of the things I was surprised to read in the feedback was:

No encapsulation – plenty of public_functions which should be _private_functions

This surprised me because - according to the vague picture I'd built up in the back of my mind over my two years as a Python developer - we don't really do private methods or functions in Python. All that we do have is a patchwork of conventions, shorthand and gentleman's agreements. But is that picture in the back of my mind correct?

Underscores and Double Underscores

So I've looked into the matter a little more deeply, consulting the standard Python documentation as well as PEP 8, and I've come to the following conclusions:

  1. The use of a double underscore before a class attribute invokes name mangling, i.e. __spam will be interpreted as _classname__spam. This can be used to emulate a crude kind of privacy, such that if one tries to call __spam from outside of its class, an exception will be raised.
  2. The programmer can use a single underscore to indicate that a function (or similar) is private, but this seems to have little syntactic effect. PEP 8 mentions that _single_leading_underscore will not be imported when from M import * is called, but I couldn't find anything else.

However, this only tells me what I could do, not what I should do.

What I Want to Know

Can I write off the above feedback as coming from someone who's probably spent his professional life programming in Java/C#/etc, and therefore doesn't have the correct mindset when it comes to encapsulation in Python? Or should I re-think the way I write Python programs, so that any encapsulation is much more explicit?

private encapsulation oop python
2 Answers

From technical point of view, there is no right or wrong way of writing code. What computer cares about are instructions and data. If you use clases or not, if your code is modular or spaghetti, what are the names of your functions, if they are public or private etc. - it all goes down the drain by the time it reaches the CPU.

Arguments like these are arguments about opinions. Everybody has an opinion. You might also call it taste. People with similar opinions group together and create organizations, political parties, institutions etc. to promote their ideas. They claim that it is somehow possible to generalize and distill how software should be written, into decisions that are either "right" or "wrong".

Yet, for every rule that proves something, you will quickly find another rule that contradicts it. This is just the law of nature - reality knows no boundaries. This is the reason of all confusion.

There is no such thing as universal rule about something, and there never will be. It would contradict the very nature of the universe: time and entropy. Whatever question you ask, the answer is always "it depends".

After 40 years of programming my core values are down to this:

  • Consistency matters more than style.
  • Make it easy for the reader to understand what you are doing, and even more importantly, why.
  • A good comment in the right place can save a week of headaches.
  • The reader might be you.
  • Always try to choose the best tool for the job.
  • Follow conventions where they make sense, but do not hesitate to break the rules when you have a justified reason for it.
  • Nobody knows better what makes sense than the person writing the code. Keep asking yourself: Does the thing that I'm doing make sense, or do I see a better way?
  • Less is more.
user_83381000

The long short of it is yes listen to the feedback. While true that Python does not really do privacy the same as C++ or Java, it still sends signals to developers and users what the intention is. public attributes can be set any which way, and this can lead to an error if you always expect "object.x" to be an integer and they make it a string. when an attribute is made private (while not truly private) means the user cannot access it directly, and must user a provided handler. The handler methods provide the only means of access and require all interaction to use the same channel. The same idea also applies to methods. there are some methods the user/developer should never need to use directly, and these should be private for the sake of simplifying the encapsulation. While not entirely necessary, using Python's privacy features does aid encapsulation and helps prevents unforeseen errors from occurring.

user_152703120
Related