Re: Why less emphasis on private data?

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 identit

Re: Why less emphasis on private data?

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 P

Re: Why less emphasis on private data?

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): pas

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

"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

Re: Why less emphasis on private data?

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 mak

Re: Why less emphasis on private data?

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 d

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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 general

Re: Why less emphasis on private data?

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 shar

Re: Why less emphasis on private data?

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 mes

Re: Why less emphasis on private data?

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 way

Re: Why less emphasis on private data?

On 2007-01-08, Paul Rubin 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): >>

Re: Why less emphasis on private data?

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 program

Re: Why less emphasis on private data?

"Paul Rubin" 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 program

Re: Why less emphasis on private data?

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 writ

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

"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

Re: Why less emphasis on private data?

"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

Re: Why less emphasis on private data?

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 ba

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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 dr

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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 w

Re: Why less emphasis on private data?

"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

Re: Why less emphasis on private data?

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 ve

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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 creat

Re: Why less emphasis on private data?

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 t

Re: Why less emphasis on private data?

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 specia

Re: Why less emphasis on private data?

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 t

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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.

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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 prefer

Re: Why less emphasis on private data?

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?

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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 cla

Re: Why less emphasis on private data?

Jorgen Grahn schrieb: > On 06 Jan 2007 17:38:06 -0800, Paul Rubin 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

Re: Why less emphasis on private data?

On 06 Jan 2007 17:38:06 -0800, Paul Rubin 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 pub

Re: Why less emphasis on private data?

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 cla

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

"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

Re: Why less emphasis on private data?

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 wi

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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 na

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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 b

Re: Why less emphasis on private data?

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 wrongl

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Re: Why less emphasis on private data?

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

Why less emphasis on private data?

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 ch