[Tutor] Data hiding in Python.

[Andreas Kostyrka]

* Jonathon Sisson <sisson.j at gmail.com> [061219 21:45]:
> 
> > My vote is, no, not worth the trouble. It's Java / C++ / static-typing / 
> > put-the-client-in-a-straightjacket-so-they-don't-touch-anything thinking.
> > 
> 
> Heh...and don't forget the king-pin of them all, C#.  Between private, 
> public, protected, internal, and protected internal I lose track of what 
> I was originally doing and end up contemplating the meaning of "what if 
> another programmer wants to use this creation of mine" instead of doing 
> what I set out to do...
> 
> I'm with Kent on this one...definitely not worth the trouble to 
> bastardize Python like that...
> 
> As a side note, does anyone have a good argument for access level 
> controls like C#?  I personally think it's a waste of time (much like 
> C#/ASP.NET...my apologies to any .NET fans out there...), and honestly 
> the arguable margin of security that access modifiers provide is 
> outweighed by the cons, in my opinion.  (And usually what programmers 
> end up doing is creating "service methods" that allow access anyways, so 
> the margin of "security" is lost).  Thoughts?

Well, what does make sense at least in a static language situation is
to support an arbitrate number of "interfaces", e.g. like Modula3 is
providing with partial revealing the exact type of an opaque type.

Basically, taking the classical IO stream example, you get the
following roles:

*) simple user
*) advanced user (does it's own thread locking, unsafe)
*) implementer (simple)
*) advanced implementer (does it's own buffer management)

and so on.

All this is not really covered by public/protected/private, because
depending upon your relationship with the class, you might different
levels of access.

Python as a dynamic language in practice does not need access roles
like the above, albeit a comparable service is provided by
zope.interfaces.

Andreas