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

[Bengt Richter]

On Sun, 02 Oct 2005 16:42:49 -0400, Mike Meyer <mwm at mired.org> wrote:

>Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
>> Well, it's a discussion of why a certain feature might be useful, not
>> that it's required.  Mike Meyer points out some reasons it might be
>> hard to do smoothly without changing Python semantics in a deep way
>> (i.e. Python 3.0 or later).  
>
>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."
>
>Not that I think that private is a bad idea. If I'm not writing
>python, then I'm probably writing Eiffel. Eiffel has facilities for
>protecting features, though the design is more consistent than the
>mishmash one gets in C++/Java. Nuts - in Eiffel, you can't write
>"instance.attribute = value"; assignment to an attribute has to be
>done in a method of the owning instance.
Actually, ISTM that's true of python too, considering that

    instance.attribute = value

is sort of syntactic sugar for

    instance.__setattr__('attribute', value)

so it's a (normally inherited) "method of the owning instance"
(taking that to mean a method of its class) that does the assignment.

>
>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.
I agree, but I wouldn't agree if I thought you were saying it's useless
to define exactly what it is we're talking about before deciding on
what needs hw/os/gil/intepreter/convention level support, and how python
would make use of such a capability, however implemented.

Paul summarised three levels, of which at least fixing unintentional
name-mangling collisions could be solved, IWT.

>
>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.
Yeah, but IRL how close to *never* do you in practice demand
to bet your life on it? ;-)

>
>For example, I once had a system that took a kernel panic trying to
>boot an OS upgrade. It had been running the previous versionn of the
>OS for most of a year with no problems. Other basically identical
>systems ran the upgraded OS just fine. I finally wound up stepping
>through the code one instruction at a time, to find that the
>subroutine invocation instruction on this machine was setting a bit in
>a register that it wasn't supposed to touch, but only in kernel
>mode. An internal OS API change meant it only showed up in the
>upgraded OS.
>
>The infamous Pentium floating point bug shows that this case isn't
>restricted to failing hardware.
>
Was that software? I've forgotten the details and am too lazy to google ;-/

Regards,
Bengt Richter