Paul Boddie wrote:
Paul Rubin wrote:
Right, the problem is if those methods start changing the private
variable. I should have been more explicit about that.
class A:
def __init__(self):
self.__x = 3
def foo(self):
return self.__x
class B(A): pass
class A(B):
On Jan 7, 1:07 am, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly) that Python
Steve Holden [EMAIL PROTECTED] writes:
class A(B):
def bar(self):
self.__x = 5 # clobbers private variable of earlier class named A
Has this ever been reported as a bug in Python? I could imagine more
sophisticated name mangling: something to do with the identity of the
class
Steven D'Aprano [EMAIL PROTECTED] wrote:
On Tue, 09 Jan 2007 10:27:56 +0200, Hendrik van Rooyen wrote:
Steven D'Aprano [EMAIL PROTECTED] wrote:
On Mon, 08 Jan 2007 13:11:14 +0200, Hendrik van Rooyen wrote:
When you hear a programmer use the word probability -
then its time to
At Wednesday 10/1/2007 04:33, Hendrik van Rooyen wrote:
Oh I am of the opposite conviction - Like the fellow of the Circuit Cellar
I forget his name ( Steve Circia (?) ) who said: My favourite Programming
Language is Solder..
Almost right: Steve Ciarcia.
--
Gabriel Genellina
Softlab SRL
Steven D'Aprano [EMAIL PROTECTED] wrote:
On Mon, 08 Jan 2007 13:11:14 +0200, Hendrik van Rooyen wrote:
When you hear a programmer use the word probability -
then its time to fire him, as in programming even the lowest
probability is a certainty when you are doing millions of
things a
[EMAIL PROTECTED] wrote:
I let the user change the internal state of the engine, I have no
assurances that my product (the engine) is doing its job...
How would you proceed to protect this inner states? In C++ private
members they can be accessed through a cast to void pointer. In Java it
can
On Tue, 09 Jan 2007 10:27:56 +0200, Hendrik van Rooyen wrote:
Steven D'Aprano [EMAIL PROTECTED] wrote:
On Mon, 08 Jan 2007 13:11:14 +0200, Hendrik van Rooyen wrote:
When you hear a programmer use the word probability -
then its time to fire him, as in programming even the lowest
Paul Rubin wrote:
Right, the problem is if those methods start changing the private
variable. I should have been more explicit about that.
class A:
def __init__(self):
self.__x = 3
def foo(self):
return self.__x
class B(A): pass
class A(B):
def bar(self):
Paul Boddie [EMAIL PROTECTED] writes:
Has this ever been reported as a bug in Python? I could imagine more
sophisticated name mangling: something to do with the identity of the
class might be sufficient, although that would make the tolerated
subversive access to private attributes rather
Paul Boddie [EMAIL PROTECTED] wrote:
Paul Rubin wrote:
Right, the problem is if those methods start changing the private
variable. I should have been more explicit about that.
class A:
def __init__(self):
self.__x = 3
def foo(self):
return self.__x
class B(A): pass
On Sun, 07 Jan 2007 23:49:21 -0800, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Just how often do you inherit from two identically-named classes
both of which use identically-named private attributes?
I have no idea how often if ever.
You've established that there's a name
Steven D'Aprano wrote:
The truth of the matter is, MyClass.__private is not private at all. It is
still a public attribute with a slightly unexpected name. In other words,
if you want to code defensively, you should simply assume that Python has
no private attributes, and code accordingly.
Steven D'Aprano [EMAIL PROTECTED] writes:
I have no idea how often if ever.
You've established that there's a name conflict when you do so, which
leads to bugs. So how often do you get bitten by that particular type of bug?
I don't know. Likely zero, possibly not. I'm sure I've written
Paul Rubin http://[EMAIL PROTECTED] wrote:
If you want to write bug-free code, pessimism is the name of the game.
A healthy touch of paranoia does not come amiss either...
And even then things foul up in strange ways because your head
is never quite literal enough.
When you hear a programmer
sturlamolden wrote:
The designers of Java, C++, C#, Ada95, Delphi, etc. seem to think that
if an object's 'internal' variables or states cannot be kept private,
programmers get an irresistible temptation to mess with them in
malicious ways. But if you are that stupid, should you be
On 2007-01-08, Paul Rubin http wrote:
Dennis Lee Bieber [EMAIL PROTECTED] writes:
I'd be quite concerned about the design environment rather than the
immediate code... Probably need something ugly like...
from mod1 import B as B1
from mod2 import B as B2
class A(B1, B2):
On 2007-01-08, hg [EMAIL PROTECTED] wrote:
sturlamolden wrote:
The designers of Java, C++, C#, Ada95, Delphi, etc. seem to think that
if an object's 'internal' variables or states cannot be kept private,
programmers get an irresistible temptation to mess with them in
malicious ways. But if
Neil Cerutti kirjoitti:
On 2007-01-08, hg [EMAIL PROTECTED] wrote:
sturlamolden wrote:
The designers of Java, C++, C#, Ada95, Delphi, etc. seem to think that
if an object's 'internal' variables or states cannot be kept private,
programmers get an irresistible temptation to mess with them in
Private data in the C++ and Java OO worlds is so taught so much and
emphasized so often that people have started thinking of it as being
desirable for its own sake. But the primary motivation for it grew out
of the need to maintain compatible interfaces. These languages rely on
a great deal of
Chris Mellon wrote:
Private data in the C++ and Java OO worlds is so taught so much and
emphasized so often that people have started thinking of it as being
desirable for its own sake. But the primary motivation for it grew out
of the need to maintain compatible interfaces.
This is generally
On 2007-01-08, Jussi Salmela [EMAIL PROTECTED] wrote:
Neil Cerutti kirjoitti:
In C one uses the pointer to opaque struct idiom to hide data.
For example, the standard FILE pointer.
To Neil Cerutti: If a programmer in C has got a pointer to some
piece of memory, that piece is at the mercy of
Wow, I got a lot more feedback than I expected!
I can see both sides of the argument, both on technical merits, and
more philosophical merits. When I first learned C++ I felt
setters/getters were a waste of my time and extra code. When I moved
to C# I still felt that, and with their 'Property
[EMAIL PROTECTED] a écrit :
Wow, I got a lot more feedback than I expected!
I can see both sides of the argument, both on technical merits, and
more philosophical merits. When I first learned C++ I felt
setters/getters were a waste of my time and extra code. When I moved
to C# I still
On Mon, 08 Jan 2007 13:11:14 +0200, Hendrik van Rooyen wrote:
When you hear a programmer use the word probability -
then its time to fire him, as in programming even the lowest
probability is a certainty when you are doing millions of
things a second.
That is total and utter nonsense and
Jussi Salmela wrote:
To surlamolden: I don't know how you define private, but if one defines
in C an external static variable i.e. a variable outside any functions,
on the file level, the scope of the variable is that file only.
Sure, in C you can hide instances inside an object image by
Steven D'Aprano wrote:
That is total and utter nonsense and displays the most appalling
misunderstanding of probability, not to mention a shocking lack of common
sense.
While I agree that the programming job itself is not
a program and hence the consider any possibility
simply doesn't make
Paul Rubin wrote:
Yes I've had plenty of
pointer related bugs in C programs that don't happen in GC'd
languages, so GC in that sense saves my ass all the time.
My experience is different, I never suffered a lot for
leaking or dangling pointers in C++ programs; and on
the opposite I didn't
Dennis Lee Bieber [EMAIL PROTECTED] writes:
__ (two leading underscores) results in name-mangling. This /may/ be
used to specify private data, but is really more useful when one is
designing with multiple super classes:
Trouble with this is you can have two classes with the same name,
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly)
On 07 Jan 2007 02:01:44 -0800, Paul Rubin
http://phr.cx@nospam.invalid wrote:
Dennis Lee Bieber [EMAIL PROTECTED] writes:
__ (two leading underscores) results in name-mangling. This /may/ be
used to specify private data, but is really more useful when one is
designing with multiple
Felipe Almeida Lessa [EMAIL PROTECTED] writes:
What is the chance of having to inherit from two classes from
different modules but with exactly the same name *and* the same
instance variable name?
Of course you're being very pessimistic or extremely unlucky.
If you want to write bug-free
[EMAIL PROTECTED] wrote:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
What is the use of private declarations, if the names themselves are not
verbose about
Paul Rubin:
Python certainly makes you spend more of your attention worrying
about possible attribute name collisions between classes and their
superclasses. And Python's name mangling scheme is leaky and
bug-prone if you ever re-use class names.
Trouble with this is you can have two classes
On 06 Jan 2007 17:38:06 -0800, Paul Rubin http wrote:
BJörn Lindqvist [EMAIL PROTECTED] writes:
It is given that emphasizing private data (encapsulation) leads to
more internal complexity and more lines of code because you have to
write getters and setters and stuff.
You can have public
Jorgen Grahn schrieb:
On 06 Jan 2007 17:38:06 -0800, Paul Rubin http wrote:
BJörn Lindqvist [EMAIL PROTECTED] writes:
It is given that emphasizing private data (encapsulation) leads to
more internal complexity and more lines of code because you have to
write getters and setters and stuff.
Thomas Ploch [EMAIL PROTECTED] writes:
Me neither, although I have to say that the '__' prefix comes pretty
close to being 'private' already. It depends on the definition of
private. For me, private means 'not accessible from outside the
module/class'.
class A:
__x = 3
class
Paul Rubin schrieb:
Thomas Ploch [EMAIL PROTECTED] writes:
Me neither, although I have to say that the '__' prefix comes pretty
close to being 'private' already. It depends on the definition of
private. For me, private means 'not accessible from outside the
module/class'.
class A:
[EMAIL PROTECTED] wrote:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly) that Python prefers to leave class
data public.
Paul Rubin wrote:
class A:
__x = 3
class B(A):
__x = 4 # ok
class C(B):
__x = 5 # oops!
Consider that the above three class definitions might be in separate
files and you see how clumsy this gets.
What are you trying to show with the above? The
sturlamolden schrieb:
[EMAIL PROTECTED] wrote:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly) that Python prefers to leave
Andrea Griffini a écrit :
Paul Rubin wrote:
Yes I've had plenty of
pointer related bugs in C programs that don't happen in GC'd
languages, so GC in that sense saves my ass all the time.
My experience is different, I never suffered a lot for
leaking or dangling pointers in C++
Paul Rubin a écrit :
Felipe Almeida Lessa [EMAIL PROTECTED] writes:
What is the chance of having to inherit from two classes from
different modules but with exactly the same name *and* the same
instance variable name?
Of course you're being very pessimistic or extremely unlucky.
If you
[ Thomas Ploch [EMAIL PROTECTED] ]
sturlamolden schrieb:
[EMAIL PROTECTED] wrote:
Coming from a C++ / C# background, the lack of emphasis on private
data seems weird to me. I've often found wrapping private data
useful to prevent bugs and enforce error checking..
It appears to me (perhaps
Sebastian 'lunar' Wiesner schrieb:
Those people deserve to fail for being just extraordinary stupid...
Yes, but there are a lot of them around...
Thomas
P.S.: I don't mean they are around here. :-)
--
http://mail.python.org/mailman/listinfo/python-list
sturlamolden wrote:
[EMAIL PROTECTED] wrote:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly) that Python prefers to leave
Bruno Desthuilliers wrote:
... and on
the opposite I didn't expect that fighting with object
leaking in complex python applications was that difficult
(I've heard of zope applications that just gave up and
resorted to the reboot every now and then solution).
Zope is a special case here,
Thomas Ploch a écrit :
sturlamolden schrieb:
(snip)
As mentioned in other replies, it is not rocket science to access a
class private data. In C++ you can cast to void*, in Java and C# you
can use reflection. C++ is said to be an unsafe language because
programmers can, using a few tricks, mess
On 7 ene, 16:13, John Nagle [EMAIL PROTECTED] wrote:
Because Python doesn't have explicit declarations, scope of variables is
a touchy issue. If you write x = 1 within a function, that will
create a local x if x doesn't exist, or alter a global x if x was
previously created in the
Andrea Griffini a écrit :
Bruno Desthuilliers wrote:
... and on
the opposite I didn't expect that fighting with object
leaking in complex python applications was that difficult
(I've heard of zope applications that just gave up and
resorted to the reboot every now and then solution).
John Nagle a écrit :
sturlamolden wrote:
[EMAIL PROTECTED] wrote:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly) that
On Sun, 07 Jan 2007 04:09:13 -0800, Paul Rubin wrote:
Felipe Almeida Lessa [EMAIL PROTECTED] writes:
What is the chance of having to inherit from two classes from
different modules but with exactly the same name *and* the same
instance variable name?
Of course you're being very pessimistic
Paul Boddie [EMAIL PROTECTED] writes:
Consider that the above three class definitions might be in separate
files and you see how clumsy this gets.
What are you trying to show with the above? The principal benefit of
using private attributes set on either the class or the instance is to
Steven D'Aprano [EMAIL PROTECTED] writes:
If you want to write bug-free code, pessimism is the name of the game.
I wonder whether Paul uses snow chains all year round, even in the blazing
summer? After all, if you want to drive safely, pessimism is the name of
the game.
No. I'm willing to
Dennis Lee Bieber [EMAIL PROTECTED] writes:
I'd be quite concerned about the design environment rather than the
immediate code... Probably need something ugly like...
from mod1 import B as B1
from mod2 import B as B2
class A(B1, B2):
Interesting. I just tried that. mod1.py
On Sun, 07 Jan 2007 19:30:05 -0800, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
If you want to write bug-free code, pessimism is the name of the game.
I wonder whether Paul uses snow chains all year round, even in the blazing
summer? After all, if you want to drive safely,
Steven D'Aprano [EMAIL PROTECTED] writes:
Just how often do you inherit from two identically-named classes
both of which use identically-named private attributes?
I have no idea how often if ever. I inherit from library classes all
the time, without trying to examine what superclasses they
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly) that Python prefers to leave class
data public. What is the logic behind that
[EMAIL PROTECTED] schrieb:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly) that Python prefers to leave class
data public.
[EMAIL PROTECTED] schrieb:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly) that Python prefers to leave class
data public.
time Coming from a C++ / C# background, the lack of emphasis on private
time data seems weird to me.
Python doesn't try to protect you from the authors of the code you use. You
should be intelligent enough to use it wisely. On the flip side, the lack
of truly private data and methods
On 6 Jan 2007 16:07:05 -0800, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Coming from a C++ / C# background, the lack of emphasis on private data
seems weird to me. I've often found wrapping private data useful to
prevent bugs and enforce error checking..
It appears to me (perhaps wrongly)
On 2007-01-07 01:54, BJörn Lindqvist wrote:
Google for python for consenting adults
Or ask yourself the opposite question. Why does C++ and C# prefer more
private data? It is given that emphasizing private data
(encapsulation) leads to more internal complexity and more lines of
code because
BJörn Lindqvist [EMAIL PROTECTED] writes:
It is given that emphasizing private data (encapsulation) leads to
more internal complexity and more lines of code because you have to
write getters and setters and stuff.
You can have public variables in Java if you choose to. Writing
private
64 matches
Mail list logo
