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