[melbourne-pug] Coding idiom

[KevinL]

I thought I remembered something special about double-underscore 
attributes - http://www.thescripts.com/forum/thread41364.html has more 
detail.  Basically, their name gets mangled to avoid namespace 
collisions.  The upshot of this is, the classes you're working with may 
not behave as you expect if you inherit from it for another class (I'd 
guess that the potential for unexpected behaviour is low, but it's there).

I, unlike you, don't see a middle ground between public and private - 
either the variable is part of the documented API and safe to use, or 
it's not.  So .XXX and ._XXX are sufficient in my mind, and the only 
place I use double-underscores is for the standard __doc__, __init__, 
etc. methods.

KevinL

Maurice Ling wrote:
> Hi,
>
> Programmatically, Python does not have any means to "hide" methods, all 
> methods are public (in java's terms). There may be some good reasons for 
> doing so, at least it simplifies things. However, in a large module 
> (especially modules that we did not write ourselves), changing a method 
> can be scary because it may break other parts.
>
> Personally, I think that using .XXX for public, ._XXX for internal and 
> .__XXX for private methods is more of a code documentation thing, which 
> is probably good if followed religiously. At least it does put up a 
> danger flag for yourself in future and prevent shooting yourself in the 
> foot.
>
> I am just wondering how can this is better tied in with Bill Birch's 
> type proposal......
>
> maurice
>
> Tennessee Leeuwenburg wrote:
>
>   
>> Hi all,
>>
>> I've been starting to adopt a new coding idiom, and I thought I'd ask 
>> for comments.
>>
>> I've been extending some code, which has involved overriding many 
>> __doFoo() methods and accessing __myVariable variables. As I understand 
>> it, this is stylistically bad, and __XXX is a way of flagging that the 
>> thing is private-only. Keep Out Unless Absolutely Necessary.
>>
>> I can see a middle ground between the public interface and very private 
>> methods. Such a thing might be an element of processing which is 
>> typically called privately, but wouldn't be unsafe to call or override 
>> in appropriate circumstances.
>>
>> For this reason I've been using .XXX for the public interface, ._doFoo() 
>> for internal methods which are relatively safe, and .__doFoo() for 
>> things intended to be very private.
>>
>> Cheers,
>> -T
>> _______________________________________________
>> melbourne-pug mailing list
>> melbourne-pug at python.org
>> http://mail.python.org/mailman/listinfo/melbourne-pug
>>
>>  
>>
>>     
>
> _______________________________________________
> melbourne-pug mailing list
> melbourne-pug at python.org
> http://mail.python.org/mailman/listinfo/melbourne-pug
>