Private methods

[D.M. Procida]

What exactly is the point of a private method? Why or when would I want
to use one?

Daniele

[Mark Lawrence]

Hardly a Python question but using a search engine could have got you
here, and rather faster :)
http://stackoverflow.com/questions/2620699/why-private-methods-in-the-object-oriented

--
Cheers.

Mark Lawrence.

[D.M. Procida]

Thanks. Sometimes I prefer to talk to real people on Usenet than do web
searches. Just my preference.

Anyway, one of the answers on that page explains that public methods are
interfaces to a class, that other things might rely on, and private ones
are for its own internal logic, that other things don't need to care
about.

In Python, using an underscore is simply a convention to note that a
method is private - it doesn't actually hide it from other things -
correct?

Daniele

[Demian Brecht]

On 12-10-09 06:59 AM, D.M. Procida wrote:
> In Python, using an underscore is simply a convention to note that a
> method is private - it doesn't actually hide it from other things -
> correct?
>
> Daniele
>

A single underscore semantically means private. A double underscore will
name mangle the function such that it's only accessible strictly by name
through the class that it's define in. Note that you *can* still access
it if you understand how name mangling works. Nothing in Python is truly
private.

--
Demian Brecht
@demianbrecht
http://demianbrecht.github.com

[Robert Kern]

On 10/9/12 2:59 PM, D.M. Procida wrote:
> Mark Lawrence <bream...@yahoo.co.uk> wrote:
>
>> On 09/10/2012 14:24, D.M. Procida wrote:
>>> What exactly is the point of a private method? Why or when would I want
>>> to use one?
>>>
>>> Daniele
>>>
>>
>> Hardly a Python question but using a search engine could have got you
>> here, and rather faster :)
>>
> http://stackoverflow.com/questions/2620699/why-private-methods-in-the-ob
> ject-oriented
>
> Thanks. Sometimes I prefer to talk to real people on Usenet than do web
> searches. Just my preference.

That's understandable, but the real people on Usenet who will answer your
questions usually prefer that you do a web search first, for a variety of reasons.

http://www.catb.org/esr/faqs/smart-questions.html#before

> Anyway, one of the answers on that page explains that public methods are
> interfaces to a class, that other things might rely on, and private ones
> are for its own internal logic, that other things don't need to care
> about.
>
> In Python, using an underscore is simply a convention to note that a
> method is private - it doesn't actually hide it from other things -
> correct?

This is correct.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Tim Chase]

On 10/09/12 08:59, D.M. Procida wrote:
>> On 09/10/2012 14:24, D.M. Procida wrote:
>>> What exactly is the point of a private method? Why or when would I want
>>> to use one?
>

> In Python, using an underscore is simply a convention to note that a
> method is private - it doesn't actually hide it from other things -
> correct?

Correct. You can read the leading underscore as "if you use this,
don't come crying if it breaks on you in a future version because we
changed an internal implementation. We told you so."

-tkc

[Ian Kelly]

On Tue, Oct 9, 2012 at 8:08 AM, Demian Brecht <demian...@gmail.com> wrote:
> A single underscore semantically means private. A double underscore will
> name mangle the function such that it's only accessible strictly by name
> through the class that it's define in. Note that you *can* still access it
> if you understand how name mangling works. Nothing in Python is truly
> private.

I tend to view name mangling as being more for avoiding internal
attribute collisions in complex inheritance structures than for
designating names as private.

[Steven D'Aprano]

Really? I tend to view name mangling as a waste of time, and complex
inheritance structures as something to avoid.



--
Steven

[Demian Brecht]

On 12-10-09 04:51 PM, Steven D'Aprano wrote:
> Really? I tend to view name mangling as a waste of time, and complex
> inheritance structures as something to avoid.

Yep, I've been coming around to this as of late.

[D.M. Procida]

Demian Brecht <demian...@gmail.com> wrote:

> On 12-10-09 04:51 PM, Steven D'Aprano wrote:
> > Really? I tend to view name mangling as a waste of time, and complex
> > inheritance structures as something to avoid.
>
> Yep, I've been coming around to this as of late.

I have a lot of inheritance. I don't know whether you'd call it complex,
but I use a lot of mixins to build classes.

It certainly makes it quick to build a class with the attributes I need,
but it does make tracing logic sometimes a pain in the neck.

I don't know what the alternative is though.

Daniele

[Robert Kern]

Whatever you may think of the use case, it was the motivating reason why it was
put into the language:

http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-identifiers

[Roy Smith]

In article
<1krpdak.u0qy9e1a4knspN%real-not-anti...@apple-juice.co.uk>,

Yes (modulo some details of how import works that I've never fully
figured out and which lack of knowledge hasn't seemed to have hurt me
any).

I view public and private in Python this way:

Public: I hereby declare that this method or attribute is part of the
promised never to change interface of this class. I might possibly
break that promise at some point in the future, but if I do, you have
the right to bitch and whine about it, and I'm morally obligated to at
least pretend I care.

Private: I hereby declare that this method or attribute is something I
needed to have for my own purposes, and is officially hidden inside my
kimono. Like all things inside my kimono, you may speculate about their
existence all you want, but you touch them at your own peril. I may
change them at some point in the future, and while you can bitch and
whine about it all you want, I'm not listening.

[Ramchandra Apte]

Uhum. Language please.

[Mark Lawrence]

What language? Further the original was readable, your use of CrapMail
made life difficult until I stripped the superfluous newlines out. Is
it really so awkward to equip yourself with a semi-decent mail reader?
Like Thunderbird, hint, hint :)

--
Cheers.

Mark Lawrence.

[Grant Edwards]

On 2012-10-10, Mark Lawrence <bream...@yahoo.co.uk> wrote:
> On 10/10/2012 16:56, Ramchandra Apte wrote:
>> On Wednesday, 10 October 2012 18:38:04 UTC+5:30, Roy Smith wrote:
>>> Public: I hereby declare that this method or attribute is part of the
>>> promised never to change interface of this class. I might possibly
>>> break that promise at some point in the future, but if I do, you have
>>> the right to bitch and whine about it, and I'm morally obligated to at
>>> least pretend I care.
>>>
>>> Private: I hereby declare that this method or attribute is something I
>>> needed to have for my own purposes, and is officially hidden inside my
>>> kimono. Like all things inside my kimono, you may speculate about their
>>> existence all you want, but you touch them at your own peril. I may
>>> change them at some point in the future, and while you can bitch and
>>> whine about it all you want, I'm not listening.
>>
>> Uhum. Language please.
>
> What language?

Perhaps he didn't like the kimono metaphor?

I always though the kimono metaphore as commonly used by MBA/sales
types was a little unseemly (but then most of what those types say is,
regardless of language or metaphor).

> Further the original was readable, your use of CrapMail made life
> difficult until I stripped the superfluous newlines out. Is it
> really so awkward to equip yourself with a semi-decent mail reader?
> Like Thunderbird, hint, hint :)

You're tilting at windmills.

Just give up and filter out all postings with a messageid ending in
'@googlegroups.com'. I find that solves all sorts of problems...

--
Grant Edwards grant.b.edwards Yow! ! Now I understand
at advanced MICROBIOLOGY and
gmail.com th' new TAX REFORM laws!!

[alex23]

On 10 Oct, 17:03, real-not-anti-spam-addr...@apple-juice.co.uk (D.M.

Procida) wrote:
> It certainly makes it quick to build a class with the attributes I need,
> but it does make tracing logic sometimes a pain in the neck.
>
> I don't know what the alternative is though.

Components.

The examples are in C++ and it's about game development, but I found
this article to be very good at explaining the approach:
http://gameprogrammingpatterns.com/component.html

I've become a big fan of components & adaptation using zope.interface:
http://wiki.zope.org/zope3/ZopeGuideComponents

[alex23]

On 11 Oct, 02:14, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
> What language?

I think he's objecting to "bitch".

I had to block him on G+ because he kept asking me to self-censor
posts that he had _chosen to read_.

[Steven D'Aprano]

On Wed, 10 Oct 2012 18:34:01 -0700, alex23 wrote:

> On 10 Oct, 17:03, real-not-anti-spam-addr...@apple-juice.co.uk (D.M.
> Procida) wrote:
>> It certainly makes it quick to build a class with the attributes I
>> need, but it does make tracing logic sometimes a pain in the neck.
>>
>> I don't know what the alternative is though.
>
> Components.

Composition. Delegation. Traits. Prototypes.

Inheritance is great, but it is not a solution to everything.


--
Steven

[88888 Dihedral]

D.M. Procida於 2012年10月9日星期二UTC+8下午9時24分30秒寫道：

> What exactly is the point of a private method? Why or when would I want
>

Private methods in the object level are searched first
in the run time of python interpreter.

I did turn some private methods in to c programs from time to time.

[Dieter Maurer]

If multiple inheritance is deemed complex, adaptation is even more so:

With multiple inheritance, you can quite easily see from the source
code how things are put together.
Adaptation follows the "inversion of control" principle. With this
principle, how a function is implemented, is decided outside
and can very easily be changed (e.g. through configuration).
This gives great flexibility but also nightmares when things do
not work as expected...

[Ian Kelly]

Name mangling is also useful for object tagging. Suppose you have
object A that is passed object B and needs to track some data
concerning object B, but does not need a strong reference to B. One
solution is to use a weak-key dictionary, but this relies upon B being
hashable, and I find it neater to just store the data on B itself.
The problem is that whatever name you use might conflict with an
existing attribute belonging to B.


class Tagger(object):

def tag(self, taggee):
taggee.__tag = some_tag_data


One of the curious ramifications of Python's name-mangling system is
that even though the attribute above is being set on some arbitrary
object, the mangling that is applied is in any case that of the class
Tagger. Thus the mangled attribute name ends up being "_Tagger__tag",
which is unlikely to cause a conflict.

There are some disadvantages to tagging. One is that you can't tag
objects of built-in types. Another is that you can't tag instances of
classes with __slots__. I tend to view the latter as another reason
to avoid using __slots__.