If you are working with a large team, you need a statically typed language. Access modifiers are the least of your problems, the lack of refactoring support is a much bigger problem.

I agree, but I was focusing on a single aspect and explaining why its value might not be apparent to the parent commenter. Really, the same argument can be adapted to other contentious features of popular static languages.

> If you expose everything, someone will write code that depends against it and make it harder for you to improve or change it in the future. Tossing in roadblocks helps guide users to the better long-term path.

> It doesn't really matter for small teams

Doesn't even have to be your team. We encountered this by way of a major library, celery.

I forget all the details, but celery was importing something else (name started with a "k", I think), and that was importing an underscore-prefixed function from uuid. Somewhere between python versions 2.7.8 and 2.7.13, the implementation of uuid changed and that import failed.

`foo._a` accessible outside `Foo` but it makes code look gross and means you're doing something wrong.

`foo.__a` accessible only inside `Foo`

I think it works.

> `foo.__a` accessible only inside `Foo`

It's not all that inaccessible. Try:

    class C:
      def __init__(self):
        self.__private = 'Is it private?'
    
    c = C()
    c._C__private

Double underscore names aren't so much about access control (because access control isn't strongly enforced) as about limiting name collisions (by including the class name in the underlying field name).

Specifically, it's about avoiding collision of "private" names via inheritance.