function v. method

[Antoon Pardon]

On 2006-07-21, Bruno Desthuilliers <onurb at xiludom.gro> wrote:
> Antoon Pardon wrote:
>> On 2006-07-21, fuzzylollipop <jarrod.roberson at gmail.com> wrote:
>> 
>>>danielx wrote:
>>>
> (snip)
>>>
>>>
>>>if you prefix with a single underscore, that tells the user, DON'T MESS
>>>WITH ME FROM OUTSIDE! I AM AN IMPLEMENTATION DETAIL!
>> 
>> 
>> Personnaly I don't like this convention. 
>
> To bad for you.

I'll survive.

>> It isn't clear enough.
>
> Oh yes ?
>
>> Suppose I am writing my own module, I use an underscore, to
>> mark variables which are an implementation detail for my
>> module.
>> 
>> Now I need to import an other module in my module and need access
>> to an implementation variable from that module.
>>
>> So now I have
>> variables with an underscore which have two different meanings:
>> 
>>   1) This is an implemantation detail of this module, It is the
>>      users of my module who have to be extra carefull using it.
>> 
>>   2) This is an implemantation detail of the other module,
>>      I should be extra carefull using it.
>
> Either you imported with the "from othermodule import *" form (which you
> shouldn't do), and you *don't* have the implementation of othermodule,
> or your used the "import othermodule" form, in which case it's pretty
> obvious which names belongs to othermodule.

As far as I understand the _name convention is often defended with the
argument that it stands out. Now if you have to go and look at the
import statements to make a disticntion, then it seems that the
way _names standout isn't that usefull.

>> And I find variable starting or ending with an underscore ugly. :-)
>
> Too bad for you. Choose another language then... PHP, Perl, Ruby ?-)

Not a very strong argument. Whether or not someone has a legitimat point
of criticism against Python or some of the conventions used. You can
always reply: Too bad, better choose another language then.

-- 
Antoon Pardon