[melbourne-pug] Coding idiom

[Maurice Ling]

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
>
>  
>