Paul Rubin <http://[EMAIL PROTECTED]> 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.
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.
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.
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.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
