[OT] Re: Why does python not have a mechanism for data hiding?
Dennis Lee Bieber a écrit : On Wed, 11 Jun 2008 10:10:14 +0200, Bruno Desthuilliers [EMAIL PROTECTED] declaimed the following in comp.lang.python: are some *very* talented and *experimented* programmers here. Pardon, but I think you mean experienced. Indeed. Tim Golden already corrected me (in private) about my mistake. Please pardon my french :-/ Of course, GvR may qualify as experimented if one considers designing a language from scratch to be an experiment G g++ ?-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Quoting Dennis Lee Bieber [EMAIL PROTECTED]: On Wed, 11 Jun 2008 21:54:33 -0700 (PDT), Michele Simionato [EMAIL PROTECTED] declaimed the following in comp.lang.python: It looks like in French (as in Italian) *experimented* has the meaning of tried and tested on the field when applied to a person. Spock raised eyebrow Fascinating Spanish also. I translate experimentado to experienced, perhaps because I had seen it before, but I never imagined that experimented would be wrong. Fascinating x2 -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 6 Juni, 03:09, Russ P. [EMAIL PROTECTED] wrote: On Jun 5, 2:57 pm, Hrvoje Niksic [EMAIL PROTECTED] wrote: Russ P. [EMAIL PROTECTED] writes: By the way, my recollection is that in C++ access defaults to private if nothing is declared explicity. So normally the private declaration is unnecessary. If it is left out, your little trick won't work. How about #define class struct I never thought of that one. I wonder what the C++ gurus would say about that. Let me guess. They'd probably say that the access restrictions are for your own good, and bypassing them is bound to do you more harm than good in the long run. And they'd probably be right. Just because you can break into a box labeled DANGER HIGH VOLTAGE, that doesn't make it a good idea. This just goes to show that the whole idea of using header files as simple text insertions is flaky to start with, and adding the preprocessor just compounds the flakiness. Needless to say, I'mnota big fan of C and C++. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 10, 11:58 am, Jonathan Gardner Who cares what the type of an object is? Only the machine. Being able to tell, in advance, what the type of a variable is is a premature optimization. Tools like psyco prove that computers (really, programmers) nowadays are smart enough to figure things out the right way without any hints from the developer. Static typing is no longer necessary in today's world. You couldn't be more wrong. Even Guido recognizes the potential value of static typing, which is why he is easing it into Python as on optional feature. He recognizes, correctly, that it can detect errors earlier and facilitate more efficient execution. But there's another, more significant potential benefit for safety-critical and mission- critical applications: static typing facilitates advanced static analysis of software. To get an idea of what that is about, take a look at http://www.sofcheck.com Here is an excerpt from their website: SofCheck’s advanced static error detection solutions find bugs in programs before programs are run. By mathematically analyzing every line of software, considering every possible input, and every path through the program, SofCheck’s solutions find any and all errors that cause a program to crash or produce an undefined result. Me again: static analysis does not replace traditional dynamic and unit testing, but it is far more advanced and finds many errors very quickly that might require weeks or months of dynamic testing -- or might not be found at all with dynamic testing until the product is in the field. With more and more automation of safety-critical systems these days, we need this more than ever. Your assertion that Static typing is no longer necessary in today's world, is just plain naive. Who cares about private declarations, or interface declarations at all? It is only a message to the developers. If you have a problem with your users doing the right thing, that is a social problem, not a technical one, and the solution is social, not technical. Yes, it is work, but it is not coding---it is explaining to other living, breathing human beings how to do a specific task, which is what you should have been doing from the start. You may be right to an extent for small or medium-sized non-critical projects, but you are certainly not right in general. I read something a while back about the flight software for the Boeing 777. I think it was something like 3,000,000 lines of Ada code. Normally, for a project of that magnitude the final integration would be expected to take something like three months. However, the precise interface specs and encapsulation methods in Ada allowed the integration to be completed in just three days. By your recommended method of social interaction, that would be one hell of a lot of talking! I realize that Python is not designed for such large projects, but don't you think certain general principles can be learned anyway? Perhaps the benefits of interface specs and encapsulation are not as obvious for smaller projects, but certainly they are not zero. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 11, 8:11 am, Russ P. [EMAIL PROTECTED] wrote: On Jun 10, 11:58 am, Jonathan Gardner Who cares what the type of an object is? Only the machine. Being able to tell, in advance, what the type of a variable is is a premature optimization. Tools like psyco prove that computers (really, programmers) nowadays are smart enough to figure things out the right way without any hints from the developer. Static typing is no longer necessary in today's world. You couldn't be more wrong. Even Guido recognizes the potential value of static typing, which is why he is easing it into Python as on optional feature. He recognizes, correctly, that it can detect errors earlier and facilitate more efficient execution. But there's another, more significant potential benefit for safety-critical and mission- critical applications: static typing facilitates advanced static analysis of software. Can you provide me with any example of Guide wanting static typing to be optional? I haven't. Any why is it you keep going so abstract in this discussion. You may be right to an extent for small or medium-sized non-critical projects, but you are certainly not right in general. I read something a while back about the flight software for the Boeing 777. I think it was something like 3,000,000 lines of Ada code. Normally, for a project of that magnitude the final integration would be expected to take something like three months. However, the precise interface specs and encapsulation methods in Ada allowed the integration to be completed in just three days. Well, that isn't just because they used encapsulation, the likelihood is well thoughtout planning, constant system testing (that DOES require accessing of those more private methods to ensure there are no problems throughout), and re-testing. Again since I'm not sure how much I trust you and your statistics anymore, have you a link to anything discussing this? I realize that Python is not designed for such large projects, but don't you think certain general principles can be learned anyway? Perhaps the benefits of interface specs and encapsulation are not as obvious for smaller projects, but certainly they are not zero. Python is designed to be an efficient high level language for writing clear readable code at any level. Considering the amount of use it gets from Google, and the scope and size of many of their projects, I find it foolish to say it is not designed for large projects. However I do not myself have an example of a large python project, because I don't program python at work. I think the issue here is your want to have python perform exactly like OO built languages such as Java, but it isn't Java, and that, is a good thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : On Jun 10, 1:04 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: If you hope to get a general agreement here in favor of a useless keyword that don't bring anything to the language, then yes, I'm afraid you're wasting your time. Actually, what I hope to do is to take something away from the language, and that is the need to clutter my identifiers with leading underscores. I find that I spend the vast majority of my programming time working on the private aspects of my code, and I just don't want to look at leading underscores everywhere. So I usually just leave them off and resort to a separate user guide to specify the public interface. I'll bet many Python programmers do the same. How many Python programmers do you think use leading underscores on every private data member or method, or even most of them for that matter? First point : please s/private/implementation/g. As long as you don't get why it's primary to make this conceptual shift, the whole discussion is hopeless. Second point : I've read millions of lines of (production) python code these last years, and I can assure you that everyone used this convention. And respected it. I'll bet not many. (See the original post on this thread.) That means that this particular aspect of Python is basically encouraging sloppy programming practices. Bullshit. Working experience is here to prove that it JustWork(tm). What I don't understand is your visceral hostility to the idea of a priv or private keyword. Because it's at best totally useless. If it offends you, you wouldn't need to use it in your own code. You would be perfectly free to continue using the leading-underscore convention (unless your employer tells you otherwise, of course). My employer doesn't tell me how to write code. I'm not a java-drone. My employer employ me because he is confident in my abilities, not because he needs some monkey to type the code. The point is not *my* code, but the whole free python codebase. I definitively do not want it to start looking anything like Java. Thanks. I get the impression that Python suits your own purposes and you really don't care much about what purpose others might have for it. Strange enough, every time I read something like this, it happens that it comes from someone who is going to ask for some fundamental change in a language used by millions of persons for the 15+ past years just because they think it would be better for their own current project. I am using it to develop a research prototype of a major safety-critical system. I chose Python because it enhances my productivity and has a clean syntax, but my prototype will eventually have to be re-written in another language. I took a risk in choosing Python, and I would feel better about it if Python would move up to the next level with more advanced features such as (optional) static typing and private declarations. I'm sorry, but I don't see any of this as being a move up to the next level. But every time I propose something like that, fundamental change in the language for your own (perceived, and mostly imaginary) needs, that is... I get all kinds of flak from people here who do their hacking and care little about anyone else's needs. No one needs another Java. Now what happens here is that *you* come here explaining everyone that they need to adapt to the way *you* think things should be. With a few relatively small improvements, Python could expand its domain considerably and make major inroads into territory that is now dominated by C++, Java, and other statically compiled languages. But that won't happen if reactionary hackers stand in the way. So anyone not agreeing with you - whatever his experience, reasons etc - is by definition a reactionnary hacker ? Nice to know. Side note: I've been looking at Scala, and I like what I see. It may actually be more appropriate for my needs, but I have so much invested in Python at this point that the switch will not be easy. So instead of taking time to learn the tool that would fit your needs, you ask for fundamental changes in a language that fits millions other persons needs ? Now let's talk about not caring about other's needs... -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : On Jun 10, 11:58 am, Jonathan Gardner (snip) Who cares about private declarations, or interface declarations at all? It is only a message to the developers. If you have a problem with your users doing the right thing, that is a social problem, not a technical one, and the solution is social, not technical. Yes, it is work, but it is not coding---it is explaining to other living, breathing human beings how to do a specific task, which is what you should have been doing from the start. You may be right to an extent for small or medium-sized non-critical projects, but you are certainly not right in general. I read something a while back about the flight software for the Boeing 777. I think it was something like 3,000,000 lines of Ada code. I can't obviously back my claim, but you could probably have the same feature set implemented in 10 to 20 times less code in Python. Not that I suggest using Python here specifically, but just to remind you that kloc is not a very exact metric - it's relative to the design, the language and the programmer(s). The first project I worked on (professionaly) was about 100 000 locs when I took over it, and one year later it was about 50 000 locs, with way less bugs and way more features. FWIW, the bigger the project, the bigger the chances that you could cut it by half with a good refactoring. Normally, for a project of that magnitude the final integration would be expected to take something like three months. However, the precise interface specs and encapsulation methods in Ada allowed the integration to be completed in just three days. By your recommended method of social interaction, that would be one hell of a lot of talking! Or just writing and reading. I realize that Python is not designed for such large projects, Clueless again. Python is pretty good for large projects. Now the point is that it tends to make them way smaller than some other much more static languages. As an average, you can count on something between 5:1 to 10:1 ratio between Java (typical and well-known reference) and Python for a same feature set. And the larger the project, the greater the ratio. but don't you think certain general principles can be learned anyway? Do you really think you're talking to a bunch of clueless newbies ? You can bet there are quite a lot of talented *and experimented* programmers here. Perhaps the benefits of interface specs and encapsulation are not as obvious for smaller projects, Plain wrong. but certainly they are not zero. You still fail to get the point. Interface specifications and encapsulation are design principles. period. These principles are just as well expressed with documentation and naming conventions, and the cost is way lower. Russ, do yourself a favor : get out of your cargo-cult one minute and ask yourself whether all python users are really such a bunch of clueless newbies and cowboy hackers. You may not have noticed, but there are some *very* talented and *experimented* programmers here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Le Wednesday 11 June 2008 08:11:02 Russ P., vous avez écrit : http://www.sofcheck.com Here is an excerpt from their website: SofCheck’s advanced static error detection solutions find bugs in programs before programs are run. By mathematically analyzing every line of software, considering every possible input, and every path through the program, SofCheck’s solutions find any and all errors that cause a program to crash or produce an undefined result. Don't mix commercial discourse with technical, it desserves your point. Theoretically, wether a program has bugs or not is not computable. Static analysis as they imply is just nonsense. AFAIK, the efforts needed to make good static analysis are proven, by experience, to be at least as time consuming than the efforts needed to make good unit and dynamic testing. -- _ Maric Michaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 11 Jun, 10:10, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Russ P. a écrit : You may be right to an extent for small or medium-sized non-critical projects, but you are certainly not right in general. I read something a while back about the flight software for the Boeing 777. I think it was something like 3,000,000 lines of Ada code. I can't obviously back my claim, but you could probably have the same feature set implemented in 10 to 20 times less code in Python. It's easy to make claims like this knowing that people aren't likely to try and write such a system in Python. Not that I suggest using Python here specifically, but just to remind you that kloc is not a very exact metric - it's relative to the design, the language and the programmer(s). The first project I worked on (professionaly) was about 100 000 locs when I took over it, and one year later it was about 50 000 locs, with way less bugs and way more features. FWIW, the bigger the project, the bigger the chances that you could cut it by half with a good refactoring. Perhaps you should get in touch with the advocacy-sig mailing list and provide them with the concrete details, because although you and I (and many others) recognise intuitively that Python code is typically shorter than, say, Java because the boilerplate of the latter is unnecessary, the last big discussion I recall about Python code being shorter than that of statically typed languages didn't really yield much in the way of actual projects to make the case. Normally, for a project of that magnitude the final integration would be expected to take something like three months. However, the precise interface specs and encapsulation methods in Ada allowed the integration to be completed in just three days. By your recommended method of social interaction, that would be one hell of a lot of talking! Or just writing and reading. Maybe, but I'd imagine that the project mentioned is a fairly large one with all the classic observations by Brooks highly applicable. Such things can incur huge costs in a large project. I realize that Python is not designed for such large projects, Clueless again. Python is pretty good for large projects. It might be good for large projects but is it good for large projects *such as the one mentioned*? Now the point is that it tends to make them way smaller than some other much more static languages. As an average, you can count on something between 5:1 to 10:1 ratio between Java (typical and well-known reference) and Python for a same feature set. And the larger the project, the greater the ratio. Again, I don't doubt this intuitively, but many people do doubt it. Citation needed! [...] Do you really think you're talking to a bunch of clueless newbies ? You can bet there are quite a lot of talented *and experimented* programmers here. Maybe, but with the style of discourse you've been using, you're not really speaking for them, are you? Perhaps the benefits of interface specs and encapsulation are not as obvious for smaller projects, Plain wrong. I'm not a big fan of lots of up-front declarations when the code is easy to understand intuitively, but what are you trying to say here? That interface specifications and encapsulation are as essential for a three line script as they are for a large project? but certainly they are not zero. You still fail to get the point. Interface specifications and encapsulation are design principles. period. These principles are just as well expressed with documentation and naming conventions, and the cost is way lower. I guess it depends on how the documentation gets written, because from what I've seen documentation is one of the more neglected areas of endeavour in software development, with many development organisations considering it a luxury which requires only a cursory treatment in order to get the code out of the door. Russ, do yourself a favor : get out of your cargo-cult one minute and ask yourself whether all python users are really such a bunch of clueless newbies and cowboy hackers. You may not have noticed, but there are some *very* talented and *experimented* programmers here. Maybe, but I'd hope that some of those programmers would be at least able to entertain what Russ has been saying rather than setting themselves up in an argumentative position where to concede any limitation in Python might be considered some kind of weakness that one should be unwilling to admit. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 11, 2:36 am, Paul Boddie [EMAIL PROTECTED] wrote: Maybe, but I'd hope that some of those programmers would be at least able to entertain what Russ has been saying rather than setting themselves up in an argumentative position where to concede any limitation in Python might be considered some kind of weakness that one should be unwilling to admit. Thanks. I sometimes get the impression that Desthuilliers thinks of this forum like a pack of dogs, where he is the top dog and I am a newcomer who needs to be put in his place. I just wish he would take a chill pill and give it a rest. I am not trying to challenge his position as top dog. All I did was to suggest that a keyword be added to Python to designate private data and methods without cluttering my cherished code with those ugly leading underscores all over the place. I don't like that clutter any more than I like all those semi-colons in other popular languages. I was originally attracted to Python for its clean syntax, but when I learned about the leading-underscore convention I nearly gagged. If Desthuilliers doesn't like my suggestion, then fine. If no other Python programmer in the world likes it, then so be it. But do we really need to get personal about it? Python will not be ruined if it gets such a keyword, and Desthuilliers would be perfectly free to continue using the leading-underscore convention if he wishes. Where is the threat to his way of life? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Wed, Jun 11, 2008 at 12:28 PM, Russ P. [EMAIL PROTECTED] wrote: If Desthuilliers doesn't like my suggestion, then fine. If no other Python programmer in the world likes it, then so be it. But do we really need to get personal about it? Python will not be ruined if it gets such a keyword, and Desthuilliers would be perfectly free to continue using the leading-underscore convention if he wishes. Where is the threat to his way of life? Well, you have to understand that a lot of python programmers are refugees from the microsoft or sun worlds, where we were forced to do things a certain way, and often it was not in our opinion the best way, but there wasn't anything we could do about it. Some of these refugees are very experienced in that other world, and don't want to go back there. So proposing that python borrow these methods of control from the place we have fled from can feel threatening. Some people obviously take it more personally than others, but this is a general feeling a lot of python programmers share. Also I'm fairly certain you're not the first to mention this topic. Here's what the cookbook has to say: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/573442 Something like that is really your best bet. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 11 Jun, 21:28, Russ P. [EMAIL PROTECTED] wrote: All I did was to suggest that a keyword be added to Python to designate private data and methods without cluttering my cherished code with those ugly leading underscores all over the place. I don't like that clutter any more than I like all those semi-colons in other popular languages. I was originally attracted to Python for its clean syntax, but when I learned about the leading-underscore convention I nearly gagged. I'm not bothered about having private instance data, but I think there's definitely a case to be answered about the double-underscore name-mangling convention. In the remote past, people were fairly honest about it being something of a hack, albeit one which had mostly satisfactory results, and unlike the private instance data argument which can often be countered by emphasising social measures, there has been genuine surprise about this particular method of preventing attribute name collisions - it's an issue which can trip up even careful programmers. Note also that the double-underscore convention is listed as a Python wart [1] and is described by Kuchling thus: But it's a hack and a kludge; making privacy depend on an unrelated property such as the attribute's name is clumsy. At least this ugliness is limited to one specific and little-used case; few Python programmers ever bother to use this private variable feature. In my opinion there are too many people either defending the status quo (warts and all) or pushing the envelope in many areas that didn't overly bother people before (various Python 3000 features). Paul [1] http://wiki.python.org/moin/PythonWarts -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 12, 6:43 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Wed, 11 Jun 2008 10:10:14 +0200, Bruno Desthuilliers [EMAIL PROTECTED] declaimed the following in comp.lang.python: are some *very* talented and *experimented* programmers here. Pardon, but I think you mean experienced. Of course, GvR may qualify as experimented if one considers designing a language from scratch to be an experiment G It looks like in French (as in Italian) *experimented* has the meaning of tried and tested on the field when applied to a person. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Michele Simionato [EMAIL PROTECTED] writes: On Jun 12, 6:43 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote: Pardon, but I think you mean experienced. Of course, GvR may qualify as experimented if one considers designing a language from scratch to be an experiment G It looks like in French (as in Italian) *experimented* has the meaning of tried and tested on the field when applied to a person. That would, in English, be proven (from similar ideas: to prove means to determine the truth by a test or trial). -- \ I went over to the neighbor's and asked to borrow a cup of | `\salt. 'What are you making?' 'A salt lick.' -- Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : On Jun 9, 2:10 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: But if it takes 6 month to get the mentioned developer to release something I can use, I'm screwed up. Fine. I've lost track of how many times I've said this now, but my suggestion for a priv keyword allowed for indirect access to private data through some name-mangling scheme. And I've lost track of how many times I've said this now, but we already have this. While we're at it, why not a 'prot' keyword that would restrict name-mangling to the addition of a single leading underscore ? That could be your temporary fix while you are waiting for the developer to release a corrected version. And even if that option were not available, you could simply open up the relevant source file in the editor of your choice and remove the offending priv declaration. Yes. And I can always edit the source code and add the methods I need etc. You probably never used monkeypatching, so I guess you just can't understand the difference between maintaining a monkeypatch and maintaining a fork. I completely fail to see how you are screwed. Sorry, but when I have to keep repeating the same basic points over and over, I can't help but think I might be wasting my time. If you hope to get a general agreement here in favor of a useless keyword that don't bring anything to the language, then yes, I'm afraid you're wasting your time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-09, Lie [EMAIL PROTECTED] wrote: That seems strange to me. The and-or simulation that was offerd in the FAQ allowed for about the same kind of structures as the ternary operator in C and was used in the standard library IIRC. So the same unreadable was already possible to write, plus that it could cause bugs and had to be made even more unreadable in order to work correctly. Considering this it I find it odd that hurting readability was a motivation not to have it. In case you didn't notice, the and-or simulation is a hack, it is not to be used by anyone writing real code (instead of for an entry to Obfuscated Python Code Contest) to substitute it for inline if. If inline if is formalized, that means the language encourages the use of inline if, which we don't want to have. Who is we? The last poll I know about had a majority in favor of a ternary operator. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 10, 1:04 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: If you hope to get a general agreement here in favor of a useless keyword that don't bring anything to the language, then yes, I'm afraid you're wasting your time. Actually, what I hope to do is to take something away from the language, and that is the need to clutter my identifiers with leading underscores. I find that I spend the vast majority of my programming time working on the private aspects of my code, and I just don't want to look at leading underscores everywhere. So I usually just leave them off and resort to a separate user guide to specify the public interface. I'll bet many Python programmers do the same. How many Python programmers do you think use leading underscores on every private data member or method, or even most of them for that matter? I'll bet not many. (See the original post on this thread.) That means that this particular aspect of Python is basically encouraging sloppy programming practices. What I don't understand is your visceral hostility to the idea of a priv or private keyword. If it offends you, you wouldn't need to use it in your own code. You would be perfectly free to continue using the leading-underscore convention (unless your employer tells you otherwise, of course). I get the impression that Python suits your own purposes and you really don't care much about what purpose others might have for it. I am using it to develop a research prototype of a major safety-critical system. I chose Python because it enhances my productivity and has a clean syntax, but my prototype will eventually have to be re-written in another language. I took a risk in choosing Python, and I would feel better about it if Python would move up to the next level with more advanced features such as (optional) static typing and private declarations. But every time I propose something like that, I get all kinds of flak from people here who do their hacking and care little about anyone else's needs. With a few relatively small improvements, Python could expand its domain considerably and make major inroads into territory that is now dominated by C++, Java, and other statically compiled languages. But that won't happen if reactionary hackers stand in the way. Side note: I've been looking at Scala, and I like what I see. It may actually be more appropriate for my needs, but I have so much invested in Python at this point that the switch will not be easy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Hi Russ, Here are just some pragmatic considerations. Personally I am against data hiding, but I obviously won't convince you in that regard. There are some pros and cons as with anything, and I feel the cons outweight the pros (namely that users of code should be able to use how they want, even if it means shooting themselves in the foot; and the fact that priv somewhat breaks the dynamics of python) Even if your proposal were to go through, you are looking at probably 2 years before it can even be used. Python3 is basically in freeze mode, and it contains the biggest change in python syntax for a long time. I know it doesn't seem like a big change to you to add a priv keyword, but python very rarely adds keywords, so it's a long shot merely for that reason. This is something that potentially would be under consideration for something like 3.2 or higher I think, so if you want to get the job done now, this topic or trying to convince other long time python users isn't going to accomplish your goals. Leading underscore takes two keystrokes to type (shift, _) while priv, private, etc takes many more. If you are too lazy to type _var then how come you aren't too lazy to type priv var? Too me it seems like more typing. If the primary objection to leading underscores is looks, it seems like you unnecesarily avoid them for a pointless reason. There are ugly aspects to every language, and there isn't really a better convention to use that I can see. Without of course implementing keywords, which are conceptually difficult to think about in terms of python object model - although you might be able to come up with a way. But if you have a better naming convention or strategy that you want to try on your code, nothing is stopping you. You can use one of the hacks found in this thread, or come up with your own hack, to more or less accomplish what you want. It should take 30 minutes or less to set up, and you are done with it. The internals of python make it difficult to do more than that, but you are welcome to create your own python fork if you think you are up to it. Although I think that would be more than 30 minutes of work. And feel free to try other languages. No one claimed python is the best for every circumstance. Well, if someone claimed that they are just fooling themselves. Python is a good hacker language that scales pretty well into enterprise and web services; and can be used for other things as well. I don't believe that data prevention (we aren't really talking about just hiding here) is necessary for 99% of tasks, but other people think differently, so there are plenty of languages that implement these features. Good luck finding a solution to fit your project. However I don't think trying to get a priv keyword into official python is feasable unless you want to wait a very long time and go hoarse from shouting :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 10, 11:21 am, Russ P. [EMAIL PROTECTED] wrote: I took a risk in choosing Python, and I would feel better about it if Python would move up to the next level with more advanced features such as (optional) static typing and private declarations. But every time I propose something like that, I get all kinds of flak from people here who do their hacking and care little about anyone else's needs. Let me share my personal insight. I used Python for a mission-critical application that needed, in effect, almost 100% uptime with superior throughput. In other words, it was a very fine piece of art that needed to be precise and correct. In the end, Python delivered, under budget, under schedule, and with superbly low maintenance costs (practically 0 compared to other systems written in Java and C). I didn't have to use any of the features you mentioned, and I can't imagine why you would need them. In fact, having them in the language would encourage others to use them and make my software less reliable. You may think we are all a bunch of hackers who are too stupid to understand what you are saying, but that is your loss. Now, let me try to explain something that perhaps the previous 166 post may not have thoroughly explained. If I am duplicating what everyone else has already said, then it's my own fault. Short answer: You don't need these features in Python. You do need to use the right tools for the right tasks. Long answer: Who cares what the type of an object is? Only the machine. Being able to tell, in advance, what the type of a variable is is a premature optimization. Tools like psyco prove that computers (really, programmers) nowadays are smart enough to figure things out the right way without any hints from the developer. Static typing is no longer necessary in today's world. Who cares about private declarations, or interface declarations at all? It is only a message to the developers. If you have a problem with your users doing the right thing, that is a social problem, not a technical one, and the solution is social, not technical. Yes, it is work, but it is not coding---it is explaining to other living, breathing human beings how to do a specific task, which is what you should have been doing from the start. When all you have is a hammer, the world seems full of nails. Think about that. You have more tools than Python to solve these problems, and Python will never be the panacea you wish it was. The panacea is you, putting the right tools to use for the right tasks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Jonathan Gardner wrote: Let me share my personal insight. I used Python for a mission-critical application that needed, in effect, almost 100% uptime with superior throughput. In other words, it was a very fine piece of art that needed to be precise and correct. In the end, Python delivered, under budget, under schedule, and with superbly low maintenance costs (practically 0 compared to other systems written in Java and C). I didn't have to use any of the features you mentioned, and I can't imagine why you would need them. In fact, having them in the language would encourage others to use them and make my software less reliable. At the risk of prolonging this thread, I'll add my own personal insight. I've spent a decent amount of time programming in Java, and the overhead of assigning a too-restrictive privacy level (which happens a lot, once privacy levels are in the language) has cost me an immense amount of time. I've lost count of how often I've had a software package which made an element non-public, in many cases for no apparent good reason, except that they hadn't anticipated the way I was going to use their code. Tracing down the consequences of these decisions, and trying to work around them, has been exceptionally time-consuming for me. You can say that I can go and modify the source code, as long as I have the source code, but that misses the point: I don't WANT to keep my own copy of the code, with the attended overhead in merging it with subsequent releases, etc. I'm not going to claim that data hiding has no purpose - it clearly addresses a set of concerns that programmers have about managing APIs. But I've found that its difficulties far outweigh its benefits. Sam Bayer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Mark Wooding a écrit : Russ P. [EMAIL PROTECTED] wrote: The idea of being able to discern properties of an object by its name alone is something that is not normally done in programming in general. Really? You obviously haven't noticed Prolog, Smalltalk, Haskell, ML, or Erlang then. And that's just the ones I can think of off the top of my head. * Prolog and Erlang distinguish atoms from variables by the case of the first letter; also `_' is magical and is equivalent to a new variable name every time you use it. * Smalltalk distinguishes between global and local variables according to the case of the first letter. * Haskell distinguishes between normal functions and constructors (both data constructors and type constructors) by the case of the first letter, and has Prolog's `_' convention. * ML allows a single-quote in variable names, but reserves names beginning with a single-quote for type variables. It also has Prolog's `_' convention. You could add Ruby's naming rules here. Or the very very common convention of using ALL_UPPER for symbolic constants (or pseudo-constants as in Python). And *quite a lot* of other either cross-language or language-specific naming conventions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : On Jun 8, 5:40 am, Mark Wooding [EMAIL PROTECTED] wrote: Russ P. [EMAIL PROTECTED] wrote: The idea of being able to discern properties of an object by its name alone is something that is not normally done in programming in general. Really? You obviously haven't noticed Prolog, Smalltalk, Haskell, ML, or Erlang then. And that's just the ones I can think of off the top of my head. * Prolog and Erlang distinguish atoms from variables by the case of the first letter; also `_' is magical and is equivalent to a new variable name every time you use it. * Smalltalk distinguishes between global and local variables according to the case of the first letter. * Haskell distinguishes between normal functions and constructors (both data constructors and type constructors) by the case of the first letter, and has Prolog's `_' convention. * ML allows a single-quote in variable names, but reserves names beginning with a single-quote for type variables. It also has Prolog's `_' convention. As far as I can see, discerning properties of a thing from its name seems relatively common. Well, common in Prolog, Smalltalk, Haskell, ML, and Erlang is hardly common in general. I'll bet that Java and C/C++ are used more in North Dakota than all those languages combined are used in the entire world. And you'll very probably loose. That's not to say they aren't interesting academic languages, of course. Erlang an academic language ? Man, you're either a troll or totally clueless. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Mark Wooding a écrit : Fuzzyman [EMAIL PROTECTED] wrote: So, you are stating that no API programmer using Python *ever* has a valid or genuine reason for wanting (even if he can't have it) genuine 'hiding' of internal state or members from consumers of his (or her...) API? I don't want to speak for whoever you were responding to, but from my point of view... Yes. I understand the difference between the documented interface of a system and the details of its implementation. But sometimes it can be useful to take advantage of implementation details, particularly if the published interface is inadequate in some way. Whether or not I choose to make use of implementation details is a trade-off between immediate convenience and maintainability, but that's something I can make a rational decision about. By enforcing your `data hiding', you're effectively telling me that I'm too stupid to make rational decisions of this sort. And that's actually extremely insulting. I couldn't state it better. +1QOTW btw. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : On Jun 6, 8:25 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: I also realize, by the way, that Python allows a client of a class to define a new class member from completely outside the class definition. Obviously, that cannot be declared private. Why so ? Why should the client of a class not be able to declare a *private* member of the class? You're kidding, right? I'm dead serious. I often add implementation attributes to either a class or an instance. These *are* implementation parts, not API. If a client accesses a data member of a class, Please stop thinking in C++. This is Python, and all you have are attributes. Whether they're callable of not doesn't change much here. then by definition that member is not really private, Who cares about it being private ? The important point is that it's *implementation*, not *interface*. so letting the client create a new data member and declare it as private seems a bit silly to me. There are two ways to decorate a class or instance object (nb: Python's classes are objects too): the static way where you wrap the object in a decorator class or instance and use delegation, and the dynamic way where you just modify the original class or object at runtime. The fact that an attribute is added (or replaced) outside the class statement doesn't mean it has to be part of the interface. You sometime have pretty legitimate reason to modify the implementation at runtime. Actually, just letting the client create the new data member, private or not, seems like a bit of a stretch to me, but I'll leave that be. You're way too much in the Java/C++ way of thinking. For the record, I have made it abundantly clear that I don't think Python should not have as rigorous an encapsulation regime as C++ or Java. The worst that could happen with my proposition is that you would need to use a mangled name to access private data or methods. That's already the case - when you use __name_mangling. And if there's no effective access restriction, then what the point of having this 'priv' keyword ? But you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. Once again, I just don't see the point. Either you want effective access restriction in Python, or you don't. And if you don't, what would this 'priv' keyword be useful to ? In the end, I suppose it boils down to aesthetics and personal preference. The leading-underscore convention bothers me for two reasons: (1) like the OP, I don't like the way it makes my code look, and (2) it is a signal to a person reading the code, but it has no actual effect in the interpreter. Indeed. The target of the signal is definitively the person reading the code. I think the concept of private data and methods is important enough to be implemented with more than just a tacky naming convention. The concept of private attributes is not important. What's important is the concept of implementation attributes. That is why I suggested the priv keyword. At the same time, I realize that people will occasionally be frustrated if they are rigorously denied access to all private data, which is why I suggested an indirect method of access through mangled names. We already have all this. Either you want language-enforced access restriction - then you might be happier with another language - or you just want to have a clear way to know whether an attribute is part of the API or not - in which case a naming convention is not only enough, but even better. You can argue that such indirect access defeats the whole idea of private data, but at least it alerts the client to the fact that he (or she or it) is accessing private data So does the naming convention, with much less work. -- and it does so without using Hungarian notation. I wouldn't label this hungarian notation - or at least, not the way hungarian notation is now commonly understood. I would let the priv keyword also be used for data or functions at file scope. It just seems logical to me. Again, some name mangling convention could be concocted for those who think they really need access. Actually, the whole objection to denied access baffles me a bit. Free your mind from the very peculiar, restricted and IMHO braindead conception of OO they taught you with Java and C++. Python is older than Java, it's by now a very very commonly used language on all major platforms, and experience prooves that you just don't need anything more than a simple naming convention. Does anyone object to not having access from outside a function to local variables within the function? I doubt it. The other thing is that the vast majority of Python software, I would guess, is provided with source code. How many Python applications or libraries are provided without source code? If you have the source code, you can obviously just delete
Re: Why does python not have a mechanism for data hiding?
On 2008-06-07, BJörn Lindqvist [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon [EMAIL PROTECTED] wrote: Now of course noone would defend such a limitation on the grounds that one doesn't need the general case and that the general case will only save you some vertical space. But when it came to the ternary operator that was exactly the argument used, to defend the lack of it. As far as I remember, the primary motivation was developers experience with the ternary operator in other languages, especially C, where it was found to hurt readability. At least in my experience, it is much much more common to see the ternary operator making code more obfuscated than easing readability. Time will tell if Python's if-else expression will be abused in the same way. That seems strange to me. The and-or simulation that was offerd in the FAQ allowed for about the same kind of structures as the ternary operator in C and was used in the standard library IIRC. So the same unreadable was already possible to write, plus that it could cause bugs and had to be made even more unreadable in order to work correctly. Considering this it I find it odd that hurting readability was a motivation not to have it. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 9, 7:20 pm, Antoon Pardon [EMAIL PROTECTED] wrote: On 2008-06-07, BJörn Lindqvist [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon [EMAIL PROTECTED] wrote: Now of course noone would defend such a limitation on the grounds that one doesn't need the general case and that the general case will only save you some vertical space. But when it came to the ternary operator that was exactly the argument used, to defend the lack of it. As far as I remember, the primary motivation was developers experience with the ternary operator in other languages, especially C, where it was found to hurt readability. At least in my experience, it is much much more common to see the ternary operator making code more obfuscated than easing readability. Time will tell if Python's if-else expression will be abused in the same way. That seems strange to me. The and-or simulation that was offerd in the FAQ allowed for about the same kind of structures as the ternary operator in C and was used in the standard library IIRC. So the same unreadable was already possible to write, plus that it could cause bugs and had to be made even more unreadable in order to work correctly. Considering this it I find it odd that hurting readability was a motivation not to have it. In case you didn't notice, the and-or simulation is a hack, it is not to be used by anyone writing real code (instead of for an entry to Obfuscated Python Code Contest) to substitute it for inline if. If inline if is formalized, that means the language encourages the use of inline if, which we don't want to have. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 9, 2:23 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Mark Wooding a écrit : Fuzzyman [EMAIL PROTECTED] wrote: So, you are stating that no API programmer using Python *ever* has a valid or genuine reason for wanting (even if he can't have it) genuine 'hiding' of internal state or members from consumers of his (or her...) API? I don't want to speak for whoever you were responding to, but from my point of view... Yes. I understand the difference between the documented interface of a system and the details of its implementation. But sometimes it can be useful to take advantage of implementation details, particularly if the published interface is inadequate in some way. Whether or not I choose to make use of implementation details is a trade-off between immediate convenience and maintainability, but that's something I can make a rational decision about. By enforcing your `data hiding', you're effectively telling me that I'm too stupid to make rational decisions of this sort. And that's actually extremely insulting. I couldn't state it better. +1QOTW btw. Please see my previous reply to that post. Being insulted by data hiding is the QOTW? I'd call that an insult to everyone else who has posted on this forum in the past week. Unless of course you mean silliest QOTW. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 9, 2:22 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Does anyone object to not having access from outside a function to local variables within the function? I doubt it. The other thing is that the vast majority of Python software, I would guess, is provided with source code. How many Python applications or libraries are provided without source code? If you have the source code, you can obviously just delete the priv keyword anywhere or everywhere it appears. Yes, fine. And then have to maintain a fork of the source code, and distribute it with the application. Honking great idea. doh :-( A client who wishes to bypass access restrictions need not maintain any fork. If you have access to the source code, removing my proposed priv keyword from an entire library or application is a one- liner in sed. If you wish to remove only specific instances of its occurrences, that is also a trivial matter, and all that needs to be maintained by the client is a record of which instances were removed. In fact, the client doesn't even need to do that, because when the next version comes out they will be reminded very quickly of where they removed priv. But such a client would be a real fool for depending on private data and/or methods, of course, because those are not part of the public API and are not guaranteed to remain unchanged. The whole reason for private data and methods is that they give the developers freedom to change the implementation without changing the interface. How about some common sense here. If you, the client, are convinced that something declared private should really be public, then perhaps you should contact the developer and explain your reasoning. If the developer agrees, then the problem is solved. If not, then perhaps it is *you*, the client who does not understand the proper usage of the code. I don't have time to reply to all or your claims, but my lack of a reply to any particular point should not be construed as implicit agreement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 9 juin, 20:43, Russ P. [EMAIL PROTECTED] wrote: (snip argument about s/private/public/g on a whole source tree not being a fork, and not being by far a worse hack than monkeypatching a small specific part of a whole lib - what can I say ?) How about some common sense here. Good question. But for which definition of common sense ? May I remind you that, for a long time, common sense dictated that the earth was flat and at the center of the universe, and that anything heavier than air could by no mean fly ? Or, more recently, that their was a market for at most 5 computers on earth, and that 640kb of RAM ought to be enough for anyone ? If you, the client, are convinced that something declared private should really be public, then perhaps you should contact the developer and explain your reasoning. Indeed. At least something we seem to agree on. If the developer agrees, then the problem is solved. Indeed again. But... But if it takes 6 month to get the mentioned developer to release something I can use, I'm screwed up. Fine. As strange as it might be, I prefer to *first* make it work, *then* contact the developer. And while we're at it: If not, Then I prefer to be able to monkeypatch the code and only maintain my monkeypatch than to have to maintain a whole fork of the original lib. But YMMV of course... then perhaps it is *you*, the client who does not understand the proper usage of the code. Do you really think that I'm fiddling with implementation stuff that may break my code any other release because I don't *understand* that code ? But anyway : even if it happened to be the case, it would still be my own responsability. So what's the matter ? Should we forbid hammers because you could use one to bang your head with ? I don't have time to reply to all or your claims, but my lack of a reply to any particular point should not be construed as implicit agreement. Sounds like a lawyer's notice. Anyway, your lack of agreement won't keep me from happily add implentation attributes to existing objects whenever I find it appropriate. Sorry for being more on the pragmatic side than on the cargo-cult one. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 9, 2:10 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: But if it takes 6 month to get the mentioned developer to release something I can use, I'm screwed up. Fine. I've lost track of how many times I've said this now, but my suggestion for a priv keyword allowed for indirect access to private data through some name-mangling scheme. That could be your temporary fix while you are waiting for the developer to release a corrected version. And even if that option were not available, you could simply open up the relevant source file in the editor of your choice and remove the offending priv declaration. I completely fail to see how you are screwed. Sorry, but when I have to keep repeating the same basic points over and over, I can't help but think I might be wasting my time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 9, 10:23 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Mark Wooding a écrit : Fuzzyman [EMAIL PROTECTED] wrote: So, you are stating that no API programmer using Python *ever* has a valid or genuine reason for wanting (even if he can't have it) genuine 'hiding' of internal state or members from consumers of his (or her...) API? I don't want to speak for whoever you were responding to, but from my point of view... Yes. I understand the difference between the documented interface of a system and the details of its implementation. But sometimes it can be useful to take advantage of implementation details, particularly if the published interface is inadequate in some way. Whether or not I choose to make use of implementation details is a trade-off between immediate convenience and maintainability, but that's something I can make a rational decision about. By enforcing your `data hiding', you're effectively telling me that I'm too stupid to make rational decisions of this sort. And that's actually extremely insulting. I couldn't state it better. +1QOTW btw. By telling me that I can never have a valid reason for wanting 'data hiding' you're effectively telling me that I'm too stupid to make rational decisions of this sort. And that's actually extremely insulting. Fuzzyman http://www.ironpython.info/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Paul Rubin http wrote: This is bogus about 95% of the time though. For the cases where it is really desired, I think it's best to require the target class to be enable it specifically somehow, maybe by inheriting from a special superclass. That could let the compiler statically resolve member lookups the rest of the time. No it wouldn't. Think about multiple inheritance. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Hrvoje Niksic [EMAIL PROTECTED] wrote: How about #define class struct Won't work. Consider `templateclass T ...'. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. [EMAIL PROTECTED] wrote: The idea of being able to discern properties of an object by its name alone is something that is not normally done in programming in general. Really? You obviously haven't noticed Prolog, Smalltalk, Haskell, ML, or Erlang then. And that's just the ones I can think of off the top of my head. * Prolog and Erlang distinguish atoms from variables by the case of the first letter; also `_' is magical and is equivalent to a new variable name every time you use it. * Smalltalk distinguishes between global and local variables according to the case of the first letter. * Haskell distinguishes between normal functions and constructors (both data constructors and type constructors) by the case of the first letter, and has Prolog's `_' convention. * ML allows a single-quote in variable names, but reserves names beginning with a single-quote for type variables. It also has Prolog's `_' convention. As far as I can see, discerning properties of a thing from its name seems relatively common. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Fuzzyman [EMAIL PROTECTED] wrote: So, you are stating that no API programmer using Python *ever* has a valid or genuine reason for wanting (even if he can't have it) genuine 'hiding' of internal state or members from consumers of his (or her...) API? I don't want to speak for whoever you were responding to, but from my point of view... Yes. I understand the difference between the documented interface of a system and the details of its implementation. But sometimes it can be useful to take advantage of implementation details, particularly if the published interface is inadequate in some way. Whether or not I choose to make use of implementation details is a trade-off between immediate convenience and maintainability, but that's something I can make a rational decision about. By enforcing your `data hiding', you're effectively telling me that I'm too stupid to make rational decisions of this sort. And that's actually extremely insulting. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
In article [EMAIL PROTECTED], Mark Wooding [EMAIL PROTECTED] wrote: * Prolog and Erlang distinguish atoms from variables by the case of the first letter; also `_' is magical and is equivalent to a new variable name every time you use it. Can you explain that in more detail? A literal reading of what you wrote would mean that if you did (assuming this is even legal syntax): _ = 1; y = _; the _'s are different variables, which is absurd enough to make me believe I just misunderstood you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
In article [EMAIL PROTECTED], Mark Wooding [EMAIL PROTECTED] wrote: By enforcing your `data hiding', you're effectively telling me that I'm too stupid to make rational decisions of this sort. And that's actually extremely insulting. I think that's taking it a bit far. Python doesn't let you manipulate pointers directly. For example, I can't do: s = foo sp = address(s) sp[2] = 'x' print s and have it print fox. Is this because I'm too stupid to make rational decision of this sort? No, it's because the Python programming model exposes some things and hides others which are deemed inappropriate or too low level. One of the things it hides is direct access to raw memory. I don't see that as fundamentally different from a C++ string class which declares its internal buffer to be private. If the goose's pot is black, then the gander's kettle is an equal shade of dark grey. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
I don't know about Erlang (though I'd think it's behaviour sould be similar to prolog), but at least in Prolog, yes, _ and _ are different variables. The whole idea of _ is that it is a placeholder that can bind to anything, but will be immediately discarded. It's just syntactic sugar so you don't have to create new names for things you don't care about, which could be a problem in prolog (once bound, cannot be bound again on the same branch) or erlang (once bound, bound forever). I just tried on erlang: f(0,_) - 1+_; f(X,_) - X*f(X-1,_). produces an error: ./t.erl:4: variable '_' is unbound ./t.erl:5: variable '_' is unbound (referring to the right side uses of the _ symbol) while the definition: f(0,Y)-1+Y; f(X,Y)-X*f(X-1,Y). produces a [very weird, just for testing purposes, don't use it at home] version of 'factorial'. So, you understood well. As I haven't been following this thread, I won't go offtopic talking about functional languages. But yes, on functional (and declarative?) languages, it makes a lot of sense to have a 'symbol' that represents a new variable any time you use it. Cheers, -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie Quoting Roy Smith [EMAIL PROTECTED]: In article [EMAIL PROTECTED], Mark Wooding [EMAIL PROTECTED] wrote: * Prolog and Erlang distinguish atoms from variables by the case of the first letter; also `_' is magical and is equivalent to a new variable name every time you use it. Can you explain that in more detail? A literal reading of what you wrote would mean that if you did (assuming this is even legal syntax): _ = 1; y = _; the _'s are different variables, which is absurd enough to make me believe I just misunderstood you. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 8, 5:52 am, Mark Wooding [EMAIL PROTECTED] wrote: By enforcing your `data hiding', you're effectively telling me that I'm too stupid to make rational decisions of this sort. And that's actually extremely insulting. 1) I suggest you not take it personally. 2) Local data within functions is hidden. Should you have access to that too? Are you insulted that you don't? 3) I have suggested that indirect or back door access could be provided to private data and methods via some sort of name mangling rule akin to the current rule for leading double underscores. This would provide access in a pinch, but it would make sure the client is aware that he or she or it is accessing private data (and it would do so without leading underscores). 4) My understanding is that most Python software is released or shipped as source code (or at least with the source code included). That means that the client would need only to remove my suggested priv keyword to gain access. Have you ever actually had to use Python software for which you had no access to the source code? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 8, 5:40 am, Mark Wooding [EMAIL PROTECTED] wrote: Russ P. [EMAIL PROTECTED] wrote: The idea of being able to discern properties of an object by its name alone is something that is not normally done in programming in general. Really? You obviously haven't noticed Prolog, Smalltalk, Haskell, ML, or Erlang then. And that's just the ones I can think of off the top of my head. * Prolog and Erlang distinguish atoms from variables by the case of the first letter; also `_' is magical and is equivalent to a new variable name every time you use it. * Smalltalk distinguishes between global and local variables according to the case of the first letter. * Haskell distinguishes between normal functions and constructors (both data constructors and type constructors) by the case of the first letter, and has Prolog's `_' convention. * ML allows a single-quote in variable names, but reserves names beginning with a single-quote for type variables. It also has Prolog's `_' convention. As far as I can see, discerning properties of a thing from its name seems relatively common. Well, common in Prolog, Smalltalk, Haskell, ML, and Erlang is hardly common in general. I'll bet that Java and C/C++ are used more in North Dakota than all those languages combined are used in the entire world. That's not to say they aren't interesting academic languages, of course. As for using the case of the first letter to distinguish between local and global variables, is that just a naming convention or is it actually enforced by the compiler (or interpreter)? If it's actually enforced, that seems rather restrictive to me. What if I want to name a local variable after a proper name or an uppercase acronym? I guess I'm just out of luck. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Sh4wn wrote: data hiding. I know member vars are private when you prefix them with 2 underscores, but I hate prefixing my vars, I'd rather add a keyword before it. Others touched on this, but I thought I'd throw it in here as well since I was just reading about this. Apparently the double underscore convention has nothing to do with data hiding. It's simply a mechanism for avoiding name clashes, and data hiding only *seems* to be a result of it. Not that that helps your situation any. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Well, common in Prolog, Smalltalk, Haskell, ML, and Erlang is hardly common in general. I'll bet that Java and C/C++ are used more in North Dakota than all those languages combined are used in the entire world. I would say python has more in common with the mentioned family than with the C or java families, although I guess it's more in between. Perl, PHP and Ruby all have significant variable names also. It is not that uncommon. 2) Local data within functions is hidden. Should you have access to that too? Are you insulted that you don't? Local data within functions is not hidden. Local data within functions vanish when the function completes. The ability for temporary data is important, and the convention of having functions be temporary keeps things sane. Not quite the same as what this discussion is about. All of the attributes of an object also vanish when the object does... 3) I have suggested that indirect or back door access could be provided to private data and methods via some sort of name mangling rule akin to the current rule for leading double underscores. This would provide access in a pinch, but it would make sure the client is aware that he or she or it is accessing private data (and it would do so without leading underscores). I honestly don't get the strong objection to leading underscores. They are a low-tech way of saying don't touch, which won't muck about with very sticky implementation problems that private attributes would have, potential performance problems etc. They work NOW. Even if priv or some such is in the running to be added to python, it's going to be years. 4) My understanding is that most Python software is released or shipped as source code (or at least with the source code included). That means that the client would need only to remove my suggested priv keyword to gain access. Have you ever actually had to use Python software for which you had no access to the source code? So when someone releases an api doesn't match what I am doing 100%, I should fork the project? This doesn't seem to be a good solution for anybody. And it seems exceptionally dumb to do so just to go through and remove some keywords. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon [EMAIL PROTECTED] wrote: Now of course noone would defend such a limitation on the grounds that one doesn't need the general case and that the general case will only save you some vertical space. But when it came to the ternary operator that was exactly the argument used, to defend the lack of it. As far as I remember, the primary motivation was developers experience with the ternary operator in other languages, especially C, where it was found to hurt readability. At least in my experience, it is much much more common to see the ternary operator making code more obfuscated than easing readability. Time will tell if Python's if-else expression will be abused in the same way. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: expression IF (was: Why does python not have a mechanism for data hiding?)
BJörn Lindqvist wrote: On Wed, Jun 4, 2008 at 2:02 PM, Antoon Pardon [EMAIL PROTECTED] wrote: Now of course noone would defend such a limitation on the grounds that one doesn't need the general case and that the general case will only save you some vertical space. But when it came to the ternary operator that was exactly the argument used, to defend the lack of it. As far as I remember, the primary motivation was developers experience with the ternary operator in other languages, especially C, where it was found to hurt readability. At least in my experience, it is much much more common to see the ternary operator making code more obfuscated than easing readability. Time will tell if Python's if-else expression will be abused in the same way. Expression IF statements are most useful in situations where you can't have multiple statements. In C, that was usually in macros, or occasionally in a function call: printf(Boolean value: %s\n, b ? True : False); was useful, for example. The syntax was probably a bad choice. The classic expression IF (an ALGOL extension) was x := IF b THEN 1 ELSE 0; Surrounded with parentheses, that form could be used in any expression context. Given Python's approach to indentation, conditionals within expressions (and iteration; one could have FOR / YIELD) don't fit the syntax. That's why lambda expressions in Python are so limited. Python already has local functions; you can write: def foo(n) : def bar(m) : print In BAR,n, m bar(n+1) which also allows you to do anything you can do with a lambda expression. You can have control structure, and it reads like ordinary Python. So there's no real need for an expression IF operator. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Someone asked about Java;
class FieldTest {
public String publicString = Foobar;
private String privateString = Hello, World!;
}
import java.lang.reflect.Field;
public class Test4 {
public static void main(String args[]) {
final Field fields[] =
FieldTest.class.getDeclaredFields();
for (int i = 0; i fields.length; ++i) {
System.out.println(Field: + fields[i]);
}
}
}
OUTPUT
Field: public java.lang.String FieldTest.publicString
Field: private java.lang.String FieldTest.privateString
And to edit it;
import java.lang.reflect.Field;
public class Test7 {
public static void main(String args[])
throws Exception {
final Field fields[] =
FieldTest.class.getDeclaredFields();
for (int i = 0; i fields.length; ++i) {
if (privateString.equals(fields[i].getName())) {
FieldTest fieldTest = new FieldTest();
Field f = fields[i];
f.setAccessible(true);
System.out.println(f.get(fieldTest));
f.set(fieldTest, Modified Field);
System.out.println(f.get(fieldTest));
break;
}
}
}
}
OUTPUT
Hello, World!
Modified Field
Enjoy.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : On Jun 4, 4:29 am, NickC [EMAIL PROTECTED] wrote: On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote: What is it about leading underscores that bothers me? To me, they are like a small pebble in your shoe while you are on a hike. Yes, you can live with it, and it does no harm, but you still want to get rid of it. With leading underscores, you can see *at the point of dereference* that the code is accessing private data. With a this is private keyword you have no idea whether you're accessing private or public data, because the two namespaces get conflated together. That is true. But with the priv keyword you'll discover quickly enough that you are trying to access private data (as soon as you run the program). With the current convention, you don't even have to run the program - as soon as you *type* the name, you know you're accessing implementation stuff. And even if a priv keyword is added, you are still free to use the leading underscore convention if you wish. What does this priv keyword buy you then ? Seriously ? The idea of being able to discern properties of an object by its name alone is something that is not normally done in programming in general. Want to talk about the hungarian notation that is everywhere in MS Windows code ?-) or about the so common C++ coding guideline that insists on prefixing data members with a m_ or a w_ ?-) More seriously: yes, you usually try to convey something about some relevant properties of the object in the identifier. Like, you know, using plurals for collections. Or i, j as loop indices. Yes, of course you should choose identifiers to be descriptive of what they represent in the real world, but you don't use names like intCount, floatWeight, or MyClassMyObject would you? Nope. Why not? Because the naming convention for variables is all_lower_with_underscores. Also, because 'count' is likely enough to be an integer and 'weight' likely enough to be a float - and else another numeric. While 'counts' and 'weights' are likely enough to be collections (likely lists) of resp. integers and floats. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : On Jun 5, 4:53 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Russ P. a écrit : Given your very recent discovery of what 'dynamic' *really* means in Python (like, for exemple, dynamically adding / replacing attributes - including methods - on a per-class or per-instance basis), possibly, yes. My very recent discovery? Funny, I thought I knew that several years ago. Looks like I mistook your I also realize, by the way, that Python allows a client of a class to define a new class member from completely outside the class definition as I just realized (...) Sorry for having read too fast. I also realize, by the way, that Python allows a client of a class to define a new class member from completely outside the class definition. Obviously, that cannot be declared private. Why so ? Why should the client of a class not be able to declare a *private* member of the class? You're kidding, right? I'm dead serious. I often add implementation attributes to either a class or an instance. These *are* implementation parts, not API. Do you mind if I tell you how to arrange the furniture in your bedroom? I must be a bit dumb, but I don't see how human interaction problems relate to enforced access restriction in an OO programming language. But if the same identifier is already declared private within the class, than the new definition should not be allowed (because it would defeat the whole idea of private class members). Why so ? Metaprogramming (including monkeypatching) is part of the pythoneer's toolbox, and while it's not something to use without pretty good reasons, it has many times proven to be a real life saver. In languages not allowing it, the solutions to the class of problems easily solved by monkeypatching happens to be at best a kludge, at worst plain unsolvable, at least without too much effort to be even worth it. Your above proposition would arbitrarily make possible and useful things either uselessly complicated or near impossible. For the record, I have made it abundantly clear that I don't think Python should not have as rigorous an encapsulation regime as C++ or Java. The worst that could happen with my proposition is that you would need to use a mangled name to access private data or methods. That's already the case - when you use __name_mangling. And if there's no effective access restriction, then what the point of having this 'priv' keyword ? But you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. Once again, I just don't see the point. Either you want effective access restriction in Python, or you don't. And if you don't, what would this 'priv' keyword be useful to ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : On Jun 5, 2:27 pm, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008 11:36:28 -0700 (PDT), Russ P. [EMAIL PROTECTED] declaimed the following in comp.lang.python: would need to use a mangled name to access private data or methods. But you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. Which will break the first time the innards rebind a value to the mangled name, as the simplified external name will still be bound to the previous value. I'm not sure you understood what I meant. In current Python, if I need access to data element __XX in class YourClass, I can use ZZ._YourClass__XX, but if I don't want to clutter my code with that mangled name, I can just write XX = ZZ._YourClass__XX and refer to it from that point on as XX. Obviously if the meaning of __XX changes within class ZZ, this will break, but that's why you are supposed to avoid using private data in the first place. AFAICT, What Dennis meant is that the binding of ZZ._YourClass__XX changes between the moment you bind it to local XX and the moment you use it, then you're out. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 6, 8:25 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: I also realize, by the way, that Python allows a client of a class to define a new class member from completely outside the class definition. Obviously, that cannot be declared private. Why so ? Why should the client of a class not be able to declare a *private* member of the class? You're kidding, right? I'm dead serious. I often add implementation attributes to either a class or an instance. These *are* implementation parts, not API. If a client accesses a data member of a class, then by definition that member is not really private, so letting the client create a new data member and declare it as private seems a bit silly to me. Actually, just letting the client create the new data member, private or not, seems like a bit of a stretch to me, but I'll leave that be. For the record, I have made it abundantly clear that I don't think Python should not have as rigorous an encapsulation regime as C++ or Java. The worst that could happen with my proposition is that you would need to use a mangled name to access private data or methods. That's already the case - when you use __name_mangling. And if there's no effective access restriction, then what the point of having this 'priv' keyword ? But you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. Once again, I just don't see the point. Either you want effective access restriction in Python, or you don't. And if you don't, what would this 'priv' keyword be useful to ? In the end, I suppose it boils down to aesthetics and personal preference. The leading-underscore convention bothers me for two reasons: (1) like the OP, I don't like the way it makes my code look, and (2) it is a signal to a person reading the code, but it has no actual effect in the interpreter. I think the concept of private data and methods is important enough to be implemented with more than just a tacky naming convention. That is why I suggested the priv keyword. At the same time, I realize that people will occasionally be frustrated if they are rigorously denied access to all private data, which is why I suggested an indirect method of access through mangled names. You can argue that such indirect access defeats the whole idea of private data, but at least it alerts the client to the fact that he (or she or it) is accessing private data -- and it does so without using Hungarian notation. I would let the priv keyword also be used for data or functions at file scope. It just seems logical to me. Again, some name mangling convention could be concocted for those who think they really need access. Actually, the whole objection to denied access baffles me a bit. Does anyone object to not having access from outside a function to local variables within the function? I doubt it. The other thing is that the vast majority of Python software, I would guess, is provided with source code. How many Python applications or libraries are provided without source code? If you have the source code, you can obviously just delete the priv keyword anywhere or everywhere it appears. And if you have a major client who insists on access to all the internals, just delete all occurrences of priv before you ship the code (or don't use it to start with). -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 6, 8:28 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Russ P. a écrit : On Jun 5, 2:27 pm, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008 11:36:28 -0700 (PDT), Russ P. [EMAIL PROTECTED] declaimed the following in comp.lang.python: would need to use a mangled name to access private data or methods. But you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. Which will break the first time the innards rebind a value to the mangled name, as the simplified external name will still be bound to the previous value. I'm not sure you understood what I meant. In current Python, if I need access to data element __XX in class YourClass, I can use ZZ._YourClass__XX, but if I don't want to clutter my code with that mangled name, I can just write XX = ZZ._YourClass__XX and refer to it from that point on as XX. Obviously if the meaning of __XX changes within class ZZ, this will break, but that's why you are supposed to avoid using private data in the first place. AFAICT, What Dennis meant is that the binding of ZZ._YourClass__XX changes between the moment you bind it to local XX and the moment you use it, then you're out. Perhaps I should have stipulated that this should be done only in a local scope and in an application that is not multi-threaded. Then I don't see how you can have a problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Wed, 04 Jun 2008 09:34:58 +, Antoon Pardon wrote: On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: it makes sense to me to also test if they work as documented. If they affect the behaviour of some public component, that's where the documentation should be. As I said they are public themselves for someone. Isn't that contradictory: Public for someone I always thought public meant accessible to virtually anyone. Not to only someone. For the programmer who writes or uses the private API it isn't really private, he must document it or know how it works. How does that make it not private. Private has never meant accessible to noone. And sure he must document it and know how it works. But that documentation can remain private, limited to the developers of the product. It doesn't have to be publicly documented. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Thu, 05 Jun 2008 08:21:41 +, Antoon Pardon wrote: On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Wed, 04 Jun 2008 09:34:58 +, Antoon Pardon wrote: On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: it makes sense to me to also test if they work as documented. If they affect the behaviour of some public component, that's where the documentation should be. As I said they are public themselves for someone. Isn't that contradictory: Public for someone I always thought public meant accessible to virtually anyone. Not to only someone. For the programmer who writes or uses the private API it isn't really private, he must document it or know how it works. How does that make it not private. Private has never meant accessible to noone. And sure he must document it and know how it works. But that documentation can remain private, limited to the developers of the product. It doesn't have to be publicly documented. If the audience is the programmer(s) who implement the private API it is not private but public. Even the public API is somewhat private to a user of a program that uses that API. The public is not virtually anyone here. Depends at which level you look in the system. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-05, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Thu, 05 Jun 2008 08:21:41 +, Antoon Pardon wrote: On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Wed, 04 Jun 2008 09:34:58 +, Antoon Pardon wrote: On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: it makes sense to me to also test if they work as documented. If they affect the behaviour of some public component, that's where the documentation should be. As I said they are public themselves for someone. Isn't that contradictory: Public for someone I always thought public meant accessible to virtually anyone. Not to only someone. For the programmer who writes or uses the private API it isn't really private, he must document it or know how it works. How does that make it not private. Private has never meant accessible to noone. And sure he must document it and know how it works. But that documentation can remain private, limited to the developers of the product. It doesn't have to be publicly documented. If the audience is the programmer(s) who implement the private API it is not private but public. Even the public API is somewhat private to a user of a program that uses that API. The public is not virtually anyone here. Depends at which level you look in the system. I think there is a general consensus about on what level to look when we are talking about private and public attributes. You can of course start talking at a whole different level and as such use these words with a meaning different than normally understood. But that will just make it harder for you to get your ideas accross. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Antoon Pardon a écrit : On 2008-06-04, NickC [EMAIL PROTECTED] wrote: On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote: What is it about leading underscores that bothers me? To me, they are like a small pebble in your shoe while you are on a hike. Yes, you can live with it, and it does no harm, but you still want to get rid of it. With leading underscores, you can see *at the point of dereference* that the code is accessing private data. @NickC : InMyArms(tm) ! But the leading underscore doesn't tell you whether it is your own private date, which you can use a you see fit, or those of someone else, which you have to be very carefull with. That's why we have __name_mangling too. Consider '_' as 'protected' and '__' as private. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. a écrit : (snip) (answering to Carl Bank) I thought you were saying that encapsulation or so-called data hiding is worthless. As far as I'm concerned, I view encapsulation as very desirable, and data-hidding as totally worthless when applied to Python's object model. Here's what I think Python should have. I think it should have a keyword, something like priv, to identify data or functions as private. As I said earlier, private for class data or functions (methods) could be implemented like protected in C++. That means that derived classes would have access to it, but clients of the class would not. If the client really needs or wants access, he could be given a sort of back door access similar to the current Python rule regarding double leading underscores. Thus, the client would have access, but he would know very well that he is using something that the original designer did not intend for him to use. It's just a suggestion. I'm not a language expert, and I realize that I could be missing something important. Given your very recent discovery of what 'dynamic' *really* means in Python (like, for exemple, dynamically adding / replacing attributes - including methods - on a per-class or per-instance basis), possibly, yes. I also realize, by the way, that Python allows a client of a class to define a new class member from completely outside the class definition. Obviously, that cannot be declared private. Why so ? But if the same identifier is already declared private within the class, than the new definition should not be allowed (because it would defeat the whole idea of private class members). Why so ? Metaprogramming (including monkeypatching) is part of the pythoneer's toolbox, and while it's not something to use without pretty good reasons, it has many times proven to be a real life saver. In languages not allowing it, the solutions to the class of problems easily solved by monkeypatching happens to be at best a kludge, at worst plain unsolvable, at least without too much effort to be even worth it. Your above proposition would arbitrarily make possible and useful things either uselessly complicated or near impossible. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 3, 6:54 pm, sturlamolden [EMAIL PROTECTED] wrote: On May 24, 3:41 pm, Sh4wn [EMAIL PROTECTED] wrote: first, python is one of my fav languages, and i'll definitely keep developing with it. But, there's 1 one thing what I -really- miss: data hiding. I know member vars are private when you prefix them with 2 underscores, but I hate prefixing my vars, I'd rather add a keyword before it. Python has no data hiding because C++ has (void *). Python underscores does some name mangling, but does not attempt any data hiding. Python and C has about the same approach to data hiding. It is well tried, and works equally well in both languages: # this is mine, keep your filthy paws off!!! Irresponsible programmers should not be allowed near a computer anyway. If you use data hiding to protect your code from yourself, what you really need is some time off to reconsider your career. So, you are stating that no API programmer using Python *ever* has a valid or genuine reason for wanting (even if he can't have it) genuine 'hiding' of internal state or members from consumers of his (or her...) API? Michael Foord http://www.ironpythoninaction.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 5, 3:26 pm, Fuzzyman [EMAIL PROTECTED] wrote: So, you are stating that no API programmer using Python *ever* has a valid or genuine reason for wanting (even if he can't have it) genuine 'hiding' of internal state or members from consumers of his (or her...) API? Michael Foordhttp://www.ironpythoninaction.com/ If you are an API programmer, the __all__ attribute of a package or module provides all the internal data hiding you need. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 5, 4:47 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Antoon Pardon a écrit : On 2008-06-04, NickC [EMAIL PROTECTED] wrote: On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote: What is it about leading underscores that bothers me? To me, they are like a small pebble in your shoe while you are on a hike. Yes, you can live with it, and it does no harm, but you still want to get rid of it. With leading underscores, you can see *at the point of dereference* that the code is accessing private data. @NickC : InMyArms(tm) ! But the leading underscore doesn't tell you whether it is your own private date, which you can use a you see fit, or those of someone else, which you have to be very carefull with. That's why we have __name_mangling too. Consider '_' as 'protected' and '__' as private. Only in some vague, fuzzy sense. My understanding is that the single underscore in a class definition is a convention only and has no actual effect whatsoever. In C++ (and Java?), on the other hand, the protected keyword *really* prevents the client from accessing the data or method, but it allows access to derived classes. The private keyword goes further and prevents access even by derived classes. The double leading underscore in Python does no such thing. By the way, people often claim that friend classes in C++ violate encapsulation. That is a common misunderstanding. They do not violate encapsulation because a class must declare its own friends. In other words, the determination of who gets acces to the private data in a class is determined within the class itself. Declaring another class a friend gives it access to your data but does not give you access to its data. (At least that's my recollection, though I haven't used C++ for several years.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 5, 2:07 pm, Russ P. [EMAIL PROTECTED] wrote: The private keyword goes further and prevents access even by derived classes. The double leading underscore in Python does no such thing. Who develops these derived classes ? A competitor ? A malicious hacker ? A spammer ? Who are you trying to hide your precious classes from that the double leading underscore is not good enough protection ? Even with a 'private' keyword, what stops them from doing s/private/public/g ? Seriously, the underscores are ugly argument has some merit but language enforced data hiding is overrated, if not downright silly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 5, 4:53 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Russ P. a écrit : Given your very recent discovery of what 'dynamic' *really* means in Python (like, for exemple, dynamically adding / replacing attributes - including methods - on a per-class or per-instance basis), possibly, yes. My very recent discovery? Funny, I thought I knew that several years ago. You must know more about me than I know about myself. I also realize, by the way, that Python allows a client of a class to define a new class member from completely outside the class definition. Obviously, that cannot be declared private. Why so ? Why should the client of a class not be able to declare a *private* member of the class? You're kidding, right? Do you mind if I tell you how to arrange the furniture in your bedroom? But if the same identifier is already declared private within the class, than the new definition should not be allowed (because it would defeat the whole idea of private class members). Why so ? Metaprogramming (including monkeypatching) is part of the pythoneer's toolbox, and while it's not something to use without pretty good reasons, it has many times proven to be a real life saver. In languages not allowing it, the solutions to the class of problems easily solved by monkeypatching happens to be at best a kludge, at worst plain unsolvable, at least without too much effort to be even worth it. Your above proposition would arbitrarily make possible and useful things either uselessly complicated or near impossible. For the record, I have made it abundantly clear that I don't think Python should not have as rigorous an encapsulation regime as C++ or Java. The worst that could happen with my proposition is that you would need to use a mangled name to access private data or methods. But you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 5, 11:25 am, George Sakkis [EMAIL PROTECTED] wrote: On Jun 5, 2:07 pm, Russ P. [EMAIL PROTECTED] wrote: The private keyword goes further and prevents access even by derived classes. The double leading underscore in Python does no such thing. Who develops these derived classes ? A competitor ? A malicious hacker ? A spammer ? Who are you trying to hide your precious classes from that the double leading underscore is not good enough protection ? Even with a 'private' keyword, what stops them from doing s/private/public/g ? Seriously, the underscores are ugly argument has some merit but language enforced data hiding is overrated, if not downright silly. I did not claim that Python should have the same encapsulation rules as C++. I was merely comparing the two in reply to a post that claimed a similarity. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
For the record, I have made it abundantly clear that I don't think Python should not have as rigorous an encapsulation regime as C++ or Java. The worst that could happen with my proposition is that you would need to use a mangled name to access private data or methods. But you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. Let me try that again: For the record, I have made it abundantly clear that I don't think Python should have as rigorous an encapsulation regime as C++ or Java. The worst that could happen with my proposition is that you would need to use a mangled name to access private data or methods. But if you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 5 juin, 20:07, Russ P. [EMAIL PROTECTED] wrote: On Jun 5, 4:47 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: Antoon Pardon a écrit : On 2008-06-04, NickC [EMAIL PROTECTED] wrote: On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote: What is it about leading underscores that bothers me? To me, they are like a small pebble in your shoe while you are on a hike. Yes, you can live with it, and it does no harm, but you still want to get rid of it. With leading underscores, you can see *at the point of dereference* that the code is accessing private data. @NickC : InMyArms(tm) ! But the leading underscore doesn't tell you whether it is your own private date, which you can use a you see fit, or those of someone else, which you have to be very carefull with. That's why we have __name_mangling too. Consider '_' as 'protected' and '__' as private. Only in some vague, fuzzy sense. My understanding is that the single underscore in a class definition is a convention only and has no actual effect whatsoever. It has the expected effect: warn adult programmers that this is implementation, not interface, so mess with it and you're on your own. In C++ (and Java?), on the other hand, the protected keyword *really* prevents the client from accessing the data or method, but it allows access to derived classes. And ? The private keyword goes further and prevents access even by derived classes. And ? The double leading underscore in Python does no such thing. No. It only make sure a child class won't *accidentally* mess things up. And that's enough as far as I'm concerned. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
In article
[EMAIL PROTECTED],
Russ P. [EMAIL PROTECTED] wrote:
In C++ (and
Java?), on the other hand, the protected keyword *really* prevents
the client from accessing the data or method, but it allows access to
derived classes. The private keyword goes further and prevents
access even by derived classes.
In C++, it does no such thing. Consider this class declaration in
MySecretClass.h:
class MySecretClass {
private:
int foo;
};
All somebody has to do to get at the private data is:
#define private public
# include MySecretClass.h
#undef private
If playing preprocessor games isn't your thing, there's a whole multitude
of other tricks you can play with pointers and typecasts that will get you
access to foo in other ways.
But, you protest, you're not supposed to do that! Well, of course not.
But you're not supposed to ignore the leading underscore convention in
Python either. That's the nice thing about freedom of religion; you get to
pick which particular sins you want to get freaked out about.
I'm pretty weak on Java, but my understanding is that it's in better shape
here, since it has neither textual inclusion of header files, nor pointers.
You might have to resort to JNI :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 5, 12:20 pm, Roy Smith [EMAIL PROTECTED] wrote: All somebody has to do to get at the private data is: #define private public # include MySecretClass.h #undef private Well, that shows the weakness of the C/C++ header files. The include directive merely does a simple text substitution, which is pretty lame as far as I am concerned. As you say, Java has moved beyond that, and Ada has always been more sophisticated than that. By the way, my recollection is that in C++ access defaults to private if nothing is declared explicity. So normally the private declaration is unnecessary. If it is left out, your little trick won't work. But your point is still valid. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. wrote: On Jun 2, 5:11 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: Russ P. [EMAIL PROTECTED] writes: I also realize, by the way, that Python allows a client of a class to define a new class member from completely outside the class definition. Obviously, that cannot be declared private. This is bogus about 95% of the time though. For the cases where it is really desired, I think it's best to require the target class to be enable it specifically somehow, maybe by inheriting from a special superclass. That could let the compiler statically resolve member lookups the rest of the time. It did seem a bit odd to me when I realized that you can add data members (or even a methods) to a class from completely outside the class definition. That can be risky, of course, and as you suggest, perhaps it shouldn't even be allowed by default. I usually find that it's safer to initialize in the constructor all (or nearly all) of the data members that will be needed in a class. If I need a list that will be populated later, for example, I reserve the name with an empty list in the constructor. Then, if for some reason the list gets accessed before it is populated, I don't get an exception. That is EXACTLY when I want an exception, I did something that shouldn't happen. You also are missing the nice ability of python to use hasattr() to find out if a class instance has a method/attribute. I use hasattr() to test for presence or absence of methods/attributes quite a lot. In the past I did what you describe, but found that to be limiting and a throwback to when I used languages that could not do introspection. I can test to see if the attribute exists, if it is empty, which can be two very different conditions that require two different actions. The only way you can do that is to initialize it to None. While this works it is a fictitious construct that we all learned when we were writing Fortran, Basic or Cobol years ago (oops I think I just revealed that I'm an 'old timer'). Now I just do: if hasattr(self, 'listInQuestion') and I can tell if it has been created (either by constructor) or by some other method. This works particularly well when I do caching of data in objects that are shared among methods. I can also do hasattr(object, 'methodInQuestion') to see if the object implements an interface that I require. May be a little off topic, but I think it is relevant. -Larry -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
2008/6/5 Russ P. [EMAIL PROTECTED]: On Jun 5, 12:20 pm, Roy Smith [EMAIL PROTECTED] wrote: All somebody has to do to get at the private data is: #define private public # include MySecretClass.h #undef private Well, that shows the weakness of the C/C++ header files. The include directive merely does a simple text substitution, which is pretty lame as far as I am concerned. As you say, Java has moved beyond that, and Ada has always been more sophisticated than that. By the way, my recollection is that in C++ access defaults to private if nothing is declared explicity. So normally the private declaration is unnecessary. If it is left out, your little trick won't work. But your point is still valid. And also #define class struct #include something.h #undef class ;) Matthieu -- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Wed, Jun 4, 2008 at 2:54 PM, Roy Smith [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: By definition, private functions are not part of the publicly documented behaviour of the unit. Any behaviour exhibited by some private component is seen externally as a behaviour of some public component. You know the difference between theory and reality? In theory, there is none... Sometimes it's useful to test internal components. Imagine this class: class ArmegeddonMachine: def pushTheButton(self): Destroy a random city city = self._pickCity() self._destroy(city) def _pickCity(): cities = ['New York', 'Moscow', 'Tokyo', 'Beijing', 'Mumbai'] thePoorSchmucks = random.choice(cities) return 'New York' def _destroy(self, city): missle = ICBM() missle.aim(city) missle.launch() The only externally visible interface is pushTheButton(), yet you don't really want to call that during testing. What you do want to do is test that a random city really does get picked. You can do one of two things at this point. You can say, But, that's not part of the externally visible interface and refuse to test it, or you can figure out a way to test it. Up to you. -- http://mail.python.org/mailman/listinfo/python-list Sorry for the long post in advance. I'm busy studying unit testing、and here is how I would go about testing the above code. 1) Make the code more testable through public (not private) interfaces. ie, split out the functionality into more public, but still properly encapsulated forms (modules/classes, etc). Don't need to make everything public, just enough that it's testable without digging into privates attributes, but still well-encapsulated. 2) Link the split-up logic together (eg, in class constructors). Use public attributes for this. Or use private attributes, but make them updatable through public methods. 3) In the unit tests update the object being tested, so it uses mock objects instead of the ones it uses by default (aka dependency injection). 4) Run the methods to be tested, and check that the mock objects were updated correctly. Here is an example (very rough, untested incomplete): # Updated armageddonmachine module: class CityPicker: def pick(self): cities = ['New York', 'Moscow', 'Tokyo', 'Beijing', 'Mumbai'] thePoorSchmucks = random.choice(cities) return 'New York' # Your bug is still here class Destroyer: def destroy(self, city): missle = ICBM() missle.aim(city) missle.launch() class ArmegeddonMachine: def __init__(self): self.city_picker = CityPicker() self.destroyer = Destroyer() def pushTheButton(self): Destroy a random city city = self.city_picker.pick() self.destroyer.destroy(city) # unit test module for armageddonmachine # Only has tests for CityPicker and ArmageddonMachine import armageddonmachine # Unit test code for CityPicker # -- Mock objects -- class MockRandom: def __init__(self): self.choose = None def choice(self, list_): assert self.choose is not None return list_[self.choose] class TestCityPicker: def setup() # Setup code run before each unit test in this class self.city_picker = CityPicker() self._bkp_random = armaggedonmachine.random def teardown() # Teardown code run after each unit test in this class armaggedonmachine.random = self._bkp_random def test_should_pick_random_cities_correctly(self): armaggedonmachine.random = MockRandom() armaggedonmachine.choose = 0 assert city_picker.pick() == 'New York' armaggedonmachine.choose = 1 assert city_picker.pick() == 'Moscow' # This will catch your bug armaggedonmachine.choose = 2 assert city_picker.pick() == 'Tokyo' armaggedonmachine.choose = 3 assert city_picker.pick() == 'Beijing' armaggedonmachine.choose = 4 assert city_picker.pick() == 'Mumbai' # Unit test code for ArmageddonMachine # -- Mock Classes -- class MockCityPicker: def __init__(self): self.city_to_pick = Test City def pick(self): return self.city_to_pick class MockDestroyer: def __init__(self): self.destroyed_cities = set() def destroy(self, city): self.destroyed_cities.append(city) # -- Unit Tests class TestArmageddonMachine: def setup(self): # Setup code that runs before each unit test in this class self.machine = ArmageddonMachine() self._bkp_picker = self.machine.city_picker self._bkp_destroyer = self.machine.destroyer self.machine.city_picker = MockCityPicker() self.machine.destroyer = MockCityDestroyer() def test_should_destroy_a_city(self): self.machine.pushTheButton() assert self.machine.destroyer.destroyed_cities == Test City -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Russ P. [EMAIL PROTECTED] writes: By the way, my recollection is that in C++ access defaults to private if nothing is declared explicity. So normally the private declaration is unnecessary. If it is left out, your little trick won't work. How about #define class struct -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Roy Smith [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: Then what you're really testing is the interactions of the push the button function with its external interface: you're asserting that the push the red button function actually uses the result from pick a random city as its target. No, that's not what I'm testing at all. I want to test that the cities really do get picked randomly. Then you need to make a design decision, by *specifying* that expected behaviour in some public API. Either pick a random city is public API with the expected behaviour that it will return a random city from a publicly-specified list of cities; or the push the button function has some externally-verifiable target that is specified. If the behaviour you describe isn't part of the specified API, then it *doesn't matter* how the city gets picked (i.e. it's an internal implementation detail); selecting New York every time doesn't go against any description of the behaviour of the application, so it's not a bug, but an internal implementation detail that doesn't deserve to be unit tested. If you want always chooses the same city to be a bug, then you are specifying some externally-expected behaviour of the application code, and that expectation needs to be specified in such a way that you can make an automated assertion about it in a unit test. Once you've decided which public API is specified as providing that behaviour, that's the point at which the unit test should be asserting that behaviour. -- \Know what I hate most? Rhetorical questions. -- Henry N. Camp | `\ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 5, 2:27 pm, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008 11:36:28 -0700 (PDT), Russ P. [EMAIL PROTECTED] declaimed the following in comp.lang.python: would need to use a mangled name to access private data or methods. But you will be using the name many times, you can reassign your own name, of course, so the mangled name need not appear more than once where it is needed. Which will break the first time the innards rebind a value to the mangled name, as the simplified external name will still be bound to the previous value. I'm not sure you understood what I meant. In current Python, if I need access to data element __XX in class YourClass, I can use ZZ._YourClass__XX, but if I don't want to clutter my code with that mangled name, I can just write XX = ZZ._YourClass__XX and refer to it from that point on as XX. Obviously if the meaning of __XX changes within class ZZ, this will break, but that's why you are supposed to avoid using private data in the first place. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 5, 2:57 pm, Hrvoje Niksic [EMAIL PROTECTED] wrote: Russ P. [EMAIL PROTECTED] writes: By the way, my recollection is that in C++ access defaults to private if nothing is declared explicity. So normally the private declaration is unnecessary. If it is left out, your little trick won't work. How about #define class struct I never thought of that one. I wonder what the C++ gurus would say about that. Let me guess. They'd probably say that the access restrictions are for your own good, and bypassing them is bound to do you more harm than good in the long run. And they'd probably be right. Just because you can break into a box labeled DANGER HIGH VOLTAGE, that doesn't make it a good idea. This just goes to show that the whole idea of using header files as simple text insertions is flaky to start with, and adding the preprocessor just compounds the flakiness. Needless to say, I'm not a big fan of C and C++. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes: On Wed, 04 Jun 2008 13:50:42 +1000, Ben Finney wrote: It seems you [alex23] have a different idea of what unit testing is for from me. For me it's about finding bugs where documentation and implementation disagree. Where documentation is specified externally-visible behaviour of the unit, I agree with this. And if you document private functions By definition, private functions are not part of the publicly documented behaviour of the unit. Any behaviour exhibited by some private component is seen externally as a behaviour of some public component. it makes sense to me to also test if they work as documented. If they affect the behaviour of some public component, that's where the documentation should be. If they *don't* affect the external behaviour, then they shouldn't be there :-) Or, at least, their behaviour shouldn't be asserted as part of the tests of external behaviour. Because the official API relies on the correct implementation of the private parts it uses under the hood. Only to the extent that the documented behaviour of the API is affected. The main benefit of marking something as not public is that one *is* free to change its behaviour, so long as the public API is preserved. One part of writing unit tests is invoking functions with arguments that you think are corner cases. For example test if a function that takes a list doesn't bomb out when you feed the empty list into it. Or if it handles all errors correctly. This sounds like part of the externally-visible behaviour of the code unit; i.e. something that belongs in the public API. I agree that this is the domain of a unit test. If a function `f()` calls internally `_g()` and that function might even call other private functions, then you have to know how `f()` works internally to create input that checks if error handling in `_g()` works correctly. No, you don't need to know how it works internally; you need only know what guarantees it must keep for its external behaviour. If someone wants to alter the `_g()` function, or remove it entirely while preserving the correct behaviour of `f()`, that should have no effect on the external behaviour of `f()`. That is to say, the knowledge of the internals of `f()` in your example is actually knowledge of something that should be documented as part of the external behaviour of `f()` — that, or it's not relevant to the behaviour of `f()` and shouldn't be unit tested in order that encapsulation is preserved. What do you do in such a situation? Build something from untested private parts and just test the assembled piece? Assert the corner-case behaviour of `f()`, through unit tests that operate on `f()` without caring about its internals. I prefer to test the private functions too. After all the private functions are not private to the everybody, there *are* functions that rely on them working correctly. Then for *those* interfaces, unit tests can be devised that make assertions about those interfaces. -- \ [T]he speed of response of the internet will re-introduce us | `\to that from which our political systems have separated us for | _o__) so long, the consequences of our own actions. -- Douglas Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-03, Lie [EMAIL PROTECTED] wrote: Python has an extremely good design because the BDFL doesn't just listen to everyone and create a product that tries to please everybody, no, he listens to those that have good ideas and tells the stupid ideas to go away and he applies a subjective decision which more often than not leads to a better python. I agree that Guido van Rossum has done an excellent job. That doesn't mean he has to be painted as unfailable in which the ideais he accepts are good ideas and those he rejects are bad ideas almost by definition. Guido has been known to change his mind, which is an admirabele quality, but it does show that at some point he rejected a good idea or accepted a bad idea. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-03, sturlamolden [EMAIL PROTECTED] wrote: On Jun 2, 12:40 pm, Antoon Pardon [EMAIL PROTECTED] wrote: I think you completed missed the point. This is just a proof of concept thing. In a real example there would of course no Set en Get methods but just methods that in the course of their execution would access or update the hidden attributes I have to agree with Banks here, you have not provided an example of data hiding. It does not discriminate between attribute access from within and from outside the class. You just assume that the attribute named 'hidden' will be left alone. Also naming it hidden is stupid as it is visible. No I don't assume that hidden wil be left alone. hidden is a free variable in a closure and thus simply can't be accessed except by local functions that were made accessible (and some mechanism dependant on the CPython implementation). What you need is a mechanism that will thrown an exception whenever an attribue is accessed from outside the class, but not from inside. And my example does this. It threw an AttributeError The mechanism must also be impossible to override with additional code. Which as far as I know it is. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Wed, 04 Jun 2008 15:55:38 +1000, Ben Finney wrote: Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes: On Wed, 04 Jun 2008 13:50:42 +1000, Ben Finney wrote: It seems you [alex23] have a different idea of what unit testing is for from me. For me it's about finding bugs where documentation and implementation disagree. Where documentation is specified externally-visible behaviour of the unit, I agree with this. And if you document private functions By definition, private functions are not part of the publicly documented behaviour of the unit. Any behaviour exhibited by some private component is seen externally as a behaviour of some public component. But only indirectly, and it's often harder to predict the corner cases that might trigger bugs or to test error testing in dependent private functions. Private functions offer an API that's public to someone, so they ought to be documented and tested. it makes sense to me to also test if they work as documented. If they affect the behaviour of some public component, that's where the documentation should be. As I said they are public themselves for someone. Because the official API relies on the correct implementation of the private parts it uses under the hood. Only to the extent that the documented behaviour of the API is affected. The main benefit of marking something as not public is that one *is* free to change its behaviour, so long as the public API is preserved. One more reason to test the individual private functions because a change of such a function shouldn't make it necessary to change the unit tests of the public API. One part of writing unit tests is invoking functions with arguments that you think are corner cases. For example test if a function that takes a list doesn't bomb out when you feed the empty list into it. Or if it handles all errors correctly. This sounds like part of the externally-visible behaviour of the code unit; i.e. something that belongs in the public API. I agree that this is the domain of a unit test. If a function `f()` calls internally `_g()` and that function might even call other private functions, then you have to know how `f()` works internally to create input that checks if error handling in `_g()` works correctly. No, you don't need to know how it works internally; you need only know what guarantees it must keep for its external behaviour. How do you know the corner cases then? Often it is interesting how a function that takes integers copes with zero, so that might be a test. It's easy if you test a function directly but you need to know the internals if you must find arguments that lead to a dependent function called with zero. Contrived example: def _g(i): return (42 / i) if i else 0 def f(x): return _g(x + 23) Here ``f(-23)`` is a special corner case that should be tested somehow. And I think it is better tested as explicit test of `_g()` than with a test of `f()`. Testing for corner cases needs some knowledge about the implementation, but that shouldn't be transitive. The tests for `f()` should assume that `_g()` itself has promised in its documentation was already covered by a unit test. If someone wants to alter the `_g()` function, or remove it entirely while preserving the correct behaviour of `f()`, that should have no effect on the external behaviour of `f()`. That is to say, the knowledge of the internals of `f()` in your example is actually knowledge of something that should be documented as part of the external behaviour of `f()` — that, or it's not relevant to the behaviour of `f()` and shouldn't be unit tested in order that encapsulation is preserved. `f()`'s documentation should mention that it works for all integers including -23 with -23 explicitly mentioned? What do you do in such a situation? Build something from untested private parts and just test the assembled piece? Assert the corner-case behaviour of `f()`, through unit tests that operate on `f()` without caring about its internals. And this way missing many potential bugs? I prefer to test the private functions too. After all the private functions are not private to the everybody, there *are* functions that rely on them working correctly. Then for *those* interfaces, unit tests can be devised that make assertions about those interfaces. Now you lost me. So essentially you don't test private functions unless they are used somewhere, then they should be tested too. As private functions that are not used, shouldn't be there in the first place, every function private or public should be tested, right!? Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: it makes sense to me to also test if they work as documented. If they affect the behaviour of some public component, that's where the documentation should be. As I said they are public themselves for someone. Isn't that contradictory: Public for someone I always thought public meant accessible to virtually anyone. Not to only someone. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On May 26, 7:32 am, Joe P. Cool [EMAIL PROTECTED] wrote: I saw this don't need it pattern in discussions about the ternary if..else expression and about except/finally on the same block level. Now Python has both. if/else was added solely because people kept coming up with ways of embedding a pseudo conditional inside expressions and writing buggy code in the process. All it really saves you in practice is a bit of vertical whitespace, so, no, you still don't need it - but if you insist on doing it, at least there's now an easy way to do it correctly. except/finally on the same block level was trivial to implement once the reference interpreter switched to an AST based compiler for 2.5. If you look at the AST, you'll find that it still only has TryExcept and TryFinally, so again, you still don't need except/finally on the same block level - all the syntax allows you to do is omit the second try: line and its associated indentation. Actually it is very useful to be able to distinguish between inside and outside. This is obvious for real world things e.g. your TV. Nobody likes to open the rear cover to switch the channel. Similar arguments apply to software objects. data hiding is a harsh name, I would call it telling what matters. The need for this becomes indispensable in really big software packages like the Eclipse framework with approx. 10 classes. If you cannot tell the difference between inside and outside you are lost. In Python, the philosophy we're all consenting adults here applies. Please don't sell a missing feature as a philosophy. Say you don't need/want it. But don't call it philosophy. Gosh, and here I thought treating programmers as non-idiots was actually one of the guiding philosophies in the discussion on python- dev. Good thing we have you here to tell us we're only imagining that. You shouldn't pretend to know, at the time you write it, all the uses to which your code will be put. It's *your* *decision* which uses will be available. Your explanation appears to me as a fear to decide. Are you writing application code or library code? For application code, you have a much greater idea of the uses for your code, so you can be confident in your decision as to what should and should not be visible. For library code, however, it's fairly common for a library to provide something which is almost, but not quite, what the user needs. Letting users poke around at their own risk is a nice courtesy that can save them a lot of work in the long run. So the decision to hide something is still made (by using an underscore prefix), but an easy mechanism is provided for the library user to override that decision. If you want the users of your code to know that an attribute should not be used as a public API for the code, use the convention of naming the attribute with a single leading underscore. Littering your class definition with dozens of underscores is exactly the line noise we love to criticize in Perl. Using underscores in names (leading or otherwise) separated by plaintext keywords is a far cry from multiple different symbols that mean different things in different contexts and can be chained together fairly arbitrarily. Python advertises himself as a full OOP language, but why does it miss one of the basic principles of OOP? Who taught you that enforced restrictions on attribute access was a basic principle of OO? Nearly every introduction to OOP? Please don't tell me that encapsulation does not mean enforced restriction. If the language has no syntactic support for encapsulation then it does not have encapsulation. Module globals aren't visible outside the module without importing it. Class attributes aren't visible outside the class without derefencing it. Instance attributes aren't visible outside an instance without deferencing one. *That* is the encapsulation/data hiding which OOP requires, and is the kind which Python enforces. What you're asking for is encapsulation of class and instance attributes based on the context in which the dereferencing occurs (inside the class, inside a subclass of that class, inside an instance of that class, inside an instance of a subclass of that class, somewhere else entirely), and that has nothing to do with the basics of OOP. On the other hand, if you're so keen on this feature, perhaps you'd like to make a concrete proposal regarding how you would like the semantics to work in light of Python dynamic typing model. What will it do when a method is invoked via the class dict rather than via attribute retrieval? Can unbound methods access protected or private attribute? How about descriptor get, set and delete methods? What happens when a function is added to a class definition after creation as a new method? Cheers, Nick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On May 26, 2:49 pm, Russ P. [EMAIL PROTECTED] wrote: I am also bothered a bit by the seeming inconsistency of the rules for the single underscore. When used at file scope, they make the variable or function invisible outside the module, but when used at class scope, the underscored variables or functions are still fully visible. For those who claim that the client should be left to decide what to use, why is the client prohibited from using underscored variables at file scope? They aren't - the only thing that won't see the underscore prefixed names is from x import *. If you do import x instead, all the underscored names will be accessible as attributes of the module. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
NickC [EMAIL PROTECTED] writes: if/else was added solely because people kept coming up with ways of embedding a pseudo conditional inside expressions and writing buggy code in the process. All it really saves you in practice is a bit of vertical whitespace, so, no, you still don't need it - but if you insist on doing it, at least there's now an easy way to do it correctly. Come on, it's more than vertical whitespace, it's extraneous variables and sometimes even extraneous functions and function call overhead. And Python is supposed to be unbureaucratic. People kept looking for ways to write conditional expressions instead of spewing the logic across multiple statements for a reason: the code is often cleaner that way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote: What is it about leading underscores that bothers me? To me, they are like a small pebble in your shoe while you are on a hike. Yes, you can live with it, and it does no harm, but you still want to get rid of it. With leading underscores, you can see *at the point of dereference* that the code is accessing private data. With a this is private keyword you have no idea whether you're accessing private or public data, because the two namespaces get conflated together. I'll keep my pebble, thanks. Cheers, Nick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On May 25, 8:01 pm, Fuzzyman [EMAIL PROTECTED] wrote: Python was not really written with 'difficult' customers in mind ;-) True. It's extremely suited to what we do though.Minor difficulties like this are vastly outweighed by advantages. The difficulties are real though. It's interesting to take a look at some of the work Brett Cannon has done trying to come up with a sandbox for executing Python code that actually manages to block access to dangerous functions like file() or urllib.urlopen(). Powerful introspection capabilities and restricted access to methods and attributes don't really play well together. http://svn.python.org/view/python/branches/bcannon-objcap/securing_python.txt?rev=55685view=markup (I believe that work is on hiatus while he's been busy with other projects, such as a more flexible Python-based reimplementation of the import mechanism that would be make it possible to implement the security restrictions needed to permit limited imports in a sandboxed interpreter) One could largely hide private vars with a program that substituted random names for single _ names, and removed the doc strings for functions, classes, and methods with such names. We need to *use* those names to display the spreadsheet once the calculation has finished (and their code has run). Such a program could even put such names in a separate module imported as '_private_do_not_use_'. Splitting more of the functionality out is probably part of the best solution. Yeah, at this point your only hope is going to be making them go through such wild contortions to get at the internal data they think better of it. Actually blocking all access to something written in Python is fairly tough (you generally need an extension class written in non-Python code that hides access to certain attributes). Cheers, Nick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 4, 4:41 pm, Antoon Pardon [EMAIL PROTECTED] wrote: Guido has been known to change his mind, which is an admirabele quality, but it does show that at some point he rejected a good idea or accepted a bad idea. And sometimes the person that talked him into accepting the bad idea in the first place ends up agreeing with him when he eventually rejects it ;) Cheers, Nick. P.S. Read the list of references in PEP 343 if you want to know what I'm talking about *cough* -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes: On Wed, 04 Jun 2008 15:55:38 +1000, Ben Finney wrote: By definition, private functions are not part of the publicly documented behaviour of the unit. Any behaviour exhibited by some private component is seen externally as a behaviour of some public component. But only indirectly No, that's the point: externally, such behaviour is exhibited by the public API. Whatever internal moving parts actually lead to the behaviour doesn't make any difference: it's the external behaviour that's being discussed in the above. and it's often harder to predict the corner cases that might trigger bugs or to test error testing in dependent private functions. Indeed. The person writing the unit tests should do so with full knowledge of what the implementation looks like. This allows coverage of those corner cases you rightly point out exist in many implementations. Those unit tests should *not*, though, exercise anything but the public API, otherwise they're breaking encapsulation. Their assertion should continue to be just as true after a refactoring of the internal components as before. Private functions offer an API that's public to someone, so they ought to be documented and tested. No, that's pretty much the point: private functions are intended for use by nothing except other functions at the same scope. If they're to be used in other contexts, they're public API, not private. It's a feature of Python that such bad API design doesn't lead to hideous workarounds: one can still easily get at the parts of an API that the programmer mistakenly marked private. That doesn't make it any less a mistake to break encapsulation, but it does make it much more easily fixed. -- \ During the Middle Ages, probably one of the biggest mistakes | `\ was not putting on your armor because you were 'just going down | _o__) to the corner.' -- Jack Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 4, 9:24 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: NickC [EMAIL PROTECTED] writes: if/else was added solely because people kept coming up with ways of embedding a pseudo conditional inside expressions and writing buggy code in the process. All it really saves you in practice is a bit of vertical whitespace, so, no, you still don't need it - but if you insist on doing it, at least there's now an easy way to do it correctly. Come on, it's more than vertical whitespace, it's extraneous variables and sometimes even extraneous functions and function call overhead. And Python is supposed to be unbureaucratic. People kept looking for ways to write conditional expressions instead of spewing the logic across multiple statements for a reason: the code is often cleaner that way. True, but it really was the multitude of buggy workarounds for the lack of a ternary expression that sealed the deal, rather than the benefits of ternary expressions in their own right :) Given that I personally use ternary expressions solely as the right hand side of an assignment statement, the reduction in vertical whitespace usage really is the only thing they gain me. I guess if you embedded them as an argument to a function call or other more complicated expression then there may be additional savings. I prefer not to do that though, since such things can get quite difficult to parse mentally when reading them later. Cheers, Nick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 4, 9:56 pm, Ben Finney [EMAIL PROTECTED] wrote: Those unit tests should *not*, though, exercise anything but the public API, otherwise they're breaking encapsulation. Their assertion should continue to be just as true after a refactoring of the internal components as before. Python must have bad unit tests then - the CPython test suite explicitly tests private methods all the time. There's actually an extremely good reason for doing it that way: when the implementation of an internal method gets broken, the unit tests flag it explicitly, rather than having to derive the breakage from the breakage of 'higher level' unit tests (after all, you wouldn't factor something out into its own method or function if you weren't using it in at least a couple of different places). Black box testing (testing only the public API) is certainly important, but grey box and white box testing that either exploits knowledge of the implementation when crafting interesting test cases, or explicitly tests internal APIs can be highly beneficial in localising faults quickly when something does break (and as any experienced maintenance programmer will tell you, figuring out what you actually broke is usually harder than fixing it after you find it). -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-04, NickC [EMAIL PROTECTED] wrote: On May 26, 7:32 am, Joe P. Cool [EMAIL PROTECTED] wrote: I saw this don't need it pattern in discussions about the ternary if..else expression and about except/finally on the same block level. Now Python has both. if/else was added solely because people kept coming up with ways of embedding a pseudo conditional inside expressions and writing buggy code in the process. All it really saves you in practice is a bit of vertical whitespace, so, no, you still don't need it - but if you insist on doing it, at least there's now an easy way to do it correctly. If I remember correctly it was added because one of the python developers was bitten by a bug in the standard library code that was caused by the use of the and-or emulation, mentioned in the FAQ. And although one indeed doesn't need this. There are a lot of things in Python one doesn't need. Python could be limited to single operator expressions. You don't need: x = a * b + c You can write it just like this: x = a * b x = x + c And if you want a list comprehension like the following: ls = [ x * x + 4 for x in xrange(10)] You can of course write it as follows: def sqrplus4(a): rs = a * a return rs + 4 ls = [sqrplus4(x) for x in xrange(10)] Now of course noone would defend such a limitation on the grounds that one doesn't need the general case and that the general case will only save you some vertical space. But when it came to the ternary operator that was exactly the argument used, to defend the lack of it. In Python, the philosophy we're all consenting adults here applies. Please don't sell a missing feature as a philosophy. Say you don't need/want it. But don't call it philosophy. Gosh, and here I thought treating programmers as non-idiots was actually one of the guiding philosophies in the discussion on python- dev. I have heard the argument: Such a feature will be abused too easily and similar too many times to find this credible. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-04, NickC [EMAIL PROTECTED] wrote: On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote: What is it about leading underscores that bothers me? To me, they are like a small pebble in your shoe while you are on a hike. Yes, you can live with it, and it does no harm, but you still want to get rid of it. With leading underscores, you can see *at the point of dereference* that the code is accessing private data. But the leading underscore doesn't tell you whether it is your own private date, which you can use a you see fit, or those of someone else, which you have to be very carefull with. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
But the leading underscore doesn't tell you whether it is your own private date, which you can use a you see fit, or those of someone else, which you have to be very carefull with. -- Antoon Pardon Well how is that different from public accessor and mutators of private variables? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-04, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: But the leading underscore doesn't tell you whether it is your own private date, which you can use a you see fit, or those of someone else, which you have to be very carefull with. -- Antoon Pardon Well how is that different from public accessor and mutators of private variables? Public accessor and mutators for private variables is a bad idea. So I don't understand what point you are trying to make by suggesting that the use of an underscore is just like it in this regard. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: By definition, private functions are not part of the publicly documented behaviour of the unit. Any behaviour exhibited by some private component is seen externally as a behaviour of some public component. You know the difference between theory and reality? In theory, there is none... Sometimes it's useful to test internal components. Imagine this class: class ArmegeddonMachine: def pushTheButton(self): Destroy a random city city = self._pickCity() self._destroy(city) def _pickCity(): cities = ['New York', 'Moscow', 'Tokyo', 'Beijing', 'Mumbai'] thePoorSchmucks = random.choice(cities) return 'New York' def _destroy(self, city): missle = ICBM() missle.aim(city) missle.launch() The only externally visible interface is pushTheButton(), yet you don't really want to call that during testing. What you do want to do is test that a random city really does get picked. You can do one of two things at this point. You can say, But, that's not part of the externally visible interface and refuse to test it, or you can figure out a way to test it. Up to you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 4, 4:29 am, NickC [EMAIL PROTECTED] wrote: On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote: What is it about leading underscores that bothers me? To me, they are like a small pebble in your shoe while you are on a hike. Yes, you can live with it, and it does no harm, but you still want to get rid of it. With leading underscores, you can see *at the point of dereference* that the code is accessing private data. With a this is private keyword you have no idea whether you're accessing private or public data, because the two namespaces get conflated together. That is true. But with the priv keyword you'll discover quickly enough that you are trying to access private data (as soon as you run the program). And even if a priv keyword is added, you are still free to use the leading underscore convention if you wish. The idea of being able to discern properties of an object by its name alone is something that is not normally done in programming in general. Yes, of course you should choose identifiers to be descriptive of what they represent in the real world, but you don't use names like intCount, floatWeight, or MyClassMyObject would you? Why not? That would tell you the type of the object at the point of dereferencing, wouldn't it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Jun 4, 2:58 pm, Russ P. [EMAIL PROTECTED] wrote: On Jun 4, 4:29 am, NickC [EMAIL PROTECTED] wrote: On Jun 4, 4:09 am, Russ P. [EMAIL PROTECTED] wrote: What is it about leading underscores that bothers me? To me, they are like a small pebble in your shoe while you are on a hike. Yes, you can live with it, and it does no harm, but you still want to get rid of it. With leading underscores, you can see *at the point of dereference* that the code is accessing private data. With a this is private keyword you have no idea whether you're accessing private or public data, because the two namespaces get conflated together. That is true. But with the priv keyword you'll discover quickly enough that you are trying to access private data (as soon as you run the program). And even if a priv keyword is added, you are still free to use the leading underscore convention if you wish. The idea of being able to discern properties of an object by its name alone is something that is not normally done in programming in general. Yes, of course you should choose identifiers to be descriptive of what they represent in the real world, but you don't use names like intCount, floatWeight, or MyClassMyObject would you? Why not? That would tell you the type of the object at the point of dereferencing, wouldn't it? Sounds familiar. http://en.wikipedia.org/wiki/Hungarian_notation -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Roy Smith [EMAIL PROTECTED] writes: The only externally visible interface is pushTheButton(), yet you don't really want to call that during testing. What you do want to do is test that a random city really does get picked. Then what you're really testing is the interactions of the push the button function with its external interface: you're asserting that the push the red button function actually uses the result from pick a random city as its target. Thus, the pick a random city function is being defined by you as *interface* for the push the button function. Interfaces do need to be unit tested. This is done by having the unit test substitute a test double for the pick a random city function, rigging that double so that its behaviour is deterministic, and asserting that the push the button function uses that deterministically-generated result. It's at this point, of course, that the pick a random city function has come rather close to being public API. The designer needs to have a fairly good reason not to simply expose the pick a random city function in the API. You can do one of two things at this point. You can say, But, that's not part of the externally visible interface and refuse to test it, or you can figure out a way to test it. Up to you. Note that the only thing I'm saying one shouldn't do is unit test the private function *directly*, since the design decision has been made that it's not part of the API. The *behaviour* of the function, as exposed via the push the button piblic API, should certainly be unit tested. Any behaviour of that function that's *not* exhibited through the behaviour of some public API should *not* be unit tested, and should in fact be removed during refactoring -- which will not break the unit test suite since no unit tests depend on it. Alternatively, as above, the design decision can be made that, in fact, this function *is* part of the public API since external things are depending on it directly. Then it needs full direct unit test coverage. -- \ I got contacts, but I only need them when I read, so I got | `\ flip-ups. -- Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Lie wrote: On May 24, 9:14 pm, Fuzzyman [EMAIL PROTECTED] wrote: For example, at Resolver Systems we expose the spreadsheet object model to our users. It hasa public, documented, API - plus a host of undocumented internally used methods. We would really *much* rather hide these, because anything our customers start using (whether documented or not) we will probably have to continue supporting and maintaining. Then don't document it, or separate internal documentation (which is never to pass through the wall) and public documentation (which your users use). Nobody would (apart from your dev team and anyone told by your dev team, which means you may fire the person for lack of discipline) know that there is such a thing and in consequence wouldn't use it. Don't tell your user not to use something, just don't tell them that it exists and they won't use it. I am not familiar with the actual software, but judging from we expose the spreadsheet object model to our users, I assume that users can discover the undocumented attributes, using Python's introspection features, like dir(obj), obj.__dict__, the inspect module, etc. So in this case, not telling them that the attributes exist, will not stop them from finding out. -- Hans Nowak (zephyrfalcon at gmail dot com) http://4.flowsnake.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On Wed, 04 Jun 2008 09:34:58 +, Antoon Pardon wrote: On 2008-06-04, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: it makes sense to me to also test if they work as documented. If they affect the behaviour of some public component, that's where the documentation should be. As I said they are public themselves for someone. Isn't that contradictory: Public for someone I always thought public meant accessible to virtually anyone. Not to only someone. For the programmer who writes or uses the private API it isn't really private, he must document it or know how it works. And he should IMHO write tests for it and expect private functions written by others to be tested. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Ben Finney wrote: Roy Smith [EMAIL PROTECTED] writes: The only externally visible interface is pushTheButton(), yet you don't really want to call that during testing. What you do want to do is test that a random city really does get picked. Then what you're really testing is the interactions of the push the button function with its external interface: you're asserting that the push the red button function actually uses the result from pick a random city as its target. Thus, the pick a random city function is being defined by you as *interface* for the push the button function. Interfaces do need to be unit tested. This is done by having the unit test substitute a test double for the pick a random city function, rigging that double so that its behaviour is deterministic, and asserting that the push the button function uses that deterministically-generated result. It's at this point, of course, that the pick a random city function has come rather close to being public API. The designer needs to have a fairly good reason not to simply expose the pick a random city function in the API. You can do one of two things at this point. You can say, But, that's not part of the externally visible interface and refuse to test it, or you can figure out a way to test it. Up to you. Note that the only thing I'm saying one shouldn't do is unit test the private function *directly*, since the design decision has been made that it's not part of the API. The *behaviour* of the function, as exposed via the push the button piblic API, should certainly be unit tested. Any behaviour of that function that's *not* exhibited through the behaviour of some public API should *not* be unit tested, and should in fact be removed during refactoring -- which will not break the unit test suite since no unit tests depend on it. Alternatively, as above, the design decision can be made that, in fact, this function *is* part of the public API since external things are depending on it directly. Then it needs full direct unit test coverage. I must be missing something in this discussion. Perhaps it's the appropriate point of view. At any rate, it seems to me that any and every function should be tested to ensure proper results. It's my understanding that unit testing (a.k.a. PyUnit) is designed for just such a purpose. So is this argument simply over *who* should be (unit) testing the internals? I.e. The fellow that wrote the code library vs. the other fellow that wants to use the library? Or is it actually, as it seems, over the internals being tested at all? -- Ethan -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
Ethan Furman [EMAIL PROTECTED] writes: I must be missing something in this discussion. Perhaps it's the appropriate point of view. At any rate, it seems to me that any and every function should be tested to ensure proper results. I restrict that to every proper behaviour the system is expected to provide should be tested. The corollary is that every behaviour is either: * part of an expected external behaviour, and thus unit tests need to assert that behaviour through the unit's public interface * not part of an expected external behaviour, and thus needs to be removed from the system This also forces a decision about private functionality: Either it's part of some public functionality, and thus needs to be tested via that public functionality; or it's not part of any public functionality, and needs to be removed. It's my understanding that unit testing (a.k.a. PyUnit) is designed for just such a purpose. Yes. -- \ I was in the first submarine. Instead of a periscope, they had | `\a kaleidoscope. 'We're surrounded.' -- Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: Then what you're really testing is the interactions of the push the button function with its external interface: you're asserting that the push the red button function actually uses the result from pick a random city as its target. No, that's not what I'm testing at all. I want to test that the cities really do get picked randomly. Notice the implementation I gave: def _pickCity(): cities = ['New York', 'Moscow', 'Tokyo', 'Beijing', 'Mumbai'] thePoorSchmucks = random.choice(cities) return 'New York' There's a deliberate bug in there, i.e. it always returns 'New York', which (as a resident of that city), I would find distressing in such an application. If you plugged in some other function for _pickCity(), you'd never discover that bug until it was too late. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does python not have a mechanism for data hiding?
On 2008-06-03, Carl Banks [EMAIL PROTECTED] wrote: On Jun 2, 10:14 am, Antoon Pardon [EMAIL PROTECTED] wrote: On 2008-06-02, Carl Banks [EMAIL PROTECTED] wrote: Can't you look beyond the specific example? The GetX is just an example. Any local function of __init__ has access to hidden and its attributes and could manipulate them, even if the class wouldn't define getters and setters. Ok. You could have made the proof-of-concept-ness of your example more clear by not, you know, binding those local functions to globally accessable names, thus thwarting your own concept. But still, we all knew functions could do that. Well maybe you all knew that, yet while I read the thread, I saw noone mentioning this possibility to get what the OP seemed to want. I also did't see other posibilities. Your idea as an alternative only came as a reaction to my idea. I know my idea as presented was cumbersome. Maybe it can be worked out more, maybe with the help of decorators to be less cumbersome. I also know it can be circumvented in CPython. Yet I think is was usefull to explore what is already possible in Python instead of just argueing about whether people need it or not I always find it odd when the you don't need it argument is used. Of course that is correct, put python has acquired a lot of things that were originnally labeled you don't need it. So why people still use it against introducing something, is something I don't entirely understand. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
