[melbourne-pug] Coding idiom

[Maurice Ling]

Justin Warren wrote:

>On Fri, 2006-05-05 at 10:31 +1000, 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......
>>    
>>
>
>I like that Python doesn't prevent you from using any method. This means
>that if I have a good reason for using a ._xx() or .__xx() method, I can
>use it without having to change the module to make the method public or
>shared (or whatever the C++ idiom is).
>  
>
I understand your point on this. It does remove the constant need to 
decide the "view" of a method as I code in Python. My real concern with 
such idioms is this, it varies with developers. For example, you 
(Justin) may use ._XX for depreciation of codes, Tennessee uses ._XX for 
internal methods, we can appreciate the confusion of the 3rd person 
using both of your codes (or even more) together.

So to an extend, when I look at unknown codes, .XX means safe and any 
number of underscore prefixes to XX (ie, ._XX or .__XX) means 
unquantified danger.

I am hoping that Bill's type system is able to strike a middle ground on 
this, allowing developers to define their own coding conventions which 
is mappable to a standard type system as metaknowledge, or something 
like that.

maurice

>I've had to use an 'internal' method from a third party module a couple
>of times because the module in question didn't have the interface or
>functionality I needed and I didn't want to write a wrapper module or
>modify the library code. It encourages me to contact the module
>developer to request a feature enhancement.. or to submit a patch.
>
>  
>