Steven D'Aprano <[EMAIL PROTECTED]> writes: > The philosophy of dynamic languages like Python is that the class designer > shouldn't be the only one who decides whether or not a particular variable > should be private or public.
I don't see that as part of the philosophy of dynamic languages. For example, the Python language spec describes a way to reach the private variables of class instances (through name mangling) but not a way to get at the private variables of closures or generators (though you can still do that in CPython through some implementation-specific hacks). I don't think those implementation hacks are a deep philosophical consequence of anything, and Python would still be Python without them. I don't see why generator designers should be any different from class designers in your logic. Why is it so important for freedom-loving programmers to be able to mess with the private variables of instances but not of generators? How are they different? (Answer: They are not different. Both are unimportant.) > The class designer is assumed to know their class best, and therefore be > in a position to know what variables are dangerous or inconvenient to leak > and which are not. But the class user is the person who knows their own > needs best, and therefore best to know whether their needs are such that > they are willing to take that risk. Why do you think the designer and user are necessarily not the same person? Maybe an app writer wants to create some fault tolerance by implementing privilege separation inside an application. I mentioned in another post that I wrote a crypto class that does exactly that, by putting the crypto variables in a separate Python interpreter from the client, and communicating by RPC over sockets. I'm both the designer and the user, and I wanted to protect the data in some of the classes I wrote from code from possible misbehavior of other classes that I wrote. With private variables, I could do that in a single process with reasonable security and much less overhead. > Why should the class designer get a monopoly on deciding what the > class user can or cannot do? Um, because the designer wrote the code? If the designer chose an algorithm that's not to the user's liking, the user's only way to fix it is by modifying the code (and thereby becoming a co-designer). What's special about instance variables, that they should all be accessible from elsewhere in the program without modifying the code? > If you believe that the class designer should have the privilege of > prohibiting certain uses of the class, Not the class, just instances of the class in a running program. The user can always repurpose the class by modifying the code and making new instances of the modified class. > you will vote for private variables. If you believe that the class > users should have more freedom, you will vote against them. You're assuming some kind of conflict between the designer and the user. If the app is such that a conflict actually exists (e.g. the user is a possibly-hostile applet), then letting the designer enforce security is essential. If no conflict exists, then the designer and user (who might be the same person) can work out something to their satisfaction. > "Truly" private variables have an advantage of making the class > designer's life somewhat easier -- not much, but a little. But that > advantage comes at the cost of making the class user's life somewhat > harder -- not much, but a little -- by restricting what they can > do. Your private variable may be just what they need to solve some > problem you never even thought of. The right way to extend or override class method behavior is by subclassing or changing the implementation. This notion of reaching into the private variables of running instances is a violation of type safety and a silly hack. -- http://mail.python.org/mailman/listinfo/python-list
