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

[Paul Rubin]

Mike Meyer <mwm at mired.org> writes:
> Actually, I think that the semantic changes required to make private
> do what you want are deep enough that the resulting language
> wouldn't be Python any longer. It has deep implications from the
> interpeter implementation all the way out to the design of the
> standard library, all of which would have to be reworked to make
> private do "the right thing."

Nah, I think Python could withstand those changes and still be Python.

> Which brings me to my point. Rather than trying to bandage Python to
> do what you want - and what, based on this thread, a lot of other
> people *don't* want - you should be building a system from the ground
> up to support the kind of B&D environment you want.

Heh, that goes against the principle that Python is supposed to be
good for everything.  For example, there was a partly-written web
browser called Grail written in Python, that used Python instead of
Javascript for web scripting.  I believe it depended on rexec/Bastion
to stop scripts from taking over the browser.  Wanting to write a
browser that way is perfectly reasonable.  But lack of a secure rexec
makes that approach impossible.  Maybe it's not feasible to implement
rexec in Python 2.x.  But I don't see anything B&D-ish about hoping
that as Python evolves, it becomes possible to bring back rexec.

> Of course, you do realize that in practice you can *never* get what
> you want. It assumes that the infrastructure is all bug-free, which
> may not be the case.

Yes, of course, you need to be careful at every level.