Ever since I started using Python, in Java I've started just making all my member variables public and forgetting about accessor methods.
It actually works.
Writing tests against implementation details makes the code less maintainable, since it means that you won't be able to change those implementation details without rewriting (or worse yet, just commenting out) unit tests.
It's fine for trivial stuff, but if you work with others, this will cause uber amounts of pain.
If this is true, why is it that there are plenty of large and successful frameworks and libraries written in Python?
> hacks will ensue en masse
Having downstream projects that use it is a sign of health for a library. If they're using the library in ways its creator never envisioned, so much the better for everyone. That's innovation.
More than once, I've had to make a choice between partially re-implementing part of a popular Java library's functionality, or shipping my own fork with all the maintenance burden that entails, because in the official version a field I want to access is private, or a class I want to subclass is final.
1 - They can't do something 'the right way' because the contract won't let them.
2 - They don't know how to do something 'the right way' because the contract is insufficiently documented (or worse, outdated).
3 - They prefer 'the first way' to 'the right way' (in a rush, not give a damn, etc).
To avoid 1) you need to have created an absolutely rock solid design that covers all use cases. To avoid 2), your documentation must be excellent. To avoid 3), there must be 'only one way'.
Unless you comply with all of the above, and can also prevent the ability to copy& paste / duplicate your code, you perfectly hidden internals will not save your project from someone who wants to write dirty code. In fact, hidden internals only really help with 3) there.
But, hey, they may not prevent all of it, but at least they will help reduce it, right?
Maybe not. In practice, hen programmers don't have the mental safety net of hidden internals, my perception is that they tend to produce simpler designs, with lower amount of state and lower amount of dependencies among pieces of that state. Which in turn tend to improve the situation against 1,2 and 3 above.
"Uncle Bob" (Clean Code's author) is the equivalent to those in the Software Engineering field, a snake oil seller that will give you the placebo that promises to fix problems that sometimes don't even exist or are of small relevance.