> > > > that an underscore convention is > > > "just as good", (It isn't), > > > > Why isn't it? > > Because it needs human intervention. >
Not necessarily at all: that's something that could be checked very readily with static analysis. Why isn't that a good enough tool if policy isn't sufficient? If you scan the code for "<target>._<something>" and target is not "self", and <something> is not a magic method, then I think that is an encapsulation error. I don't know that Pylint or the various other flavors of analysis tools have an option to check for that, but wouldn't adding one be better then changing the language? That way those who want it get the certainty that encapsulation is never broken, and those who don't care don't have to worry about it. > > > > that you could crack it if you really > > > tried, (so what?), > > > > Exactly.. so what? WHY is the convention not enough? What REAL > > situation is there that the lack of *forced* encapsulation but policy > > based encapsulation not enough? > > > > See human intervention above - and as for > "real, forced data hiding" - have you ever > coded anything that produced a segmentation fault? > [ snip discussion of processor memory protection ] That's apples to... potatoes. I'm not opposed to memory protection :) Segmentation faults and memoy protection are an utterly different thing. One protects against a programmer accidentally going in and overwriting something that he shouldn't, when he doesn't even know he's doing it. The other protects against a programmer *intentionally* and *explicitly* going into source code and finding an undocumented internal detail to *intentionally* change it for some specific purpose. One stops someone from making a mistake. The other stops someone from doing something they /intend/ on doing. (Both may have an impact on someone with malicious intent, but that's a whole other subject) --S P.S. Aiee, this discussion is getting overwhelmingly long. :)
-- http://mail.python.org/mailman/listinfo/python-list
