On Sun, 02 Oct 2005 16:42:49 -0400, Mike Meyer <[EMAIL PROTECTED]> wrote:
>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. 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 -- http://mail.python.org/mailman/listinfo/python-list