Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #31017 > unrolled thread

Private methods

Back to article view | Back to comp.lang.python

Contents

  Private methods real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) - 2012-10-09 14:24 +0100
    Re: Private methods Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-10-09 14:51 +0100
      Re: Private methods real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) - 2012-10-09 14:59 +0100
        Re: Private methods Demian Brecht <demianbrecht@gmail.com> - 2012-10-09 07:08 -0700
        Re: Private methods Robert Kern <robert.kern@gmail.com> - 2012-10-09 15:12 +0100
        Re: Private methods Tim Chase <python.list@tim.thechases.com> - 2012-10-09 09:21 -0500
        Re: Private methods Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-09 11:08 -0600
          Re: Private methods Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-09 23:51 +0000
            Re: Private methods Demian Brecht <demianbrecht@gmail.com> - 2012-10-09 17:26 -0700
              Re: Private methods real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) - 2012-10-10 08:03 +0100
                Re: Private methods alex23 <wuwei23@gmail.com> - 2012-10-10 18:34 -0700
                  Re: Private methods Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-11 02:08 +0000
                  Re: Private methods Dieter Maurer <dieter@handshake.de> - 2012-10-11 08:04 +0200
            Re: Private methods Robert Kern <robert.kern@gmail.com> - 2012-10-10 13:47 +0100
            Re: Private methods Ian Kelly <ian.g.kelly@gmail.com> - 2012-11-01 16:45 -0600
        Re: Private methods Roy Smith <roy@panix.com> - 2012-10-10 09:08 -0400
          Re: Private methods Ramchandra Apte <maniandram01@gmail.com> - 2012-10-10 08:56 -0700
            Re: Private methods Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-10-10 17:13 +0100
              Re: Private methods Grant Edwards <invalid@invalid.invalid> - 2012-10-10 16:30 +0000
              Re: Private methods alex23 <wuwei23@gmail.com> - 2012-10-10 18:39 -0700
    Re: Private methods 88888 Dihedral <dihedral88888@googlemail.com> - 2012-10-10 20:11 -0700

Page 1 of 2  [1] 2  Next page →

#31017 — Private methods

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

Daniele

[toc] | [next] | [standalone]

#31019

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

-- 
Cheers.

Mark Lawrence.

[toc] | [prev] | [next] | [standalone]

#31020

Mark Lawrence <breamoreboy@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.

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

[toc] | [prev] | [next] | [standalone]

#31023

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

[toc] | [prev] | [next] | [standalone]

#31025

On 10/9/12 2:59 PM, D.M. Procida wrote:
> Mark Lawrence <breamoreboy@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

[toc] | [prev] | [next] | [standalone]

#31027

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

[toc] | [prev] | [next] | [standalone]

#31050

On Tue, Oct 9, 2012 at 8:08 AM, Demian Brecht <demianbrecht@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.

[toc] | [prev] | [next] | [standalone]

#31056

On Tue, 09 Oct 2012 11:08:13 -0600, Ian Kelly wrote:

> On Tue, Oct 9, 2012 at 8:08 AM, Demian Brecht <demianbrecht@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.

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



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#31057

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.

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

[toc] | [prev] | [next] | [standalone]

#31065

Demian Brecht <demianbrecht@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

[toc] | [prev] | [next] | [standalone]

#31096

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

[toc] | [prev] | [next] | [standalone]

#31098

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

[toc] | [prev] | [next] | [standalone]

#31104

alex23 <wuwei23@gmail.com> writes:

> 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

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

[toc] | [prev] | [next] | [standalone]

#31078

On 10/10/12 12:51 AM, Steven D'Aprano wrote:
> On Tue, 09 Oct 2012 11:08:13 -0600, Ian Kelly wrote:
>
>> On Tue, Oct 9, 2012 at 8:08 AM, Demian Brecht <demianbrecht@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.
>
> Really? I tend to view name mangling as a waste of time, and complex
> inheritance structures as something to avoid.

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

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

[toc] | [prev] | [next] | [standalone]

#32579

On Tue, Oct 9, 2012 at 5:51 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 09 Oct 2012 11:08:13 -0600, Ian Kelly wrote:
>
>> I tend to view name mangling as being more for avoiding internal
>> attribute collisions in complex inheritance structures than for
>> designating names as private.
>
> Really? I tend to view name mangling as a waste of time, and complex
> inheritance structures as something to avoid.

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

[toc] | [prev] | [next] | [standalone]

#31079

In article 
<1krpdak.u0qy9e1a4knspN%real-not-anti-spam-address@apple-juice.co.uk>,
 real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:

> Mark Lawrence <breamoreboy@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.
> 
> 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?

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.

[toc] | [prev] | [next] | [standalone]

#31089

On Wednesday, 10 October 2012 18:38:04 UTC+5:30, Roy Smith  wrote:
> In article 
> 
> <1krpdak.u0qy9e1a4knspN%real-not-anti-spam-address@apple-juice.co.uk>,
> 
>  real-not-anti-spam-address@apple-juice.co.uk (D.M. Procida) wrote:
> 
> 
> 
> > Mark Lawrence <breamoreboy@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.
> 
> > 
> 
> > 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?
> 
> 
> 
> 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.

Uhum. Language please.

[toc] | [prev] | [next] | [standalone]

#31090

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

[toc] | [prev] | [next] | [standalone]

#31091

On 2012-10-10, Mark Lawrence <breamoreboy@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!!

[toc] | [prev] | [next] | [standalone]

#31097

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web