Mike Meyer <[EMAIL PROTECTED]> writes: > > What convention? It just makes it possible to write code with some > > specific invariants if there's a need to do so. > > That you don't pass private variables to a function unless it's a builtin.
No, I don't see that as "convention", it's just something that you do if you want to make sure that all the references are local or builtins. It's like saying that if you if you want to be sure that x is always positive, then don't execute statements like "x = -3". I wouldn't call something like that a "convention". In C, one can easily crash an application by derefencing a null pointer, or break type safety by freeing something twice or setting an array element with an out-of-range index. In Python, those failures are supposed to be impossible. Not "inconvenient", but impossible. We usually think of that as a good thing, not a symptom of bondage and discipline. But (not even bothering with private instance variables or builtins), if I say def g(): for i in (1,2,3,4,5): yield i x = g() maybe I'd like to be sure that x never yields negative numbers. CPython happens to have some features that stop me from guaranteeing that invariant. A CPython script that makes x yield negative 3 is contorted but not impossible. Whether the existence of those hooks is a good thing or not, I don't see them as a fundamental characteristic of Python. Python without those hooks would still be Python. And I don't see why wanting to be able to guarantee that impossibility is somehow more B&D than wanting to guarantee the impossibility of null pointer dereferences. > Except that, with Python as it exists today with a private keyword > added, it's *still* everyone. The only convention breaking the private > keyword would allow the compiler to catch is a reference to > foo.private. Well, it would be done at runtime by __getattr__ or the like. > It wouldn't catch overriding things in __builtins__ or > overriding builtins in a module, or things poking at the variable > through __dict__, or - well, there are probably lots of things that > need to be dealt with. Yes, but I see all of those as implementation artifacts, not anything fundamental. > Preventing accidents is all "private" does - without fundamental > changes to the implementation of the language. You have to catch every > mechanism that can be used to find a reference to an attribute, like > references to __dict__ and to the class variable. The Python stdlib for a long time had a module called Bastion that attempted to do exactly that, so you can't say that the desire is un-Pythonic. Bastion was only removed because implementation issues kept it from working properly. Those issues probably can't be resolved in the 2.x series but as the language evolves, maybe something can be done to bring it back. -- http://mail.python.org/mailman/listinfo/python-list