471,310 Members | 1,090 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,310 software developers and data experts.

Class Friends


Hello!

Is it possible to make classes friends in Python? Or is it better to just stick
to "Java style" .isThis, .getThat, .setThis style functions?

I understand that classes are generally grouped logically into separate files
anyway. So, this isn't always necessary. But I'm a perfectionist and was
wondering if friendships were possible in Python.

Thank you!

se*******@yahoo.com
Jul 18 '05 #1
11 8494
On Fri, 27 Aug 2004 15:19:53 +0000, Sean Don wrote:

Hello!

Is it possible to make classes friends in Python? Or is it better to just stick
to "Java style" .isThis, .getThat, .setThis style functions?

I understand that classes are generally grouped logically into separate files
anyway. So, this isn't always necessary. But I'm a perfectionist and was
wondering if friendships were possible in Python.


In Python, there isn't much of an idea of "Private"; Python's philosophy
is "We're all consenting adults here." Thus, there isn't much of an idea
of "friends" either. In Java terminology, on a technical level everybody
is already friends with everybody else already.

Ultimately, it is the human meaning of "friendship" that is more
important (classes that twiddle with other classes internals), and Python
allows you to deal with that as you see fit.

In all my years of Python programming, only once have I generated a
"friend" class in the human sense. Generally there are ways around it.

As a final note, don't use 'getThat' or 'setThis'; that's a hack around
Java's weaknesses. Look up "property" in the Python manual and use that;
it is good both for re-factoring classes and for new ones too. This is one
reason that Python "gets away with" the way it works; unless you go out of
your way to break a class's encapsulation, the class author can always
catch things like attribute access with a property.

class MyXActsStrange(object):
def __init__(self):
self._x = 0
def getX(self):
return self._x + 1
def setX(self, val):
self._x = val
x = property(getX, setX)
a = MyXActsStrange()
a.x 1 a.x = 4
a.x

5
Very useful.

(Some people would use "self.__x", to get the psuedo-private name munging
invoked. My call is if the "security" isn't perfect there isn't much
point, as the language is already depending on the client programmer to
behave. I think Java can get good security but C++ is already effectively
as permissive as Python, it just makes the hoops harder.)
Jul 18 '05 #2
On Fri, 27 Aug 2004 16:55:28 GMT, Jeremy Bowers <je**@jerf.org> wrote:
(Some people would use "self.__x", to get the psuedo-private name munging
invoked. My call is if the "security" isn't perfect there isn't much
point, as the language is already depending on the client programmer to
behave. I think Java can get good security but C++ is already effectively
as permissive as Python, it just makes the hoops harder.)


Really, the double-under mangling is more about stopping a subclass
from stomping on some internal detail of the base class. In general,
though, I've found it to be a complete pain in the arse - there's been
too many times where I've been using an external library and wanted to
hook into the base class to fix something, and had to use the mangled
name.

I've considered a jihad to try and get uses of the double-under
mangling removed from the standard library. Maybe once 2.4 is out I'll
take this on.
Jul 18 '05 #3
Sean Don <a@c.d> wrote:
Hello!

Is it possible to make classes friends in Python? Or is it better to just stick to "Java style" .isThis, .getThat, .setThis style functions?
Neither. "friends" has no possible meaning in Python terms. Accessor
methods are a horrid idea in Python: if you ever need access to an
attribute to trigger the execution of some code, why, use 'property' --
that's what it's THERE for!

I understand that classes are generally grouped logically into separate files anyway. So, this isn't always necessary. But I'm a perfectionist and was
wondering if friendships were possible in Python.


What could 'friendship' possibly ever MEAN in a Python context...?!
Alex
Jul 18 '05 #4
Anthony Baxter <an***********@gmail.com> wrote:
...
I've considered a jihad to try and get uses of the double-under
mangling removed from the standard library. Maybe once 2.4 is out I'll
take this on.


Count on my support on this: I consider it "something that looked like
it would be a good idea at the time" (to me, too -- I'm not prescient
either;-) but didn't really work as well as hoped.
Alex
Jul 18 '05 #5
On Fri, 27 Aug 2004 16:55:28 +0000, Jeremy Bowers wrote:
In Python, there isn't much of an idea of "Private"; Python's philosophy
is "We're all consenting adults here." Thus, there isn't much of an idea
of "friends" either. In Java terminology, on a technical level
everybody is already friends with everybody else already.


My own 'rule of thumb' in accessing from outside to the attributes
of a Python class is "read attributes directly, but change them only via
methods". In other words, I treat all attributes in a class as 'readonly'.
This allow me to cut off amletic questions like "shall this be public of
private?", only to change it later on. The rule is so effective that I
tend to use it also in languages that allow public/protected/private
distinctions, like C++ and Java.
Jul 18 '05 #6
Sean Don wrote:
Hello!

Is it possible to make classes friends in Python?


Not just possible - all Python classes are always friends with each
other (something that rubs off Python programmers, I suppose :)

Shalabh

Jul 18 '05 #7
On Fri, 27 Aug 2004 20:37:44 +0200, Alex Martelli wrote:
Anthony Baxter <an***********@gmail.com> wrote:
...
I've considered a jihad to try and get uses of the double-under
mangling removed from the standard library. Maybe once 2.4 is out I'll
take this on.


Count on my support on this: I consider it "something that looked like
it would be a good idea at the time" (to me, too -- I'm not prescient
either;-) but didn't really work as well as hoped.


Well, I didn't want to come right out and say it for fear of starting a
flame war, but yeah, I was thinking this really loudly :-)

(At least it is only for *double* underscores; mangling on singles would
have *really* sucked.)
Jul 18 '05 #8
Shalabh Chaturvedi <sh*****@cafepy.com> pisze:
Is it possible to make classes friends in Python?


Not just possible - all Python classes are always friends with each
other (something that rubs off Python programmers, I suppose :)


That's why other call us "friendly people".

--
Jarek Zgoda
http://jpa.berlios.de/
Jul 18 '05 #9
Jeremy Bowers <je**@jerf.org> wrote:
On Fri, 27 Aug 2004 20:37:44 +0200, Alex Martelli wrote:
Anthony Baxter <an***********@gmail.com> wrote:
...
I've considered a jihad to try and get uses of the double-under
mangling removed from the standard library. Maybe once 2.4 is out I'll
take this on.


Count on my support on this: I consider it "something that looked like
it would be a good idea at the time" (to me, too -- I'm not prescient
either;-) but didn't really work as well as hoped.


Well, I didn't want to come right out and say it for fear of starting a
flame war, but yeah, I was thinking this really loudly :-)

(At least it is only for *double* underscores; mangling on singles would
have *really* sucked.)


Yeah, it would. Mind you, accidental clashes with a base class's
internals _do_ happen, and it IS a pity there's no easy and elegant way
to avoid them, but it currently seems to me (after a few years'
experience, and starting with a positive bias towards the idea) that
mangling on double underscores, as Anthony says, has enough issues to
make it not ideal for the purpose. So, we need to keep that mechanism
in the language, for backwards compatibility (and perhaps as a sneaky
way to claim we DO so have 'private'...!-)... but we sure don't need to
use it ourselves if it gives us more problems than it solves.

Just like the (more practically important) problem of sandboxing (ever
since rexec and Bastion got deprecated), the problem of avoiding
accidental clashes between ancestor and descendant classes, without
paying a substantial price for it, may perhaps be currently classed as
'unsolved -- as yet'.
Alex
Jul 18 '05 #10
>Really, the double-under mangling is more about stopping a subclass
from stomping on some internal detail of the base class. In general,
though, I've found it to be a complete pain in the arse - there's been
too many times where I've been using an external library and wanted to
hook into the base class to fix something, and had to use the mangled
name.


It's more useful when using Mixin classes - as you say, a subclass could
validly want to mess with the implementation of a base class, but a mixin
shouldn't need to touch the internals of another.

--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
Jul 18 '05 #11
Jeremy Bowers <je**@jerf.org> writes:
In Python, there isn't much of an idea of "Private";
**** ALERT: Rantbot trigger activation 8986232 ****

Rant title: Encapsulation and access restriction are orthogonal
concepts.

Rant variant: Python.

Rant summary:

The concept of privacy existis in Python. Please don't confuse
privacy with access restriction.

Python supports encapsulation. Please don't confuse encapsulation
with access restriction.

Encapsulation is data abtraction; access restriction is a pain in
the arse.

Rant body:

<SUPPRESSED>

Some people would use "self.__x", to get the psuedo-private name
munging invoked.


.... access restriction for the really dense.

If the programmer is too dumb to figure out the name mangling scheme
and work around it, then he (and the project he is working on) has
some serious problems, to the extent that accessing private data when
he shouldn't becomes but a drop in the ocean.

Jul 18 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

15 posts views Thread by Guenther Sohler | last post: by
21 posts views Thread by Sebastian Faust | last post: by
5 posts views Thread by Darren Grant | last post: by
13 posts views Thread by Bryan Parkoff | last post: by
4 posts views Thread by Andy Venikov | last post: by
21 posts views Thread by anddos | last post: by
4 posts views Thread by alacrite | last post: by
14 posts views Thread by Rahul | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.