Does Python really follow its philosophy of "Readability counts"?

[Russ P.]

On Jan 23, 1:54 am, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> Steven D'Aprano a écrit :
>
>
>
> > On Thu, 22 Jan 2009 19:10:05 +0000, Mark Wooding wrote:
>
> >> Steven D'Aprano <st... at REMOVE-THIS-cybersource.com.au> writes:
>
> >>> On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
> >>>> Steven D'Aprano a écrit :
> >>>>> But if you have free access to attributes, then *everything* is
> >>>>> interface.
> >>>> Nope.
> >>> How could anyone fail to be convinced by an argument that detailed and
> >>> carefully reasoned?
> >> Well, your claim /was/ just wrong.  But if you want to play dumb: the
> >> interface is what's documented as being the interface.
>
> > But you miss my point.
>
> > We're told Python doesn't have private attributes.
>
> Yes.
>
> > We're told that we're
> > allowed to "mess with the internals",
>
> Given that we're willing and able to cope with possible consequences.
>
> > we're *encouraged* to do so
>
> Certainly not.
>
> > Python
> > gives you the freedom to do so, and any suggestion that freedom might be
> > reduced even a tiny bit is fought passionately.
>
> Won't comment on this.
>
> > When people ask how to
> > implement private attributes, they're often told not to bother even using
> > single-underscore names.
>
> "often" ? Not as far as I can tell. I think you're confusing this with
> the advice to not use getters/setters for no good reason, given Python's
> support for computed attributes - which is not exactly the same thing.
>
> > When it is suggested that Python should become
> > stricter, with enforced data hiding, the objections come thick and fast:
> > people vehemently say that they like Python just the way it is, that they
> > want the ability to mess with the internals.
>
> Indeed. There's no shortage of B&D languages, and well, Python is OSS,
> so if you want a B&D Python (now that's an oxymoron), please feel free
> to implement it. But by all mean, leave my favorite language alone. Thanks.
>
> > You even argued that you disliked data structures implemented in C and
> > preferred those written in Python because you have more ability to mess
> > with the private attributes.
> > In context, I had just mentioned that lists'
> > internals were inaccessible from Python code. I neglected to give an
> > example at the time, but a good example is the current length of the
> > list. Consider the experience of Microsoft and Apple.
>
> Yes, two great examples of freedom champions.
>
> > No matter how often
> > they tell people not to mess with the internals, people do it anyway, and
> > always believe that their reason is a good reason.
>
> And who are *you* to pronounce any judgement about that ?
>
> > And Python culture encourages that behaviour (albeit the consequences are
> > milder: no buffer overflows or core dumps).
>
> > Add to that the culture of Open Source that encourages reading the source
> > code.
>
> Indeed. A *very* good thing FWIW.
>
> > You don't need to buy a book called "Undocumented Tips and Tricks
> > for Python" to discover the internals. You just need to read the source
> > code.
>
> Exactly.
>
> > And then you have at least two places in the standard library where
> > _attributes are *explicitly* public:
>
> >http://bugs.python.org/issue3152
>
> > Given this permissive culture, any responsible
>
> For your personal definition of "responsible".
>
> > library writer must assume
> > that if he changes his so-called "private" attributes, he will break
> > other people's code.
>
> You still don't get the point. If someone's code breaks because he
> messed with my implementation code, then *he* is responsible. The
> contract is very clear : "warranty void if unsealed".
>
>
>
> > In principle it could break just as much code as if
> > he didn't even bother flagging them with a leading underscore, which is
> > probably why many people don't even bother with _names.
>
> > In other words, if you make it easy for people to mess with your
> > internals, if you have a culture that allows and even encourages them to
> > mess with your internals, then you don't have internals. Everything is de
> > facto public.
>
> Now that you've exposed your opinions, let's face reality (I mean,
> *facts*): Python developpers very rarely mess with implementation,
> usually do so for very good (and documented) reasons, and from what I've
> seen usually tend to get in touch with the library author to explain
> their case and find a better solution.
>
> Funny enough, it looks that the more you treat programmers as
> responsible, normally intelligent adult person, the more they tend to
> behave as such. And the other way around, too.
>
> Now, you comprehensively exposed your personnal distaste for Python's
> and more generally OSS philosophy. So I can only - as I already did way
> before in this thread - wonder *why* are you using Python ?
>
> I mean, is it because your bosses forces you to do so ? If yes, then,
> I'm truly sorry for you - I sometimes have to work with languages I
> really dislike so I can feel your pain (but OTHO, I never complained on
> these languages newsgroups about how wrong they were nor how they should
> IMHO be).
>
> Else, well, I just don't get the point. What you are fussing about are
> fundamental design choices (and philosophic points) that are well known,
> explained, advertized, etc. - and are really not likely to change
> anytime soon.

I am curious about something. Have you ever needed to access a
"private" attribute (i.e., one named with a leading underscore) in
Python code that you did not have the source code for? For that
matter, have you ever even used a library written in Python without
having access to the source code?

As I said before, if you have the source code you can always change
private attributes to public in a pinch if the language enforces
encapsulation. But if you are working on a team project, you can't
change the code that another member of a team checks in. That is how
enforced data hiding helps teams of developers manage interfaces. The
bigger the team and the bigger the project, the more it helps.

Mr. D'Aprano gave an excellent example of a large banking program.
Without enforced encapsulation, anyone on the development team has
access to the entire program and could potentially sneak in fraudulent
code much more easily than if encapsulation were enforced by the
language.

I am certainly not saying that Python is useless without enforced data
hiding. It is obviously very useful for a wide range of applications
and domains already. I am only saying that it's usefulness could be
enhanced if enforced encapsulation can be added without somehow
comromising the language. I don't know enough about the inner workings
of the Python interpreter to know if that is the case or not (I am an
aeronautical engineer), but the objections I've seen so far on this
thread have not impressed me.