Good Pythonic style is much looser than Java's uptight restrictiveness:

In Java, good style means private on methods wherever possible, all fields encapsulated, type declarations, defined interfaces including abstract methods.

All this is now doable in Python, but good style allows and encourages public members, duck-typing, etc.

Yet I find all that to be quite useful. IDE's, for example, can do much more with these declarations in place. SO, I often do these things in Python, much more than examples of good Pythonic code that I find.

Is it actually bad style to do these things?

  • I'm no expert, but readers of Python code expect it to be written a certain way. For example, in Java, if you need to expose the private member of a class, you would use a getter, in Python, while you can write a getter, it's better practice to just expose the variable naturally. Following Java style conventions in Python might not be a good idea.
    – user321545
    Commented Dec 2, 2018 at 16:25
  • 1
    "All this is now doable in Python": What do you mean? As far as I know, everything is public in Python, there are only naming conventions to mark members that are private, but the language does not prevent the programmer from accessing them directly from outside the class in which they are defined.
    – Giorgio
    Commented Dec 2, 2018 at 16:27
  • 1
    I used to code in LISP some 20 years ago, and the main problem with big real-world applications was the lack of strict typing (it was possible with declarations, but not typical LISP style). We got the weirdest runtime errors. I appreciate the strictness of Java, allowing to see and repair many problems already in the IDE, at compile time. Commented Dec 2, 2018 at 17:11
  • 1
    I like a strict type system for two reasons. Code completion and compile time errors. Of the two compile time errors that tell me when I've used a string where an int is expected is my favorite. They're like terse little unit tests. Commented Dec 2, 2018 at 19:03

1 Answer 1


Somewhat surprisingly, Python gives you a lot of choice here. Most Python code is fairly informal regarding exact types, and whether some attribute is part of the public interface. This works fine, until it doesn't. In particular, maintaining large projects is more challenging in dynamic languages like Python.

But as the Zen of Python says: Explicit is better than implicit.

Python has been moving towards enabling but not requiring a stricter style. Importantly, recent Python versions add syntax for type annotations. While these annotations are comparatively limited and have no runtime effect (they are usually processed by external type checkers such as mypy) they make it more feasible to use static typing in parts of your code. Whether this is feasible depends on what modules are using, since most modules do not provide any type annotations of their own, and some do not even have interfaces that can be typed.

This is a bit similar to JavaScript vs. TypeScript: type checking (with all its benefits like better semantic autocompletion in editors) is available if you want it, but you're in no way forced to declare your types.

So if you feel like this helps you keep your code maintainable …

  • make use of docstrings
  • use type annotations
  • use external checkers and linters such as mypy and pylint
  • prefer read-only properties over directly assigning public attributes
  • create explicit interfaces (e.g. using the abc.ABC base class)
  • explicitly assert your function preconditions, e.g.:

    assert isinstance(param, SomeInterface), \
        f"param must be SomeInterface, but was {type(param)}"`

The Python code I write tends to do this, in moderation. Especially because the static type checking is a later add-on, it is quite limited and doesn't always work. And it's really not worth meticulously encapsulating every attribute as you'd do in Java. But stronger checks help catching bugs early, so being a bit more explicit than usual can be a good idea.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.