Will python never intend to support private, protected and public?

Paul Rubin http
Fri Sep 30 09:10:09 CEST 2005


Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:
> 	They did? Fine... Add another that Python names beginning with _ or
> __ are not to be accessed from outside the module/class that defined
> them. And if one is not the "owner" of that module/class, they should
> contact the responsible person and justify the need to have it made
> public, or to have access methods added.

People are much likelier than the compiler is, to make errors with
such policies.  For example: someplace in the application it says

  setattr(x, propname, 23)

where x is an ABC instance.  You didn't expect propname to have the
value "_ABC__private_var" but somehow it got that way, maybe through
malicious input data.  What coding standard is going to catch that?
Are you suggesting a coding standard that bans setattr?

I'm not proposing to change the behavior of a.__xyz even though that
behavior is currently broken.  The question under discussion is about
adding a new feature to Python, e.g. a "private" declaration that's
orthagonal to __xyz name mangling.  Whether such a feature is worth
implementing or not is questionable.  I'm not even saying it's worth
doing.  However, deciding to do it, and then doing it in a broken way,
is insane.

What "coding standards" let you do is review a piece of code and say
"the __xyz attribute didn't get clobbered, unless somebody, somewhere,
made an error with name mangling or the coding standard", which means
you have to consider that possibility anytime you're trying to debug
something related to the __xyz attribute.

OTOH, "private" lets you say 100% for certain that another class
didn't clobber __xyz, and that any bug that clobbered it MUST reside
in the class that declared it.  That makes auditing for __xyz-related
errors a lot simpler since you only have to look in one class for them.

If "private" exists and you don't like it, you can solve that with a
coding standard that says not to use it.  Any violation can be
instantly flagged by the build script.  If "private" doesn't exist,
there is no reasonable coding standard that can substitute for it.



More information about the Python-list mailing list