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

Bruno Desthuilliers bruno.42.desthuilliers at websiteburo.invalid
Fri Jan 23 13:57:52 CET 2009

Russ P. a écrit :
> 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?

No to both.

> 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.

And then have to maintain a fork. No, thanks.

> But if you are working on a team project, you can't
> change the code that another member of a team checks in.

Why on earth couldn't I change the code of another member of my team if 
that code needs changes ? The code is the whole team's ownership.

Now and FWIW,  in this case (our own code), I just don't need to "mess 
with internals" - I just just change what needs to be changed.

> That is how
> enforced data hiding helps teams of developers manage interfaces.

I totally fails to find any evidence of this assertion in the above 

> The
> bigger the team and the bigger the project, the more it helps.

Your opinion.

> 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.

My my my. If you don't trust your programmers, then indeed, don't use 
Python. What can I say (and what do I care ?). But once again, relying 
on the language's access restriction to manage *security* is, well, kind 
of funny, you know ?

> 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

You might have a chance to sell this to a clueless pointy haired boss - 
I mean,  that enforced access restriction will make Python more suitable 
for some big enterprizey project. As far as I'm concerned, I'm not 
buying it.

> without somehow
> comromising the language.

Then just forget it.

> 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.

I've not seen much technical objections - but anyway: learn (I mean, 
*really* learn) how Python's object model works, and you'll perhaps find 
out why this would break the whole thing.

More information about the Python-list mailing list