On Monday 02 February 2009 04:51:11 pm Russ P. wrote: > As I said before, as an aeronautical engineer I don't know if enforced > access restriction can be added to Python without compromising or > unduly complicating the language. Maybe it can't. If that's the case, > then people should make that argument. But just saying that enforced > access restriction is useless in general is nonsense. Are we supposed > to believe that the designers of C++, Java, Ada, and Scala are all > idiots?
I'm amazed at how quickly this thread degenerated into another 'enforced data hiding' thread. I think the previous one ran long enough for me to actually say that 'access restriction is nonsense', when my point had been '_enforced_ access restrictions in python is worthless in all the examples provided so far' (except perhaps the extensions modules, but those are not python). You are an aeronautical engineer. You, and I understand that, don't want, shouldn't want, and will not want to run anything you cannot trust. You want the most assurances you can get. You are well within your right to want that - to disallow in your systems, and in the systems that you build, anything that you even suspect that may threaten the integrity of the system, and let's face it, breaking the encapsulation, intentional or not, is pretty suspicious. So, in current python, _you_ have the _choice_ of preventing it. As the checks are static, of course, you can break them in runtime, just like you would in C, C++ and Java. But somehow, it is not enough for you that you have the choice, because that also gives _me_ the choice of _not_ doing it in my own systems. And you still haven't said why it bothers you that I have the choice. Now, if you were arguing for [truly optional - as in, the user decides] dynamic checks, you may see a very different position. That RExec and Bastion even existed should tell you that there is interest on implementing some kind of trusted execution (as in 'I trust this code to do whatever it wants, but not this other code'). That both projects failed should tell you that either it is impossible to achieve in python (which would be bad), or that there is just not enough interest on keeping them (which would not amaze me). But, if you are arguing for dynamic checks, those are not present in C++ either, and thus, it isn't really what you mean with enforced data hiding. > If an assignment to the previously > "private" attribute is missed, no warning will be issued (because > Python allows new attributes to be added anywhere, even completely > outside the class definition itself). And if the library is widely > used, the probability of such bugs occurring is very high. Good coding standards would prevent that. And by good coding standards, I mean "treat pylint and similar tools as a requirement before executing any code", and it will catch that sort of bugs. Again, _you_ have the choice. Use it if you wish. Now, I'm with you in that accidental variable creation is a nasty side effect of python dynamism (and that you may be forfeiting it if you go the pylint route). But that particular complaint has nothing to do with enforced vs not-enforced data hiding, and everything to do with static typing. And mind you, must of us who use python, do so _because_ of the dynamism and not in spite of it. Funny thing is, you have the choice, _now, today_, of having your precious static checks, both of them, for your projects. But you keep complaining because I also have the choice, and I may chose not to have them. -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
