Mark Lawrence <breamore...@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 :)
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?
> 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.
> 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.
> 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
>> 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."
On Tue, Oct 9, 2012 at 8:08 AM, Demian Brecht <demianbre...@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.
On Tue, 09 Oct 2012 11:08:13 -0600, Ian Kelly wrote:
> On Tue, Oct 9, 2012 at 8:08 AM, Demian Brecht <demianbre...@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.
Demian Brecht <demianbre...@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.
> On Tue, 09 Oct 2012 11:08:13 -0600, Ian Kelly wrote:
>> On Tue, Oct 9, 2012 at 8:08 AM, Demian Brecht <demianbre...@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:
"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
> 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.
> 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 :)
> 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!!
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.
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.
alex23 <wuwe...@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.
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...
<steve+comp.lang.pyt...@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.
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__.
