function v. method

[Bruno Desthuilliers]

Antoon Pardon wrote:
> 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.

It does.

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

Please re-read the Fine Manual and try to understand what I wrote above.
You don't have to parse the import statements to know if you're dealing
with a local implementation detail or implementation of another module,
unless you do braindead renames of imported symbols.

Anyway, messing with another module's implementation should be *very* rare.

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

There are very few chances this convention will change anytime soon. You
may not like it for any good or bad reason, the fact is that you have to
live with it.

FWIW, the choice of other languages I proposed as an alternative is not
totally innocent : they all are possible replacements for Python, and
they all have their share of ugly cryptic notations... I'm not myself a
big fan of the leading underscore, but it's certainly a lesser evil when
compared to $php_vars or others @myperlishstuff. Or with C++
m_myMemberVar FWIW.


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"