Paul Rubin wrote: > If changing the way a class uses its own private variables breaks an > application > because another class was using the private variable unexpectedly, > then that's bad, regardless of whether the other class's author was > notified or not. It's better to let the compiler automatically flag > these things, than to depend on conventions.
The problem with Python's compiler as it is today is that it can't generally detect private attribute access: information about an object/class being accessed is only guaranteed to be available at run-time. Of course, Bastion and its peers [1] "solve" this by introducing run-time environments which seek to guarantee attribute privacy. As for the merits of private/protected/final attributes and methods, I've seen enough time-wasting and premature "security" optimisations to know that such facilities can also waste a tremendous amount of time in multi-person projects. Paul [1] At EuroPython there was a talk about protecting object attributes in Ubuntu Launchpad [2], for which the slides are apparently unavailable, and while chatting about this later on I noted that I'd seen something like it before. The realisation that mxProxy [3] was this apparently often overlooked thing occurred more or less simultaneously with the realisation that I was talking to its author. :-) [2] http://www.python-in-business.org/ep2005/talk.chtml?talk=1610&track=692 [3] http://www.egenix.com/files/python/mxProxy.html -- http://mail.python.org/mailman/listinfo/python-list
