Re: is python Object oriented??
On Jan 31, 1:54 am, Christian Heimes wrote: > Michael Torrie schrieb: > > >> It all depends on implementation, I think even we can make "C" object > >> oriented with proper implementation. > > > Indeed, any code based on gobject libraries can be object-oriented in > > design and function. > > The Python C API is a good example for well designed and object oriented > C code. > > Christian hello -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com a écrit : On Feb 4, 3:11 am, Bruno Desthuilliers wrote: thmpsn@gmail.com a écrit : On Feb 3, 1:14 am, David Cournapeau wrote: (snip) after all, we have used FILE* for years and I have no idea about the FILE structure. Your lack of knowledge about it doesn't mean that it has somehow magically "private" members. The only reason that most of us don't know what a FILE is is that it's definition is implementation-defined (i.e., every compiler may define it differently). That doesn't have anything to do with private members. For example, on my system, defines FILE as: struct _iobuf { char *_ptr; int _cnt; char *_base; int _flag; int _file; int _charbuf; int _bufsiz; char *_tmpfname; }; Didn't you notice kind of a pattern here ? You mean the leading underscores? I don't think they're used for the same purpose as in Python. Not exactly the same purpose, indeed, but there's still something close: mark the names as "special". In C/C++, identifiers that begin with an underscore are reserved (at least at the outer level). Thus, if the member '_ptr' would instead be named 'ptr', something like this would break things: #define ptr // OOPS!! #include That shouldn't happen with '_ptr', since programs are not supposed to define those kinds of names (yeah, right). And here again : "would break", "shouldn't", "supposed". Convention over enforcement. typedef struct _iobuf FILE; Given this information, nothing prevents me from writing things like: FILE* fp = fopen("file.txt", "r"); if (!fp) { /* do something */ } printf("fp->_cnt = %d\n", fp->cnt); printf("fp->_flag = %d\n", fp->_flag); printf("fp->_file = %d\n", fp->_file); fp->_flag = 0x20; // OOPS!! >> Indeed - and that's exactly the point : nothing prevents you from accessing the implementation, *and yet, you don't* I sure don't, but I still *can*. So what ? CHAOS MAY ENSUE!! C is not really a new technology, and has been the basis for most systems for years and years. Looks like nothing that bad as "CHAOS" really happened so far... -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
* Russ P. (Tue, 3 Feb 2009 21:04:30 -0800 (PST)) > Imagine you own a company, and you decide to lease an office building. > Would you expect the office doors to have locks on them? Oh, you > would? Why? You mean you don't "trust" your co-workers? What are locks > but enforced access restriction? > > What people like you are saying is that you don't need no stinkin' > locks because your co-workers are all "consenting adults" whom you > trust. Actually, you're saying even more than that. You're saying that > office doors never need locks, because everyone should trust their co- > workers. All you need is a "keep-out" sign on the door (leading > underscores). And you are presenting as evidence for your position the > fact that people occasionally get locked out of an office that they > need to get into. > > I'm saying, fine, if you trust your co-workers, then keep the doors > unlocked, but please don't insist that office doors come without > locks. Yes, locks occasionally cause inconvenience, but they serve a > very useful purpose if used properly. This analogy is not adequate. If someone uses your library then it is his office and nothing can stop him. Someone else gave a better analogy with a device that says that the warranty is lost if you open it. And that's exactly the same with the underscore convention. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Wednesday 04 February 2009 10:53:54 am Russ P. wrote: > On Feb 4, 5:35 am, Luis Zarrabeitia wrote: > > Quoting "Russ P." : > > This analogy is nonsense. There is no way you will execute code on my > > system if I don't authorize it, regardless of how "public" are the > > variables declared in my code. No one will execute code on _your_ system > > either, without your authorization. That puts you in a different > > position: you can easily _check_ that everything is alright before > > executing, whereas in the office example, it cannot be done. > > I don't follow your point, [...] > The locks on the doors are analogous to enforced access restrictions. And that is my point, nothing more, nothing less. They aren't analogous. I know a bit of python, and a bit of programming, and I think you do too. If you can't make your point without an analogy, isn't it perhaps that your point is not transferable from the analogy to the python context where you are trying to apply it?. You can control everything that happens in your systems, whatever those systems may be. There are no locks, no offices, no employees going unchecked. You can decide, at any time you want, if the code you are about to run meets your policies. The particular one you are talking about, the "data hiding", can be easily checked. By you, by the QA team, by a computer, by an automated system, by your own pseudo python interpreter that will run pylint against the code before trying to run it. Insert that into your office analogy, and maybe then situations will be a little more analogous. But keep in mind that the only difference between what you claim to want and what you currently have, is that _you_ (not me) can decide whether to use it or not. -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Steven D'Aprano writes: > Now, that's a toy example. Languages like Ada make correctness proofs, > well, perhaps not easy, but merely difficult compared to impossible for > languages like Python. Say `generally impractical' rather than `impossible' and I'll agree with you. But I'm not actually sure that the situation for Python with respect to correctness proofs is significantly harder than it is for C. Certainly Ada (or at least dialects of Ada) have features which make proof-supporting tools easier; I'm not aware of such proof support for other languages. Actually, if you're starting from a formal specification in Z, say, and implementing in Python, well, the Z checker will already have ensured that your specification is well typed; your proof that the implementation follows the specification will automatically contain a well-typed-ness proof of your implementation regardless of whether the compiler provides static verification. > To bring it back to private/public attributes, side-effects make > correctness proofs difficult. Modifications of attributes are side- > effects. When attributes are subject to being modified by arbitrary code, > it is harder to reason about the correctness of the code: > > class Inverter(object): > def __init__(self, x): > # Pre-condition: x is always a float > if x: > self.x = x > else: > raise ValueError("x must not be zero") > # Post-condition: if self.x exists, it is a non-zero float > def invert(self): > return 1.0/self.x > > > Is method invert correct? I'd argue that it isn't, and in fact that the specification is wrong. In particular, it ought to be a precondition that x is nonzero. At this point you can dump the explicit check at the cost of imposing a proof obligation on the caller. > No, it is not, because the invariant that self.x is non-zero may have > been broken by some arbitrary piece of code elsewhere. It's not stated as an invariant. It's stated as a post-condition, which is indeed true (almost[1]) regardless of the behaviour of other parts of the program. [1] A subclass may have already set self.x before invoking Inverter.__init__. If you explicitly `del self.x' before raising the exception, the subclass can still defeat you by passing the reference to the half-constructed object to another thread which mutates the object at an inconvenient time. I mention all of this merely to avoid pedantry in follow-ups. I'd also argue that maintaining the invariant about self.x is the responsibility of code that messes with self.x, and therefore it is /legitimate/ to modify self.x from external code which maintains the invariant. > Our ability to reason about the correctness of the code is weakened > significantly. Sticking an underscore in front of x does not help: > there's nothing to stop some arbitrary function elsewhere changing _x > to zero. Dichotomy for you. * EITHER the other code is written to the same high standards, in which case it will come with appropriate specifications, preconditions, postconditions, invariants and proofs for whatever it does, even -- especially -- if it involves grubbily messing about with your module's innards (so everything is fine); * OR the other code doesn't meet your high standards, in which case all bets are off anyway, from the point of view of formal-methods types at any rate (so you can wash your hands of the whole affair). > (1) Paranoia. Make the developer responsible for checking everything all > the time: [...] > (2) Hope the error never occurs, and if it does, let the caller deal with > it. [...] > There is a third strategy, sadly not available to Python programmers: > prevention by catching potential errors at compile-time. Four: Describe your interface clearly, specify the behaviour of functions and so on; and leave whoever messes with your module with the task of proving -- to whatever level of formality is required by their project -- that what they've done is sane and reasonable. In fact, since whatever one does in a project should be held to this standard, whether it involves grubbing about inside undocumented internals or not, there's nothing particularly special about this case. Good job, really, since Python doesn't distinguish either. ;-) -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
"Russ P." writes: > Imagine you own a company, and you decide to lease an office building. > Would you expect the office doors to have locks on them? Oh, you > would? Why? You mean you don't "trust" your co-workers? What are locks > but enforced access restriction? Huh? The lock on the door isn't to keep the coworkers out. It's to let them /in/ while keeping everyone else out. So I don't really see the analogy. Or are you talking about the individual offices? If so, then I'd expect the locks to be /used/ only under rather unusual circumstances. If someone in the office has something to hide, I think that's rather suspicious, actually... -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 4, 3:11 am, Bruno Desthuilliers wrote: > thmpsn@gmail.com a écrit : > > > > > On Feb 3, 1:14 am, David Cournapeau wrote: > (snip) > >> after all, we have used FILE* for years and I have no idea about the FILE > >> structure. > > > Your lack of knowledge about it doesn't mean that it has somehow > > magically "private" members. The only reason that most of us don't > > know what a FILE is is that it's definition is implementation-defined > > (i.e., every compiler may define it differently). > > > That doesn't have anything to do with private members. For example, on > > my system, defines FILE as: > > > struct _iobuf { > > char *_ptr; > > int _cnt; > > char *_base; > > int _flag; > > int _file; > > int _charbuf; > > int _bufsiz; > > char *_tmpfname; > > }; > > Didn't you notice kind of a pattern here ? You mean the leading underscores? I don't think they're used for the same purpose as in Python. In C/C++, identifiers that begin with an underscore are reserved (at least at the outer level). Thus, if the member '_ptr' would instead be named 'ptr', something like this would break things: #define ptr // OOPS!! #include That shouldn't happen with '_ptr', since programs are not supposed to define those kinds of names (yeah, right). > > typedef struct _iobuf FILE; > > > Given this information, nothing prevents me from writing things like: > > > FILE* fp = fopen("file.txt", "r"); > > if (!fp) { /* do something */ } > > > printf("fp->_cnt = %d\n", fp->cnt); > > printf("fp->_flag = %d\n", fp->_flag); > > printf("fp->_file = %d\n", fp->_file); > > > fp->_flag = 0x20; // OOPS!! > > Indeed - and that's exactly the point : nothing prevents you from > accessing the implementation, *and yet, you don't* I sure don't, but I still *can*. CHAOS MAY ENSUE!! -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Hendrik van Rooyen wrote: "Scott David Daniels" wrote: You might enjoy looking at QNX, since I think it is built along the lines you are describing here. I have an ancient copy of their OS, but haven't followed for more than couple of decades. I vaguely know about it, and I know they claim to be hot on real time stuff. I have never pursued it in any depth because of the real tiny nature of the processors I have been working with (8031). When I had a cursory look at it a long time ago, it seemed to be almost unix like in its make up, and I doubted that I could persuade it to run on of them. (I may be dead wrong of course - I don't know) I will put it on my list of stuff to try to get done. Slightly OT: QNX was open-sourced, at least for non-commercial use, a little more that a year ago. So it might be worth a new look. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
En Wed, 04 Feb 2009 07:05:22 -0200, Bruno Desthuilliers escribió: Gabriel Genellina a écrit : En Mon, 02 Feb 2009 19:51:11 -0200, Russ P. escribió: Suppose a library developer (or a module developer on a large team) uses leading underscores. Now suppose that, for whatever reason (pressure from the users, perhaps), the library developer decides to change a "private" attribute to public. Now all occurrences of the identifier need to be changed. If an assignment to the previously "private" attribute is missed, no warning will be issued (because Python allows new attributes to be added anywhere, even completely outside the class definition itself). And if the library is widely used, the probability of such bugs occurring is very high. So _foo becomes foo. Then: class X(object): def get_foo(self): return self._foo def set_foo(self, value): self._foo = value foo = property(get_foo, set_foo) FWIW, if there's no other need for the property, I'd do it the other way round : directly make foo a plain attribute, and add a _foo property whose accessors would raise a deprecation warning. Then there's no chance I miss a an assignement to _foo !-) Yes, that would be better. In any case, one has both static analysis tools (e.g. pylint) and dynamic warnings (like you said above) so I don't see a problem here. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 4, 5:35 am, Luis Zarrabeitia wrote: > Quoting "Russ P." : > > > Imagine you own a company, and you decide to lease an office building. > > Would you expect the office doors to have locks on them? Oh, you > > would? Why? You mean you don't "trust" your co-workers? What are locks > > but enforced access restriction? > > This analogy is nonsense. There is no way you will execute code on my system > if > I don't authorize it, regardless of how "public" are the variables declared in > my code. No one will execute code on _your_ system either, without your > authorization. That puts you in a different position: you can easily _check_ > that everything is alright before executing, whereas in the office example, it > cannot be done. I don't follow your point, but I think you are reading too much into the analogy. Obviously, an office building cannot be "copied" in a few seconds as a software library can, so the analogy obviously cannot be taken too far. The locks on the doors are analogous to enforced access restrictions. When you lease the building, you are presumably given a complete set of keys, including master keys. The keys are analogous to the source code, which allows you to trivially disable the access restrictions. People like you are saying that keys are not enough. You don't want to be bothered with keys. You want the office doors to come with no locks on them at all, because you don't intend to lock them anyway, and someone could possibly get locked out someday. You are saying that locks are unnecessary because you trust your co-workers (aren't you lucky!), and you can just put "keep-out" signs on the doors (leading underscores). Well, that may be reasonable for a small group of developers working on a small, "cool" project. It is inappropriate, however, for a large, safety-critical project with dozens or hundreds of developers that are hired off the street in accordance with current labor laws. Now, if you concede that Python is just not intended for such projects, then fine, but please don't claim that access restrictions are useless for all applications and domains. That's just ridiculous. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Quoting "Russ P." : > Imagine you own a company, and you decide to lease an office building. > Would you expect the office doors to have locks on them? Oh, you > would? Why? You mean you don't "trust" your co-workers? What are locks > but enforced access restriction? This analogy is nonsense. There is no way you will execute code on my system if I don't authorize it, regardless of how "public" are the variables declared in my code. No one will execute code on _your_ system either, without your authorization. That puts you in a different position: you can easily _check_ that everything is alright before executing, whereas in the office example, it cannot be done. Of course, if the analogy is flawed in such an essential aspect, I won't even humor it. I worry, though, that you obviously believe that it is not flawed. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Quoting "Russ P." : > > Indeed he can. He can even do that in Python; it just requires a little > > self-discipline from the team, or a validation script on the code > > repository if he really doesn't trust them. Not only can this be done > > without forcing the rest of the world to play, it makes things a little > > less daunting when those nice clean interfaces turn out to be > > incomplete/too slow/not what you thought. > > This has already been refuted several times on this thread alone, so I > will not bother doing it again. > Please, point out where, because I don't recall you explaining why is not enough to use a "validation script" on the code if you wish to. I _do_ recall you saying that you didn't want the validation script unless it is integrated with python, but I'm yet to see the difference. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Steven D'Aprano a écrit : On Tue, 03 Feb 2009 12:09:46 +0100, Bruno Desthuilliers wrote: I love Python, and I'm greedy and want it all: I want a dynamic, easy-to- use language *and* a compiler that can protect me from myself That's not what compilers are for. So you say. While it's quite clear that a compiler for a statically typed language can catch at least some type errors, this is still not what a compiler is for. A compiler is here to compile you source code into a suitable representation for the execution environment. And FWIW, some compilers are rather weaker than Python when it comes to "protecting you from yourself". and bad data. I definitly fail to see how a compiler could protect you from *runtime* issues ??? I'm surprised you can't. Any time a compiler prevents an error by detecting it at compile-time (say, attempting to store a 96-bit float into the memory space allocated for a 32-bit int), Oh, you meant "type error". But this is a programming error, not "bad data". "bad data" is something you get (usually from the outside world) at runtime only. Well, the way I understand it, at least. Perhaps what you are thinking is that I meant compilers can protect you from "all" runtime issues. That would be silly. Although, in principle, we can get close, for some definition of "close". Here's a toy function, and a specification: def inverse(x): return 1.0/x Specification: input must be a float, output must be a float. Is that function correct? No, because it will raise an exception if x==0.0. Python's compiler is dumb and will allow you to write incorrect functions, but a smart compiler could look at that function and see that it was incorrect. The fix would then be to change the code, or the specification, or both. Ok, let's see. What happens if you pass 0.0 to the function as-is ? Yes, indeed, you get a runtime error. Now what happens if you add error handling to the function itself ? What will the error handler do ? Yes, raise a runtime error. So far, I don't see any gain here. No, no, don't answer yet. Sure, what you need here is a compiler that can inspect the whole code source using this function to make sure it is always properly invoked. Mmm, wait - will this work with shared libs ? I'm afraid not. Ok, so you have to change the specification to : "input must be a non-zero-float", and use the type system to define non-zero-float type. Smart compilers turn some runtime errors into compile-time errors. Indeed. The earlier you catch the error, the easier it is to fix it. Indeed. Now, that's a toy example. Languages like Ada make correctness proofs, well, perhaps not easy, but merely difficult compared to impossible for languages like Python. Indeed. And that's fine : if we want maximum type safety and as-possibly-proved code, we know which tool to use. Now good luck doing web development, system admin, app scripting and quite a lot of other things (well, perhaps more that 80% of ordinary application programming) in Ada. Can you understand that not everybody needs maximum type safety / correctness proof etc for all his code ? That all this "security" stuff comes with a price that may not be worth paying ? To bring it back to private/public attributes, side-effects make correctness proofs difficult. Modifications of attributes are side- effects. Then use a functional language !-) When attributes are subject to being modified by arbitrary code, it is harder to reason about the correctness of the code: Indeed. Not the right tool, obviously. OTHO, it makes it way easier to use as glue between different, sometimes not highly compatible components. (snip) There are two usual approaches to dealing with that problem which are available to Python programmers: (1) Paranoia. Make the developer responsible for checking everything all the time: Paranoiacs (also known as control-freaks) are not happy using Python. They usually prefer Ada or, at least, Java. def invert(self): x = self.x if isinstance(x, float) and x: return 1.0/self.x else: raise MyError('post-condition x a non-zero float violated') The correct solution is indeed to make x a property with a sanity check in the setter - in which case you'll have a useful traceback - or as a read-only property, or even better to just declare it as implementation (naming it _x). (2) Hope the error never occurs, and if it does, let the caller deal with it. If the attribute is either a read-only property or an implementation attribute, then the guy that messed with it is responsible for the possible consequences. That's the contract, yes. Hopefully you aren't your own caller. I'm usually the first user of my own libs, and my coworkers comes immediatly after. IOW, I eat my own dogfood, thanks. That's often the Python approach. As I explained above, the "Python approach" is actually a bit d
Re: is python Object oriented??
Russ P. a écrit : On Feb 3, 4:14 pm, "Rhodri James" wrote: On Tue, 03 Feb 2009 05:37:57 -, Russ P. wrote: (snip) If a library developer releases the source code of a library, any user can trivially "defeat" the access restrictions. But if a team of developers is checking in code for a project, the leader(s) of the project can insist that the access restrictions be respected to simplify the management of interfaces. The larger the team, the more useful that can be. That's why Java, C++, Ada, Scala, and other languages have a "private" keyword. Indeed he can. He can even do that in Python; it just requires a little self-discipline from the team, or a validation script on the code repository if he really doesn't trust them. Not only can this be done without forcing the rest of the world to play, it makes things a little less daunting when those nice clean interfaces turn out to be incomplete/too slow/not what you thought. This has already been refuted several times on this thread alone, s/refuted/debated/ -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com a écrit : On Feb 3, 1:14 am, David Cournapeau wrote: (snip) after all, we have used FILE* for years and I have no idea about the FILE structure. Your lack of knowledge about it doesn't mean that it has somehow magically "private" members. The only reason that most of us don't know what a FILE is is that it's definition is implementation-defined (i.e., every compiler may define it differently). That doesn't have anything to do with private members. For example, on my system, defines FILE as: struct _iobuf { char *_ptr; int _cnt; char *_base; int _flag; int _file; int _charbuf; int _bufsiz; char *_tmpfname; }; Didn't you notice kind of a pattern here ? typedef struct _iobuf FILE; Given this information, nothing prevents me from writing things like: FILE* fp = fopen("file.txt", "r"); if (!fp) { /* do something */ } printf("fp->_cnt = %d\n", fp->cnt); printf("fp->_flag = %d\n", fp->_flag); printf("fp->_file = %d\n", fp->_file); fp->_flag = 0x20; // OOPS!! Indeed - and that's exactly the point : nothing prevents you from accessing the implementation, *and yet, you don't* - unless of course you have a very strong reason to do so for a very specific corner case *and* you pretty well know what you're doing *and* you accept the implications. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Gabriel Genellina a écrit : En Mon, 02 Feb 2009 19:51:11 -0200, Russ P. escribió: Suppose a library developer (or a module developer on a large team) uses leading underscores. Now suppose that, for whatever reason (pressure from the users, perhaps), the library developer decides to change a "private" attribute to public. Now all occurrences of the identifier need to be changed. If an assignment to the previously "private" attribute is missed, no warning will be issued (because Python allows new attributes to be added anywhere, even completely outside the class definition itself). And if the library is widely used, the probability of such bugs occurring is very high. So _foo becomes foo. Then: class X(object): def get_foo(self): return self._foo def set_foo(self, value): self._foo = value foo = property(get_foo, set_foo) FWIW, if there's no other need for the property, I'd do it the other way round : directly make foo a plain attribute, and add a _foo property whose accessors would raise a deprecation warning. Then there's no chance I miss a an assignement to _foo !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
"Scott David Daniels" wrote: > You might enjoy looking at QNX, since I think it is built along the > lines you are describing here. I have an ancient copy of their OS, > but haven't followed for more than couple of decades. I vaguely know about it, and I know they claim to be hot on real time stuff. I have never pursued it in any depth because of the real tiny nature of the processors I have been working with (8031). When I had a cursory look at it a long time ago, it seemed to be almost unix like in its make up, and I doubted that I could persuade it to run on of them. (I may be dead wrong of course - I don't know) I will put it on my list of stuff to try to get done. Thanks for the reminder. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Tue, 03 Feb 2009 12:09:46 +0100, Bruno Desthuilliers wrote: >> I love Python, and I'm greedy and want it all: I want a dynamic, >> easy-to- use language *and* a compiler that can protect me from myself > > That's not what compilers are for. So you say. >> and bad data. > > I definitly fail to see how a compiler could protect you from *runtime* > issues ??? I'm surprised you can't. Any time a compiler prevents an error by detecting it at compile-time (say, attempting to store a 96-bit float into the memory space allocated for a 32-bit int), it has prevented a runtime error. Perhaps what you are thinking is that I meant compilers can protect you from "all" runtime issues. That would be silly. Although, in principle, we can get close, for some definition of "close". Here's a toy function, and a specification: def inverse(x): return 1.0/x Specification: input must be a float, output must be a float. Is that function correct? No, because it will raise an exception if x==0.0. Python's compiler is dumb and will allow you to write incorrect functions, but a smart compiler could look at that function and see that it was incorrect. The fix would then be to change the code, or the specification, or both. Smart compilers turn some runtime errors into compile-time errors. The earlier you catch the error, the easier it is to fix it. Now, that's a toy example. Languages like Ada make correctness proofs, well, perhaps not easy, but merely difficult compared to impossible for languages like Python. To bring it back to private/public attributes, side-effects make correctness proofs difficult. Modifications of attributes are side- effects. When attributes are subject to being modified by arbitrary code, it is harder to reason about the correctness of the code: class Inverter(object): def __init__(self, x): # Pre-condition: x is always a float if x: self.x = x else: raise ValueError("x must not be zero") # Post-condition: if self.x exists, it is a non-zero float def invert(self): return 1.0/self.x Is method invert correct? No, it is not, because the invariant that self.x is non-zero may have been broken by some arbitrary piece of code elsewhere. Our ability to reason about the correctness of the code is weakened significantly. Sticking an underscore in front of x does not help: there's nothing to stop some arbitrary function elsewhere changing _x to zero. There are two usual approaches to dealing with that problem which are available to Python programmers: (1) Paranoia. Make the developer responsible for checking everything all the time: def invert(self): x = self.x if isinstance(x, float) and x: return 1.0/self.x else: raise MyError('post-condition x a non-zero float violated') You can use decorators to decrease the amount of boilerplate, but you have to remember to use the decorators; or you can use a metaclass to automatically apply decorators, but that's hard and not very flexible. Whichever way you do it, you're still responsible, and whatever way, you still have to pay the performance penalty. This also turns an unexpected exception into an expected exception, but is otherwise rather useless. It doesn't tell you when the post-condition was violated, or by what function, and that's the information you need in order to fix the bug. (2) Hope the error never occurs, and if it does, let the caller deal with it. Hopefully you aren't your own caller. That's often the Python approach. I've already written about the glorious freedom such an approach gives the developer. I'm not being sarcastic: even if you are your own caller, you get to put off worrying about a bug which might never happen. This is a great strategy when the worst thing that a bug will do is display an icon in the wrong position. Fix it in the next release. But that's not a viable strategy when the consequences of a bug might include giving the patient 20,000 rads of radiation instead of 200: http://www.ccnr.org/fatal_dose.html There is a third strategy, sadly not available to Python programmers: prevention by catching potential errors at compile-time. (Python does catch some errors at compile-time, but only syntax errors.) If x can only be modified in a few places, (that is, it is effectively hidden or private) then it is much easier to reason about program correctness, avoid bugs, and debug those bugs which do occur. No, this is not a panacea which will prevent every imaginable bug. Nor is it a replacement for unit-testing (which also does not prevent every imaginable bug). It is a compliment to unit-testing. Is it subject to over-use or misuse? Of course it is. So are properties, and decorators, and metaclasses, and OO, and Singletons, and, well, everything. Let's not close our eyes to *either* the costs or the benefits, and let's not limit what Python
Re: is python Object oriented??
On Feb 3, 7:49 pm, "Rhodri James" wrote: > On Wed, 04 Feb 2009 01:13:32 -, Russ P. wrote: > > On Feb 3, 4:05 pm, "Rhodri James" wrote: > >> I'm very much of the second opinion; it was Russ who did the sudden > >> volte > >> face and declared that it was trivial to circumvent. > > > Whoa! Hold on a minute here. Your failure to understand a simple idea > > does not constitute a "sudden volte" (whatever that is) on my part. > > My apologies. "Volte-face" should have had a hyphen in it. > > > Let me try to explain again what should be fairly obvious. > > I understood you just fine. It was how what you described was > consistent with your previous position that "private" was needed > for enforcement purposes, while the leading underscore convention > relied on team discipline and was therefore insufficient. Since > you've clarified that "private" enforces privacy through... er... > team discipline, I'm now just very confused as to what you think > it buys you. > > -- > Rhodri James *-* Wildebeeste Herder to the Masses You need team discipline either way. The question here is to what extent the language supports the discipline. If you are going to check for access violations anyway with third-party tools or code reviews, why not let the language do the job for you automatically (or at least take a first cut at it)? Imagine you own a company, and you decide to lease an office building. Would you expect the office doors to have locks on them? Oh, you would? Why? You mean you don't "trust" your co-workers? What are locks but enforced access restriction? What people like you are saying is that you don't need no stinkin' locks because your co-workers are all "consenting adults" whom you trust. Actually, you're saying even more than that. You're saying that office doors never need locks, because everyone should trust their co- workers. All you need is a "keep-out" sign on the door (leading underscores). And you are presenting as evidence for your position the fact that people occasionally get locked out of an office that they need to get into. I'm saying, fine, if you trust your co-workers, then keep the doors unlocked, but please don't insist that office doors come without locks. Yes, locks occasionally cause inconvenience, but they serve a very useful purpose if used properly. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Wed, 04 Feb 2009 01:13:32 -, Russ P. wrote: On Feb 3, 4:05 pm, "Rhodri James" wrote: I'm very much of the second opinion; it was Russ who did the sudden volte face and declared that it was trivial to circumvent. Whoa! Hold on a minute here. Your failure to understand a simple idea does not constitute a "sudden volte" (whatever that is) on my part. My apologies. "Volte-face" should have had a hyphen in it. Let me try to explain again what should be fairly obvious. I understood you just fine. It was how what you described was consistent with your previous position that "private" was needed for enforcement purposes, while the leading underscore convention relied on team discipline and was therefore insufficient. Since you've clarified that "private" enforces privacy through... er... team discipline, I'm now just very confused as to what you think it buys you. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 4:14 pm, "Rhodri James" wrote: > On Tue, 03 Feb 2009 05:37:57 -, Russ P. wrote: > > On Feb 2, 7:48 pm, "Rhodri James" wrote: > >> On Tue, 03 Feb 2009 02:16:01 -, Russ P. > >> wrote: > >> > Here we go again. If you have access to the source code (as you nearly > >> > always do with Python code), then "breaking the language-enforced data > >> > hiding" is a trivial matter of deleting the word "private" (or > >> > equivalent). > > >> If it's that trivial to defeat something that its proponents appear to > >> want to be close to an iron-clad guarantee, what on earth is the point > >> of using "private" in the first place? > > > If a library developer releases the source code of a library, any user > > can trivially "defeat" the access restrictions. But if a team of > > developers is checking in code for a project, the leader(s) of the > > project can insist that the access restrictions be respected to > > simplify the management of interfaces. The larger the team, the more > > useful that can be. That's why Java, C++, Ada, Scala, and other > > languages have a "private" keyword. > > Indeed he can. He can even do that in Python; it just requires a little > self-discipline from the team, or a validation script on the code > repository if he really doesn't trust them. Not only can this be done > without forcing the rest of the world to play, it makes things a little > less daunting when those nice clean interfaces turn out to be > incomplete/too slow/not what you thought. This has already been refuted several times on this thread alone, so I will not bother doing it again. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 4:05 pm, "Rhodri James" wrote: > On Tue, 03 Feb 2009 08:45:23 -, Steven D'Aprano > > wrote: > > I find this extreme position is rather incoherent. If I may paraphrase > > the argument as I see it: > > "Enforced data hiding is useless, because it is utterly trivial to bypass > > it, AND it's wicked, because it makes it unbelievably painful and > > difficult to bypass it when you need to." > > If it is trivial to bypass, surely it can't be that painful to bypass? > > I think you haven't noticed which of the parties is shifting their ground. > I'm very much of the second opinion; it was Russ who did the sudden volte > face and declared that it was trivial to circumvent. Whoa! Hold on a minute here. Your failure to understand a simple idea does not constitute a "sudden volte" (whatever that is) on my part. Let me try to explain again what should be fairly obvious. If the user of the library has the source code (and the right to modify it), disabling access restrictions is trivial. You simply delete the "private" keyword (or equivalent) wherever necessary. If you are working with a team, however, you cannot just do that unilaterally unless you have the authority to do so. In other words, you may be required to conform to the APIs established by the team. In that case, disabling access restrictions may not be impossible (or even difficult), but it is no longer trivial. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Wed, Feb 4, 2009 at 4:10 AM, wrote: > > What limitations? The only limitations I see are the ones associated > with opaque types (what you mentioned above). Opaque type are used in C++ as well, for data hiding - if private/public were that great for data hiding, the PIMPL idiom would not be used. That's the limitation I am talking about. Granted, it is relatively specific to C++, which use the C headers mechanism for API declaration. David -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Tue, 03 Feb 2009 10:20:28 +0100, Thorsten Kampe wrote: >> If a "private" keyword (or equivalent) were available, then the change >> would need to be made in only one location rather than at every >> occurrence off the identifier. That is much less error prone. Sure, you >> can argue (as I'm sure someone will) that the users of the library >> should be more careful. Yes they should, but why not let the language >> help with such low-level details. That's what high-level languages are >> for. > > This scenario is highly "supposing" and doesn't look like a real-world- > case to me. You think that private attributes never become public? Encoding a "private" flag in the name is a violation of Once And Only Once. Although the OAOO principle is generally referred to when discussing code, it is more generic and applies to other things as well. You should be able to state an attribute is private *once*, not every time you use it. http://c2.com/cgi/wiki?OnceAndOnlyOnce On the other hand, encoding that private flag in the name is a variation of *sensible* Hungarian Notation, as used by the Microsoft Apps team, not the stupid version used by the Windows team. http://www.joelonsoftware.com/articles/Wrong.html So that's a point in its favour. > But anyway: the obvious solution in my humble opinion would > be to do something like "public_attribute = _private_attribute". But > that would be too simple, too "unjavaesque", right?! No, it would be too *faulty*. It simply doesn't work. Consider: class Parrot(object): _count = 0 def foo(self): print 'foo' self._count += 1 def bar(self): print "You have called foo %d times" % self._count This works as expected: >>> p = Parrot() >>> p.foo() foo >>> p.foo() foo >>> p.bar() You have called foo 2 times Now you promote count from private to public, using your "obvious solution", and try to use it: class Parrot(object): _count = 0 count = _count def foo(self): print 'foo' self._count += 1 def bar(self): print "You have called foo %d times" % self._count >>> p = Parrot() >>> p.foo() foo >>> p.count = 99 >>> p.bar() You have called foo 1 times Clearly the "obvious" solution simply isn't sufficient to get the result that you need. One solution is to just refactor the source code, so that the attribute identifier "_count" becomes "count", but beware of all the usual issues with source code refactoring. Another solution is to leave _count as it is, and create a *property* called count, not a simple attribute: count = property( lambda self: self._count, lambda self, x: setattr(self, '_count', x), None, "Public interface to private attribute _count" ) but this adds complexity to the class and will be a maintenance headache as the class' methods diverge into those that manipulate self._count directly and other methods which manipulate self.count. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Tue, 03 Feb 2009 08:45:23 -, Steven D'Aprano wrote: I find this extreme position is rather incoherent. If I may paraphrase the argument as I see it: "Enforced data hiding is useless, because it is utterly trivial to bypass it, AND it's wicked, because it makes it unbelievably painful and difficult to bypass it when you need to." If it is trivial to bypass, surely it can't be that painful to bypass? I think you haven't noticed which of the parties is shifting their ground. I'm very much of the second opinion; it was Russ who did the sudden volte face and declared that it was trivial to circumvent. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Tue, 03 Feb 2009 05:37:57 -, Russ P. wrote: On Feb 2, 7:48 pm, "Rhodri James" wrote: On Tue, 03 Feb 2009 02:16:01 -, Russ P. wrote: > Here we go again. If you have access to the source code (as you nearly > always do with Python code), then "breaking the language-enforced data > hiding" is a trivial matter of deleting the word "private" (or > equivalent). If it's that trivial to defeat something that its proponents appear to want to be close to an iron-clad guarantee, what on earth is the point of using "private" in the first place? If a library developer releases the source code of a library, any user can trivially "defeat" the access restrictions. But if a team of developers is checking in code for a project, the leader(s) of the project can insist that the access restrictions be respected to simplify the management of interfaces. The larger the team, the more useful that can be. That's why Java, C++, Ada, Scala, and other languages have a "private" keyword. Indeed he can. He can even do that in Python; it just requires a little self-discipline from the team, or a validation script on the code repository if he really doesn't trust them. Not only can this be done without forcing the rest of the world to play, it makes things a little less daunting when those nice clean interfaces turn out to be incomplete/too slow/not what you thought. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
En Mon, 02 Feb 2009 19:51:11 -0200, Russ P. escribió: Suppose a library developer (or a module developer on a large team) uses leading underscores. Now suppose that, for whatever reason (pressure from the users, perhaps), the library developer decides to change a "private" attribute to public. Now all occurrences of the identifier need to be changed. If an assignment to the previously "private" attribute is missed, no warning will be issued (because Python allows new attributes to be added anywhere, even completely outside the class definition itself). And if the library is widely used, the probability of such bugs occurring is very high. So _foo becomes foo. Then: class X(object): def get_foo(self): return self._foo def set_foo(self, value): self._foo = value foo = property(get_foo, set_foo) You have the public name "foo", for new usage outside the library, and the private name "_foo", for internal use only. And we're all happy. If it weren't for your "historical" reasons, using those trivial get/set functions is rather silly. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Quoth David Cournapeau : > On Wed, Feb 4, 2009 at 2:36 AM, wrote: > > > > Pretty much, unless maybe the code documents what you're not supposed > > to access: > > But that's my point: that's just not true for many packages I have > used - some packages do follow the _ convention, some don't. For > example, to take an example I am somewhat familiar with: distutils > does not follow this at all. There is no documentation, and it is > almost impossible to know what's the API from implementation details, > the interface is leaking everywhere. Now, distutils is an "old" > package, but my experience at least showed me that this is relatively > common. > > There are some relatively well known packages which use a different > mechanism to clearly separate the intended API, without using the _ > convention, or more exactly in supplement of it. This whole issue gets more complicated, I think, when you consider that what is "public" versus "private" in an API depends on the consumer. That is, you might have a group of modules that use a package-internal interface, while what the "outside world" is supposed to use is a more restricted API. The package-internal interface isn't _private_ in the sense of hiding things from anybody outside the class or its subclasses, but neither is it public. I won't be surprised to hear that languages with data hiding have some provision for this, but to my mind this is a "one, two, many" situation. That is, if you have one case, things are trivially simple. If you have two cases, you can differentiate them. But once you have three cases, you almost certainly have _more_ than three cases...in other words a problem in generalization. In my code I generally use _ for stuff that is class-private, and document the "outside" or "stable" API, and everything else is...whatever it needs to be. Perhaps the packages you are thinking of do something similar? --RDM -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 12:05 pm, David Cournapeau wrote: > On Wed, Feb 4, 2009 at 2:36 AM, wrote: > > On Feb 3, 1:14 am, David Cournapeau wrote: > >> On Tue, Feb 3, 2009 at 2:37 PM, Russ P. wrote: > >> > On Feb 2, 7:48 pm, "Rhodri James" wrote: > >> >> On Tue, 03 Feb 2009 02:16:01 -, Russ P. > >> >> wrote: > >> >> > Here we go again. If you have access to the source code (as you nearly > >> >> > always do with Python code), then "breaking the language-enforced data > >> >> > hiding" is a trivial matter of deleting the word "private" (or > >> >> > equivalent). > > >> >> If it's that trivial to defeat something that its proponents appear to > >> >> want to be close to an iron-clad guarantee, what on earth is the point > >> >> of using "private" in the first place? > > >> >> -- > >> >> Rhodri James *-* Wildebeeste Herder to the Masses > > >> > If a library developer releases the source code of a library, any user > >> > can trivially "defeat" the access restrictions. But if a team of > >> > developers is checking in code for a project, the leader(s) of the > >> > project can insist that the access restrictions be respected to > >> > simplify the management of interfaces. The larger the team, the more > >> > useful that can be. That's why Java, C++, Ada, Scala, and other > >> > languages have a "private" keyword. > > >> I think a lof of this "discussion" is caused by different usages of > >> private. My understanding is that you think private is missing in > >> python because there is no clear different between a member which is > >> published (part of the API) and one which is not (e.g. whose behavior > >> may change between different revisions, even minor). I agree the > >> underscore is not an ideal solution - it is certainly not followed by > >> all python code out there (not even in python itself - see distutils > >> for example). > > >> But I think you are overstating the advantage of private for that > >> usage, at least for C++. In C++, if you have a public class in a > >> header: > > >> class Foo { > >> private: > >> int f; > > >> }; > > >> It means f is private (cannot be accessed outside Foo instances), but > >> it is declared in the public header. Actually, when people means this > >> kind of 'data-hiding', C++ does not bring anything to C itself - after > >> all, we have used FILE* for years and I have no idea about the FILE > >> structure. > > > Your lack of knowledge about it doesn't mean that it has somehow > > magically "private" members. The only reason that most of us don't > > know what a FILE is is that it's definition is implementation-defined > > (i.e., every compiler may define it differently). > > > That doesn't have anything to do with private members. For example, on > > my system, defines FILE as: > > > struct _iobuf { > > char *_ptr; > > int _cnt; > > char *_base; > > int _flag; > > int _file; > > int _charbuf; > > int _bufsiz; > > char *_tmpfname; > > }; > > typedef struct _iobuf FILE; > > Hm, I guess it depends on the implementation, but it is at least > possible in C to completely hide the structure, by declaring only a > pointer, and defining the structure outside any public header file. > Then, you cannot accidentally access any member - it would result in a > compiler error. I've done that to implement ADTs (abstract data types, also known as opaque types), but it's far from optimal, mainly because: - The compiler doesn't know the size of the class/struct (since it hasn't seen its definition), so you have to provide some sort of "constructor" function that's defined in the same file in which the class/struct is defined. This function will allocate memory for the object using malloc()/new and return a pointer to it. Of course, since memory allocated using malloc()/new has to be released using free()/ delete, you also have to provide a "destructor" function that does this, and the user *always* has to call both the constructor function and the destructor function *explicitly*, which is VERY cumbersome (as opposed to C++ constructors/destructors, which are called automatically at object creation/deletion, and which you don't always need to provide unless you have to do some initialization/cleanup). - Memory allocated with malloc()/new is allocated on the heap (as opposed to variables that you simply declare locally, which are allocated on the stack), and heap memory allocation is slower than stack memory allocation (not that you have to worry about this overhead except in really high-performance applications). In short, you pay too high a price for using an object whose size isn't known at compile time. > This method is also used in C++, that's the pimpl pattern. It is used > for various purposes (avoid long compilation times when changing some > private implementation, actual data hiding), but the underlying idea > is that you hide the implementation from the public headers. That's > used
Re: is python Object oriented??
On Wed, Feb 4, 2009 at 2:36 AM, wrote: > On Feb 3, 1:14 am, David Cournapeau wrote: >> On Tue, Feb 3, 2009 at 2:37 PM, Russ P. wrote: >> > On Feb 2, 7:48 pm, "Rhodri James" wrote: >> >> On Tue, 03 Feb 2009 02:16:01 -, Russ P. >> >> wrote: >> >> > Here we go again. If you have access to the source code (as you nearly >> >> > always do with Python code), then "breaking the language-enforced data >> >> > hiding" is a trivial matter of deleting the word "private" (or >> >> > equivalent). >> >> >> If it's that trivial to defeat something that its proponents appear to >> >> want to be close to an iron-clad guarantee, what on earth is the point >> >> of using "private" in the first place? >> >> >> -- >> >> Rhodri James *-* Wildebeeste Herder to the Masses >> >> > If a library developer releases the source code of a library, any user >> > can trivially "defeat" the access restrictions. But if a team of >> > developers is checking in code for a project, the leader(s) of the >> > project can insist that the access restrictions be respected to >> > simplify the management of interfaces. The larger the team, the more >> > useful that can be. That's why Java, C++, Ada, Scala, and other >> > languages have a "private" keyword. >> >> I think a lof of this "discussion" is caused by different usages of >> private. My understanding is that you think private is missing in >> python because there is no clear different between a member which is >> published (part of the API) and one which is not (e.g. whose behavior >> may change between different revisions, even minor). I agree the >> underscore is not an ideal solution - it is certainly not followed by >> all python code out there (not even in python itself - see distutils >> for example). >> >> But I think you are overstating the advantage of private for that >> usage, at least for C++. In C++, if you have a public class in a >> header: >> >> class Foo { >> private: >> int f; >> >> }; >> >> It means f is private (cannot be accessed outside Foo instances), but >> it is declared in the public header. Actually, when people means this >> kind of 'data-hiding', C++ does not bring anything to C itself - after >> all, we have used FILE* for years and I have no idea about the FILE >> structure. > > Your lack of knowledge about it doesn't mean that it has somehow > magically "private" members. The only reason that most of us don't > know what a FILE is is that it's definition is implementation-defined > (i.e., every compiler may define it differently). > > That doesn't have anything to do with private members. For example, on > my system, defines FILE as: > > struct _iobuf { >char *_ptr; >int _cnt; >char *_base; >int _flag; >int _file; >int _charbuf; >int _bufsiz; >char *_tmpfname; >}; > typedef struct _iobuf FILE; Hm, I guess it depends on the implementation, but it is at least possible in C to completely hide the structure, by declaring only a pointer, and defining the structure outside any public header file. Then, you cannot accidentally access any member - it would result in a compiler error. This method is also used in C++, that's the pimpl pattern. It is used for various purposes (avoid long compilation times when changing some private implementation, actual data hiding), but the underlying idea is that you hide the implementation from the public headers. That's used for example by QT, and many other C++ libraries. This shows quite strongly the limitations of the whole private/public business in C++. > > Pretty much, unless maybe the code documents what you're not supposed > to access: But that's my point: that's just not true for many packages I have used - some packages do follow the _ convention, some don't. For example, to take an example I am somewhat familiar with: distutils does not follow this at all. There is no documentation, and it is almost impossible to know what's the API from implementation details, the interface is leaking everywhere. Now, distutils is an "old" package, but my experience at least showed me that this is relatively common. There are some relatively well known packages which use a different mechanism to clearly separate the intended API, without using the _ convention, or more exactly in supplement of it. David -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 1:14 am, David Cournapeau wrote: > On Tue, Feb 3, 2009 at 2:37 PM, Russ P. wrote: > > On Feb 2, 7:48 pm, "Rhodri James" wrote: > >> On Tue, 03 Feb 2009 02:16:01 -, Russ P. wrote: > >> > Here we go again. If you have access to the source code (as you nearly > >> > always do with Python code), then "breaking the language-enforced data > >> > hiding" is a trivial matter of deleting the word "private" (or > >> > equivalent). > > >> If it's that trivial to defeat something that its proponents appear to > >> want to be close to an iron-clad guarantee, what on earth is the point > >> of using "private" in the first place? > > >> -- > >> Rhodri James *-* Wildebeeste Herder to the Masses > > > If a library developer releases the source code of a library, any user > > can trivially "defeat" the access restrictions. But if a team of > > developers is checking in code for a project, the leader(s) of the > > project can insist that the access restrictions be respected to > > simplify the management of interfaces. The larger the team, the more > > useful that can be. That's why Java, C++, Ada, Scala, and other > > languages have a "private" keyword. > > I think a lof of this "discussion" is caused by different usages of > private. My understanding is that you think private is missing in > python because there is no clear different between a member which is > published (part of the API) and one which is not (e.g. whose behavior > may change between different revisions, even minor). I agree the > underscore is not an ideal solution - it is certainly not followed by > all python code out there (not even in python itself - see distutils > for example). > > But I think you are overstating the advantage of private for that > usage, at least for C++. In C++, if you have a public class in a > header: > > class Foo { > private: > int f; > > }; > > It means f is private (cannot be accessed outside Foo instances), but > it is declared in the public header. Actually, when people means this > kind of 'data-hiding', C++ does not bring anything to C itself - after > all, we have used FILE* for years and I have no idea about the FILE > structure. Your lack of knowledge about it doesn't mean that it has somehow magically "private" members. The only reason that most of us don't know what a FILE is is that it's definition is implementation-defined (i.e., every compiler may define it differently). That doesn't have anything to do with private members. For example, on my system, defines FILE as: struct _iobuf { char *_ptr; int _cnt; char *_base; int _flag; int _file; int _charbuf; int _bufsiz; char *_tmpfname; }; typedef struct _iobuf FILE; Given this information, nothing prevents me from writing things like: FILE* fp = fopen("file.txt", "r"); if (!fp) { /* do something */ } printf("fp->_cnt = %d\n", fp->cnt); printf("fp->_flag = %d\n", fp->_flag); printf("fp->_file = %d\n", fp->_file); fp->_flag = 0x20; // OOPS!! > Maybe I still lack experience, but I find neither _ prefixing nor > private/public/protected a satisfaying way to make clear what is > public API and what is not. In particular, if I have a python package > which does not use _ at all, shall I assume everything is public ? Pretty much, unless maybe the code documents what you're not supposed to access: class IOBuf: def __init__(self): self.ptr = "" # <- this is private! self.cnt = 0 # <- this is private! self.base = "" # <- this is private! self.flag = 0 # <- this is private! self.file = 0 # <- this is private! self.charbuf = 0 # <- this is private! self.bufsiz = 0 # <- this is private! self.tmpfname = "" # <- this is private! Nope, not a good idea either... -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
> Why? - Python is object oriented, but I can write whole systems > without defining a single class. > By analogy, if data hiding is added to language, I could write a > whole system without hiding a single item. I guess the problem is that you would not be able to use some libraries because their author thought that it would be wise to hide everything (a behavior fairly popular in the Java world). Let take some http library as an example, the author would certainly think that hiding the socket object is the only sane thing to do. But what if you just *have* to call that special ioctl on the socket object before it can work in your scenario... In python you can easily go under the hood if you need to do it. -- дамјан ( http://softver.org.mk/damjan/ ) "We think it's a great consumer win, and it's a great industry win, to be able to ensure that with good copy protection, you can have so much functionality for the user", Jordi Rivas, Microsoft Director of Technology -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Hendrik van Rooyen wrote: "Diez B. Roggisch" ...Sure one could envision a system where each object is running in it's micro-process. ... I would have loved a language that supported it, as well as an operating system (and I do not mean stuff like tiny os and others of that ilk), but one that really supported fast task switching to make the micro tasks less expensive on cheap little processors with scarce resources You might enjoy looking at QNX, since I think it is built along the lines you are describing here. I have an ancient copy of their OS, but haven't followed for more than couple of decades. --Scott David Daniels scott.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Steven D'Aprano a écrit : On Tue, 03 Feb 2009 03:48:58 +, Rhodri James wrote: On Tue, 03 Feb 2009 02:16:01 -, Russ P. wrote: Here we go again. If you have access to the source code (as you nearly always do with Python code), then "breaking the language-enforced data hiding" is a trivial matter of deleting the word "private" (or equivalent). If it's that trivial to defeat something that its proponents appear to want to be close to an iron-clad guarantee, what on earth is the point of using "private" in the first place? Well, that is a good question. Since it is even more trivial to defeat Python's private-by-convention data hiding, why even bother? Just make everything public. What on earth is the point of prefixing an attribute with an underscore? To make clear it is *not* part of the API. The point is about enforced access restriction, not encapsulation. I think this debate has a lot to do with people's attitudes towards "No User Serviceable Parts". Some people are comfortable using black-boxes, and if (enforced) data hiding makes it easier for others to build safe, efficient black-boxes, then they're willing to give up that a little bit of flexibility/freedom for the benefit of safe, efficient black-boxes. Others prefer white-boxes, and are willing to give up some safety and efficiency, and live with increased risk and lower performance, just in case some day they might want to open up the white-box and replace the widget with a gadget. I don't see how this relates to efficiency. Some of us consider that a black-box sealed with regular Phillips head screws is still be an effective black-box. And most of us here go as far as considering that something as simple as a "warranty broke if unsealed" label is enough. It's not hard to find a screw driver and open the box, but it's still an effective barrier against casual and accidental tinkering while allowing deliberate tinkering. Idem for a label. You *see* it, don't you ? So you cannot pretend you "accidentaly" opened the box. Others take the attitude that anything short of resistance to oxy torches and diamond-tipped drills might as well be in a paper bag, and therefore there's no point to black-boxes at all. straw-man argument once again. No one here says taht there's no point to black-box - just that there's no point having to resort to any special screw-driver if and when we want to treat it as a white box. I find this extreme position is rather incoherent. It's *your* oversimplification of the point against *enforced* access restriction that makes it incoherent. (snip) Another extreme position is that enforced data hiding is useless, that there is *never* any need for it *at all*, and therefore Python doesn't need it, there's no reason except stupid PHB's belief in cargo-cult coding why Python couldn't be used for controlling nuclear reactors or the Space Shuttle. There may be quite a lot of reasons to think (rightly or not) that Python is not suited for such tasks. Anyway, I personnaly don't care whether Python would be the right tool for such cases, because - like probably more than 99.99% of Python users - that's not what I'm using it for, and I don't see any reason to add such useless arbitrary restrictions just because 2 or 3 persons claims that it's "how it should be". FWIW, since anything dynamic would be considered unsafe in the mentioned use cases, the next point would be to make Python as static as Java. Yeah, great. There's been some claims remarkably close to that in this or the previous thread. I trust that nobody really believes this extreme position -- it's not that far off claiming that procedures and functions are pointless and stupid because we have GOTO. yet another straw man argument. I love Python, and I'm greedy and want it all: I want a dynamic, easy-to- use language *and* a compiler that can protect me from myself That's not what compilers are for. and bad data. I definitly fail to see how a compiler could protect you from *runtime* issues ??? I'm envious of Haskell's type-inference. I want the option to have the compiler warn me when some function is messing with my classes' internals as soon as I hit Enter, May I remind you that "def" and "class" are executable statements ? I'm not going to *demand* the choice of white-box or black-box classes. I don't have the right to demand anything. But I can ask, I can try to make my case (to those who will listen), and I refuse to be brow-beaten by those who think Python is Just About Perfect Just The Way It Is into feeling *ashamed* for wanting that choice. It's not about Python being "Just About Perfect Just The Way It", it's about deciding whether enforced access restriction is of any use (at least for a very large majority of it's users), and if it's worth imposing design changes so fundamuntal they would just turn Python into a totally different language just because
Re: is python Object oriented??
* Marco Mariani (Tue, 03 Feb 2009 10:42:06 +0100) > Thorsten Kampe wrote: > > This scenario is highly "supposing" and doesn't look like a > > real-world- case to me. But anyway: the obvious solution in my > > humble opinion would be to do something like "public_attribute = > > _private_attribute". But that would be too simple, too > > "unjavaesque", right?! > > Yes, the use of @property is.. cheating!! Shame on you! :) "Decorators", right? Never used that, but I read about it... Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Thorsten Kampe wrote: This scenario is highly "supposing" and doesn't look like a real-world- case to me. But anyway: the obvious solution in my humble opinion would be to do something like "public_attribute = _private_attribute". But that would be too simple, too "unjavaesque", right?! Yes, the use of @property is.. cheating!! Shame on you! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
* thmpsn@gmail.com (Mon, 2 Feb 2009 09:02:13 -0800 (PST)) > On Feb 2, 2:55 am, Stephen Hansen wrote: > > > This is proven > > > by your statement above, whereby you are driving a user away, > > > simply because the language, in one small aspect, does not > > > give him what he wants, and the tenor of this thread has been > > > very much: "That's how it is - like it or lump it", and no amount > > > of careful explanation of why people want the feature has cut > > > any ice - > > > > I'm missing the careful explanation. What I've heard is that the lack > > of enforced encapsulation is "a danger". What I've heard is that > > people want it because they've been told they should want it and > > believe that. Why? > > Who has said the latter? Are you just trying to spread FUD? No, he's not. He's giving his and other people's impression of the pro- private group's arguments. They construct cases that do not exist in reality or can more-than-easily be avoided. > > There have been no "careful explanations" to answer that, in my mind. > > And thus my response is: the practical possibility of needing access > > vastly outweights the theoretical situation that might go bad if > > encapsulation wasn't there. Why? Because in any real situation, IMHO, > > *forced* encapsulation is pointless. > > I think you've gotten too subjective on this matter. You might as well > say that we don't need no stinkin' OOP, we could all just be > programming with goto's. It's even simpler: "don't use other people's underscores". It couldn't get more simple than that. > > > It has all the time been countered with statements > > > about how the proponents of private attributes "don't need it", > > > (as if they are plain dumb), > > > > They don't need it. No one has shown a *real* reason why. The only > > reasons provided are "its a DANGER" that someone "MIGHT DO BAD". > > That's not a real reason. If its your project that someone is doing > > bad in, this is a situation which can be *clearly* specified in a > > projects policy and coding standards and can be *trivially* tested for > > with simple static analysis in nearly all cases. The problem is the > > person and not the code then. There's *countless* other ways that > > person can do bad if you're allowing them to commit blindly anything > > into your project. > > Aha! I see this attitude quite often among C/C++ people, regarding > buffer overflows and uninitialized pointer dereferences: someone will > say "C and C++ are unsafe languages because they allow you to overrun > buffers", then a C/C++ zealot will respond "Hire some good > programmers". > > SAME ATTITUDE. Not at all. Buffer overflows cannot be easily avoided in C/C++ like languages. On the contrary you can easily avoid other people's privates by simply not using their underscores. It's really that simple. Even I got that - and I'm a really simple guy. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
* Russ P. (Mon, 2 Feb 2009 13:51:11 -0800 (PST)) > On Feb 2, 9:02 am, thmpsn@gmail.com wrote: > Several participants here keep repeating that the leading-underscore > convention is perfectly adequate. Aside from the aesthetic problem of > littering code with leading underscores, let me try to explain the > problem with leading underscores. A leading underscore is not an aesthetic problem - while I would agree that /multiple/ leading or trailing underscores are. > Suppose a library developer (or a module developer on a large team) > uses leading underscores. Now suppose that, for whatever reason > (pressure from the users, perhaps), the library developer decides to > change a "private" attribute to public. Now all occurrences of the > identifier need to be changed. If an assignment to the previously > "private" attribute is missed, no warning will be issued (because > Python allows new attributes to be added anywhere, even completely > outside the class definition itself). And if the library is widely > used, the probability of such bugs occurring is very high. > > If a "private" keyword (or equivalent) were available, then the change > would need to be made in only one location rather than at every > occurrence off the identifier. That is much less error prone. Sure, > you can argue (as I'm sure someone will) that the users of the library > should be more careful. Yes they should, but why not let the language > help with such low-level details. That's what high-level languages are > for. This scenario is highly "supposing" and doesn't look like a real-world- case to me. But anyway: the obvious solution in my humble opinion would be to do something like "public_attribute = _private_attribute". But that would be too simple, too "unjavaesque", right?! Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 3, 12:45 am, Steven D'Aprano wrote: > Another extreme position is that enforced data hiding is useless, that > there is *never* any need for it *at all*, and therefore Python doesn't > need it, there's no reason except stupid PHB's belief in cargo-cult > coding why Python couldn't be used for controlling nuclear reactors or > the Space Shuttle. There's been some claims remarkably close to that in > this or the previous thread. My recollection is that several people have said exactly that in no uncertain terms, if not in this thread then in the one a few days ago. > I trust that nobody really believes this > extreme position -- it's not that far off claiming that procedures and > functions are pointless and stupid because we have GOTO. If nobody believes it, several participants here could have fooled me. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Tue, 03 Feb 2009 03:48:58 +, Rhodri James wrote: > On Tue, 03 Feb 2009 02:16:01 -, Russ P. > wrote: > >> Here we go again. If you have access to the source code (as you nearly >> always do with Python code), then "breaking the language-enforced data >> hiding" is a trivial matter of deleting the word "private" (or >> equivalent). > > If it's that trivial to defeat something that its proponents appear to > want to be close to an iron-clad guarantee, what on earth is the point > of using "private" in the first place? Well, that is a good question. Since it is even more trivial to defeat Python's private-by-convention data hiding, why even bother? Just make everything public. What on earth is the point of prefixing an attribute with an underscore? I think this debate has a lot to do with people's attitudes towards "No User Serviceable Parts". Some people are comfortable using black-boxes, and if (enforced) data hiding makes it easier for others to build safe, efficient black-boxes, then they're willing to give up that a little bit of flexibility/freedom for the benefit of safe, efficient black-boxes. Others prefer white-boxes, and are willing to give up some safety and efficiency, and live with increased risk and lower performance, just in case some day they might want to open up the white-box and replace the widget with a gadget. Some of us consider that a black-box sealed with regular Phillips head screws is still be an effective black-box. It's not hard to find a screw driver and open the box, but it's still an effective barrier against casual and accidental tinkering while allowing deliberate tinkering. Others take the attitude that anything short of resistance to oxy torches and diamond-tipped drills might as well be in a paper bag, and therefore there's no point to black-boxes at all. I find this extreme position is rather incoherent. If I may paraphrase the argument as I see it: "Enforced data hiding is useless, because it is utterly trivial to bypass it, AND it's wicked, because it makes it unbelievably painful and difficult to bypass it when you need to." If it is trivial to bypass, surely it can't be that painful to bypass? Another extreme position is that enforced data hiding is useless, that there is *never* any need for it *at all*, and therefore Python doesn't need it, there's no reason except stupid PHB's belief in cargo-cult coding why Python couldn't be used for controlling nuclear reactors or the Space Shuttle. There's been some claims remarkably close to that in this or the previous thread. I trust that nobody really believes this extreme position -- it's not that far off claiming that procedures and functions are pointless and stupid because we have GOTO. (The restrictions on GOTOs is analogous to enforced data hiding. We give up the freedom and flexibility to jump into the middle of arbitrary pieces of code in order to write safer and more maintainable code.) But as I wrote once before, it is very liberating to program in Python, and put responsibility for dealing with errors onto the caller. Let them call your methods with invalid arguments, let them mess with your internals, if it breaks, it's their responsibility! Except when it isn't. And that's when I'd like to be able to lock my classes down and enforce data hiding. Not all the time, because I do like white-boxes, but sometimes a black-box is the right choice, or the necessary choice, and if that makes development harder, then that's a cost I'm willing to pay. If I'm not willing to pay it, then I'll leave it as a nice, open, transparent white-box with easily messed-with internals and let the caller deal with the consequences of messing with the internals. Whether you agree with that choice or not is irrelevant. *My* code, *my* choice: it's my decision to write code as a black-box or a white-box, just like it's my choice to use a BSD license or the GPL or a closed- source proprietary license, or to make the class mutable or immutable. If other people don't like my choices, well, you have lots of options: you can sub-class, you can delegate, you can use somebody else's class, you can write your own class, you can do without, you can fork the source code, you can make do with it the way it is, or you can complain to the Salvation Army[1] about how I'm ruining your programming experience by being too strict/not strict enough. I love Python, and I'm greedy and want it all: I want a dynamic, easy-to- use language *and* a compiler that can protect me from myself and bad data. I'm envious of Haskell's type-inference. I want the option to have the compiler warn me when some function is messing with my classes' internals as soon as I hit Enter, and not to have to remember to run some third-party tool. I'm not going to *demand* the choice of white-box or black-box classes. I don't have the right to demand anything. But I can ask, I can try to make my case (to th
Re: is python Object oriented??
"Diez B. Roggisch" > Your argument would be valid if *any* of the *languages* implementing > encapsulation would offer that real isolation. None does. So where from > comes the feeling that this must be something a *language* should offer? > > Sure one could envision a system where each object is running in it's > micro-process. So far, this hasn't been implemented (to the best of my > knowledge) - so making assertions about the feasibility & robustness for > running as well as for developing are somewhat "airy", don't you think? No. Not airy. Hairy, yes. I suppose the language is a kind of wish list on my part - I have spent the last twenty years or so writing stuff like this on small processors, in assembler, and I would have loved a language that supported it, as well as an operating system (and I do not mean stuff like tiny os and others of that ilk), but one that really supported fast task switching to make the micro tasks less expensive on cheap little processors with scarce resources. (8031) I have written various flavours of my own, (pre emptive, round robin, cooperative) and they all suffer from the speed troubles associated with task switching on that architecture, but in all cases the performance was good enough to get the job done. Most of the stuff really did follow a dataflow model as I have described, but its all so inextricably intertwined with the hardware and the requirements of the different jobs that it feels kind of hopeless to try to extract general principles from it, except for obvious stuff like that it works better if your queues are formal and robust, and that the messages must contain everything that is required to get the job done. If you do this, then there is really no reason to worry about how some other thing is doing it's job. In fact if you find yourself peeking at the other task's innards, then it means you have to rethink the dataflow, because you are on the wrong track - that is what I meant when I talk of "granularity" I have find that code re use, between different projects, has in my case been limited to some parts of: - Task switching code - The ticker structure to interface to hardware - Queues, buffers and memory management. - Utility functions like some simple math and string handling. Anyway this is getting a bit far away from the python way, which does not strictly enforce the 'Pure Path' (Tm) of: - have loose objects as threads/processes - send messages between them using clever queueing So we are extremely unlikely to agree on the importance of enforced data hiding. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Stephen Hansen wrote: 8< - arguments I don't agree with - >P.S. Aiee, this discussion is getting overwhelmingly long. :) It is indeed and I do actually have other stuff to do so I shall try to retreat with defiant dignity. Been fun though, to see the other viewpoints when it started getting serious. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Tue, Feb 3, 2009 at 2:37 PM, Russ P. wrote: > On Feb 2, 7:48 pm, "Rhodri James" wrote: >> On Tue, 03 Feb 2009 02:16:01 -, Russ P. wrote: >> > Here we go again. If you have access to the source code (as you nearly >> > always do with Python code), then "breaking the language-enforced data >> > hiding" is a trivial matter of deleting the word "private" (or >> > equivalent). >> >> If it's that trivial to defeat something that its proponents appear to >> want to be close to an iron-clad guarantee, what on earth is the point >> of using "private" in the first place? >> >> -- >> Rhodri James *-* Wildebeeste Herder to the Masses > > If a library developer releases the source code of a library, any user > can trivially "defeat" the access restrictions. But if a team of > developers is checking in code for a project, the leader(s) of the > project can insist that the access restrictions be respected to > simplify the management of interfaces. The larger the team, the more > useful that can be. That's why Java, C++, Ada, Scala, and other > languages have a "private" keyword. I think a lof of this "discussion" is caused by different usages of private. My understanding is that you think private is missing in python because there is no clear different between a member which is published (part of the API) and one which is not (e.g. whose behavior may change between different revisions, even minor). I agree the underscore is not an ideal solution - it is certainly not followed by all python code out there (not even in python itself - see distutils for example). But I think you are overstating the advantage of private for that usage, at least for C++. In C++, if you have a public class in a header: class Foo { private: int f; }; It means f is private (cannot be accessed outside Foo instances), but it is declared in the public header. Actually, when people means this kind of 'data-hiding', C++ does not bring anything to C itself - after all, we have used FILE* for years and I have no idea about the FILE structure. Maybe I still lack experience, but I find neither _ prefixing nor private/public/protected a satisfaying way to make clear what is public API and what is not. In particular, if I have a python package which does not use _ at all, shall I assume everything is public ? cheers, David -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 7:48 pm, "Rhodri James" wrote: > On Tue, 03 Feb 2009 02:16:01 -, Russ P. wrote: > > Here we go again. If you have access to the source code (as you nearly > > always do with Python code), then "breaking the language-enforced data > > hiding" is a trivial matter of deleting the word "private" (or > > equivalent). > > If it's that trivial to defeat something that its proponents appear to > want to be close to an iron-clad guarantee, what on earth is the point > of using "private" in the first place? > > -- > Rhodri James *-* Wildebeeste Herder to the Masses If a library developer releases the source code of a library, any user can trivially "defeat" the access restrictions. But if a team of developers is checking in code for a project, the leader(s) of the project can insist that the access restrictions be respected to simplify the management of interfaces. The larger the team, the more useful that can be. That's why Java, C++, Ada, Scala, and other languages have a "private" keyword. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Quoting "Russ P." : > I know ... changing one word constitutes a "fork." Yeah, right. Yeah, right. > You can't be bothered to change one word, but the library developer should > be required to litter his code with leading underscores everywhere, No, instead they will have to litter his code with "private" keywords. (So now this is about laziness and not wanting to type "_"? The argument gets weirder and weirder) > and large development teams should depend on labor intensive code > reviews for checks that could be automated by the language. Or, by already existing third party tools that you insist on ignoring. > (And, please ... I am not suggesting that enforced access restrictions > would render code reviews unnecessary, but it could certainly simplify > them.) Please, tell, how does it having the checks on the interpreter will simplify them more than having the checks on an external tool? -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Tue, 03 Feb 2009 02:16:01 -, Russ P. wrote: Here we go again. If you have access to the source code (as you nearly always do with Python code), then "breaking the language-enforced data hiding" is a trivial matter of deleting the word "private" (or equivalent). If it's that trivial to defeat something that its proponents appear to want to be close to an iron-clad guarantee, what on earth is the point of using "private" in the first place? -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On 2009-02-02, Russ P. wrote: > I am not sure why people keep "mentioning" that "Python is not > Java." As a slogan, it is rather misleading. Because other people keep insisting that it ought to be. > Python is not C++, Ada, or Scala either. All of those > languages have enforced access restriction. Why only mention > Java? It's often mentioned that Python is not C++ as well. People who know Ada or Scala presumably have a varied enough background that they find no need insist that all languages must do things the same way as language X does. -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 4:35 pm, "Rhodri James" wrote: > This really, really, *really* isn't a tangent. It's the heart of > the matter. You are advocating a change that doesn't fit with > Python's "consenting adults" approach to programming. It's trivial > to enforce hiding using static checking tools if you really feel the > need to not trust yourself; it's much harder (though by no means > impossible) to break language-enforced hiding when (not if) an > interface turns out to be inadequate. Here we go again. If you have access to the source code (as you nearly always do with Python code), then "breaking the language-enforced data hiding" is a trivial matter of deleting the word "private" (or equivalent). I know ... changing one word constitutes a "fork." Yeah, right. You can't be bothered to change one word, but the library developer should be required to litter his code with leading underscores everywhere, and large development teams should depend on labor intensive code reviews for checks that could be automated by the language. (And, please ... I am not suggesting that enforced access restrictions would render code reviews unnecessary, but it could certainly simplify them.) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
"Russ P." writes: > I am not sure why people keep "mentioning" that "Python is not Java." > As a slogan, it is rather misleading. Python is not C++, Ada, or Scala > either. All of those languages have enforced access restriction. Why > only mention Java? Because Java is a well-known member of a family of object-oriented languages (or at least languages supporting object-oriented programming). `Python is not Java' is somewhat of a slogan, intended to convey the message that Python, quite intentionally, does not behave in the same way as other languages you may be familiar with. Smalltalk's visibility features are very different from C++ and Java: a method can mess with its own object's (i.e., the recipient of the message which caused the method to be invoked) instance variables but no others -- a restriction enforced syntactically, since there is simply no way of referring to a different instance's variables. There is no restriction whatever on sending messages to other objects. Self abandons the concept of instance variable (and of class, for that matter), and access controls with it. The Common Lisp Object System provides no access control features (though one could probably implement some using the MOP, were one sufficiently motivated); however, CL's package system is better placed for this job anyway. Other object systems for Lisp-family languages tend to be similar. The Lisp Machine's Flavors -- the first object system with multiple inheritance -- relied on the package system for access control; CLOS-like systems for Scheme, which lacks packages, tend not to bother at all. (The package system controls the mapping from tokens read from, say, files to symbols; packages can export some of their symbols, so you can refer to, say, MDW:FOO if package MDW exports symbol FOO, or you can `use' package MDW in your own package to make FOO refer to MDW:FOO. The package system tries to keep you honest rather than acting as an enforcement mechanism: even if MDW doesn't export BAR, you can still talk about MDW::BAR -- note the double-colon -- as much as you like. Working at the name-to-symbol level allows the package system to operate uniformly on all the various namespaces in Lisp.) Perl's object system provides no access controls. Ruby does, following Simula, though it uses C++-ish `private' for Simula's `hidden'. > If that's the case, you have my sympathies, but let's not pretend that > Java is the only popular OO language with enforced access > restrictions. No, but let's not pretend either that such features are essential to object orientation, or that they are even typical of object systems outside of a particular (admittedly popular) subfamily. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Mon, 02 Feb 2009 13:54:08 -, Hendrik van Rooyen wrote: wrote: PS: More accurately, Python _embodies_ a philosophy, and to advocate changes that go against that philosophy is to advocate changing Python into something that would no longer be Python. You can do that, but you aren't likely to get the community to follow you. *sits on his hands to try to avoid the tangent, with the gaping hole of religion looming beneath the spiderweb of philosophy, and the language spec gathering dust in the corner, forgotten and forlorn* This really, really, *really* isn't a tangent. It's the heart of the matter. You are advocating a change that doesn't fit with Python's "consenting adults" approach to programming. It's trivial to enforce hiding using static checking tools if you really feel the need to not trust yourself; it's much harder (though by no means impossible) to break language-enforced hiding when (not if) an interface turns out to be inadequate. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
2009/2/2 Russ P. : > On Feb 2, 2:46 pm, Tim Rowe wrote: >> No, we're supposed to believe that the designers of C++, Java, Ada, >> and Scala are all designers of languages that are not Python. If all >> languages had the same philosophy what would be the point of different >> languages? Is it worth mentioning (again) that Python is not Java? >> >> -- >> Tim Rowe > > I am not sure why people keep "mentioning" that "Python is not Java." Because Java is the language that folks most offen insist Python become like. > As a slogan, it is rather misleading. Python is not C++, Ada, or Scala > either. All of those languages have enforced access restriction. Why > only mention Java? You might notice that I also mentioned C++, Ada and Scala. > their wishes. If that's the case, you have my sympathies, but let's > not pretend that Java is the only popular OO language with enforced > access restrictions. You might notice (again) that I also mentioned C++, Ada and Scala. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Mon, Feb 2, 2009 at 4:51 PM, Russ P. wrote: > On Feb 2, 9:02 am, thmpsn@gmail.com wrote: > > On Feb 2, 2:55 am, Stephen Hansen wrote: > > > > > > This is proven > > > > by your statement above, whereby you are driving a user away, > > > > simply because the language, in one small aspect, does not > > > > give him what he wants, and the tenor of this thread has been > > > > very much: "That's how it is - like it or lump it", and no amount > > > > of careful explanation of why people want the feature has cut > > > > any ice - > > > > > I'm missing the careful explanation. What I've heard is that the lack > > > of enforced encapsulation is "a danger". What I've heard is that > > > people want it because they've been told they should want it and > > > believe that. Why? > > > > Who has said the latter? Are you just trying to spread FUD? > > > > > There have been no "careful explanations" to answer that, in my mind. > > > And thus my response is: the practical possibility of needing access > > > vastly outweights the theoretical situation that might go bad if > > > encapsulation wasn't there. Why? Because in any real situation, IMHO, > > > *forced* encapsulation is pointless. > > > > I think you've gotten too subjective on this matter. You might as well > > say that we don't need no stinkin' OOP, we could all just be > > programming with goto's. > > > > Sure, hey, let's do OOP in C, using structs, POD STRUCTS (), and > > PLAIN FUNCTIONS () > > > > Heck, why do we even need OOP?? Long live procedural!! > > > > We don't even need no stinkin programming languages, we could just > > program using 1's and 0's! > > > > What's with this luddite attitude, Python community? > > > > > > It has all the time been countered with statements > > > > about how the proponents of private attributes "don't need it", > > > > (as if they are plain dumb), > > > > > They don't need it. No one has shown a *real* reason why. The only > > > reasons provided are "its a DANGER" that someone "MIGHT DO BAD". > > > That's not a real reason. If its your project that someone is doing > > > bad in, this is a situation which can be *clearly* specified in a > > > projects policy and coding standards and can be *trivially* tested for > > > with simple static analysis in nearly all cases. The problem is the > > > person and not the code then. There's *countless* other ways that > > > person can do bad if you're allowing them to commit blindly anything > > > into your project. > > > > Aha! I see this attitude quite often among C/C++ people, regarding > > buffer overflows and uninitialized pointer dereferences: someone will > > say "C and C++ are unsafe languages because they allow you to overrun > > buffers", then a C/C++ zealot will respond "Hire some good > > programmers". > > > > SAME ATTITUDE. > > I couldn't agree more. > > As I said before, as an aeronautical engineer I don't know if enforced > access restriction can be added to Python without compromising or > unduly complicating the language. Maybe it can't. If that's the case, > then people should make that argument. But just saying that enforced > access restriction is useless in general is nonsense. Are we supposed > to believe that the designers of C++, Java, Ada, and Scala are all > idiots? > > Several participants here keep repeating that the leading-underscore > convention is perfectly adequate. Aside from the aesthetic problem of > littering code with leading underscores, let me try to explain the > problem with leading underscores. > > Suppose a library developer (or a module developer on a large team) > uses leading underscores. Now suppose that, for whatever reason > (pressure from the users, perhaps), the library developer decides to > change a "private" attribute to public. Now all occurrences of the > identifier need to be changed. If an assignment to the previously > "private" attribute is missed, no warning will be issued (because > Python allows new attributes to be added anywhere, even completely > outside the class definition itself). And if the library is widely > used, the probability of such bugs occurring is very high. 1. This would be a great spot to use a property. Problem solved. 2. Unit tests. Lots of unit tests. 3. Pylint will check for uninitialized fields. It won't stop you from running the code obviously, but it will notify you if you forgot to change something. 4. Find/Replace. Takes the effort out of looking for the places to change the name. [long argument for private keyword] > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 2:46 pm, Tim Rowe wrote: > 2009/2/2 Russ P. : > > > Are we supposed > > to believe that the designers of C++, Java, Ada, and Scala are all > > idiots? > > No, we're supposed to believe that the designers of C++, Java, Ada, > and Scala are all designers of languages that are not Python. If all > languages had the same philosophy what would be the point of different > languages? Is it worth mentioning (again) that Python is not Java? > > -- > Tim Rowe I am not sure why people keep "mentioning" that "Python is not Java." As a slogan, it is rather misleading. Python is not C++, Ada, or Scala either. All of those languages have enforced access restriction. Why only mention Java? For the record, I have never used Java, nor do I have any desire to ever use it. That is why I am intrigued by the apparent obsession with it here. I suspect that many programmers are forced to use against their wishes. If that's the case, you have my sympathies, but let's not pretend that Java is the only popular OO language with enforced access restrictions. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Monday 02 February 2009 04:51:11 pm Russ P. wrote: > As I said before, as an aeronautical engineer I don't know if enforced > access restriction can be added to Python without compromising or > unduly complicating the language. Maybe it can't. If that's the case, > then people should make that argument. But just saying that enforced > access restriction is useless in general is nonsense. Are we supposed > to believe that the designers of C++, Java, Ada, and Scala are all > idiots? I'm amazed at how quickly this thread degenerated into another 'enforced data hiding' thread. I think the previous one ran long enough for me to actually say that 'access restriction is nonsense', when my point had been '_enforced_ access restrictions in python is worthless in all the examples provided so far' (except perhaps the extensions modules, but those are not python). You are an aeronautical engineer. You, and I understand that, don't want, shouldn't want, and will not want to run anything you cannot trust. You want the most assurances you can get. You are well within your right to want that - to disallow in your systems, and in the systems that you build, anything that you even suspect that may threaten the integrity of the system, and let's face it, breaking the encapsulation, intentional or not, is pretty suspicious. So, in current python, _you_ have the _choice_ of preventing it. As the checks are static, of course, you can break them in runtime, just like you would in C, C++ and Java. But somehow, it is not enough for you that you have the choice, because that also gives _me_ the choice of _not_ doing it in my own systems. And you still haven't said why it bothers you that I have the choice. Now, if you were arguing for [truly optional - as in, the user decides] dynamic checks, you may see a very different position. That RExec and Bastion even existed should tell you that there is interest on implementing some kind of trusted execution (as in 'I trust this code to do whatever it wants, but not this other code'). That both projects failed should tell you that either it is impossible to achieve in python (which would be bad), or that there is just not enough interest on keeping them (which would not amaze me). But, if you are arguing for dynamic checks, those are not present in C++ either, and thus, it isn't really what you mean with enforced data hiding. > If an assignment to the previously > "private" attribute is missed, no warning will be issued (because > Python allows new attributes to be added anywhere, even completely > outside the class definition itself). And if the library is widely > used, the probability of such bugs occurring is very high. Good coding standards would prevent that. And by good coding standards, I mean "treat pylint and similar tools as a requirement before executing any code", and it will catch that sort of bugs. Again, _you_ have the choice. Use it if you wish. Now, I'm with you in that accidental variable creation is a nasty side effect of python dynamism (and that you may be forfeiting it if you go the pylint route). But that particular complaint has nothing to do with enforced vs not-enforced data hiding, and everything to do with static typing. And mind you, must of us who use python, do so _because_ of the dynamism and not in spite of it. Funny thing is, you have the choice, _now, today_, of having your precious static checks, both of them, for your projects. But you keep complaining because I also have the choice, and I may chose not to have them. -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
2009/2/2 Russ P. : > Are we supposed > to believe that the designers of C++, Java, Ada, and Scala are all > idiots? No, we're supposed to believe that the designers of C++, Java, Ada, and Scala are all designers of languages that are not Python. If all languages had the same philosophy what would be the point of different languages? Is it worth mentioning (again) that Python is not Java? -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 9:02 am, thmpsn@gmail.com wrote: > On Feb 2, 2:55 am, Stephen Hansen wrote: > > > > This is proven > > > by your statement above, whereby you are driving a user away, > > > simply because the language, in one small aspect, does not > > > give him what he wants, and the tenor of this thread has been > > > very much: "That's how it is - like it or lump it", and no amount > > > of careful explanation of why people want the feature has cut > > > any ice - > > > I'm missing the careful explanation. What I've heard is that the lack > > of enforced encapsulation is "a danger". What I've heard is that > > people want it because they've been told they should want it and > > believe that. Why? > > Who has said the latter? Are you just trying to spread FUD? > > > There have been no "careful explanations" to answer that, in my mind. > > And thus my response is: the practical possibility of needing access > > vastly outweights the theoretical situation that might go bad if > > encapsulation wasn't there. Why? Because in any real situation, IMHO, > > *forced* encapsulation is pointless. > > I think you've gotten too subjective on this matter. You might as well > say that we don't need no stinkin' OOP, we could all just be > programming with goto's. > > Sure, hey, let's do OOP in C, using structs, POD STRUCTS (), and > PLAIN FUNCTIONS () > > Heck, why do we even need OOP?? Long live procedural!! > > We don't even need no stinkin programming languages, we could just > program using 1's and 0's! > > What's with this luddite attitude, Python community? > > > > It has all the time been countered with statements > > > about how the proponents of private attributes "don't need it", > > > (as if they are plain dumb), > > > They don't need it. No one has shown a *real* reason why. The only > > reasons provided are "its a DANGER" that someone "MIGHT DO BAD". > > That's not a real reason. If its your project that someone is doing > > bad in, this is a situation which can be *clearly* specified in a > > projects policy and coding standards and can be *trivially* tested for > > with simple static analysis in nearly all cases. The problem is the > > person and not the code then. There's *countless* other ways that > > person can do bad if you're allowing them to commit blindly anything > > into your project. > > Aha! I see this attitude quite often among C/C++ people, regarding > buffer overflows and uninitialized pointer dereferences: someone will > say "C and C++ are unsafe languages because they allow you to overrun > buffers", then a C/C++ zealot will respond "Hire some good > programmers". > > SAME ATTITUDE. I couldn't agree more. As I said before, as an aeronautical engineer I don't know if enforced access restriction can be added to Python without compromising or unduly complicating the language. Maybe it can't. If that's the case, then people should make that argument. But just saying that enforced access restriction is useless in general is nonsense. Are we supposed to believe that the designers of C++, Java, Ada, and Scala are all idiots? Several participants here keep repeating that the leading-underscore convention is perfectly adequate. Aside from the aesthetic problem of littering code with leading underscores, let me try to explain the problem with leading underscores. Suppose a library developer (or a module developer on a large team) uses leading underscores. Now suppose that, for whatever reason (pressure from the users, perhaps), the library developer decides to change a "private" attribute to public. Now all occurrences of the identifier need to be changed. If an assignment to the previously "private" attribute is missed, no warning will be issued (because Python allows new attributes to be added anywhere, even completely outside the class definition itself). And if the library is widely used, the probability of such bugs occurring is very high. If a "private" keyword (or equivalent) were available, then the change would need to be made in only one location rather than at every occurrence off the identifier. That is much less error prone. Sure, you can argue (as I'm sure someone will) that the users of the library should be more careful. Yes they should, but why not let the language help with such low-level details. That's what high-level languages are for. Several people have argued that an advantage of the leading-underscore convention is that it tells you at every occurrence of the identifier that it is private. Of course, the leading-underscore convention could still be used even in combination with enforced access restriction. But the larger point is this: that is like saying that global parameters should be repeated as literal numbers at every occurrence so the user can see the value instantly. Sure, that saves you the trouble of looking up the value when you need to know it, but it also requres that any change must be carefully made at every location. No competent p
Re: is python Object oriented??
> > > > that an underscore convention is > > > "just as good", (It isn't), > > > > Why isn't it? > > Because it needs human intervention. > Not necessarily at all: that's something that could be checked very readily with static analysis. Why isn't that a good enough tool if policy isn't sufficient? If you scan the code for "._" and target is not "self", and is not a magic method, then I think that is an encapsulation error. I don't know that Pylint or the various other flavors of analysis tools have an option to check for that, but wouldn't adding one be better then changing the language? That way those who want it get the certainty that encapsulation is never broken, and those who don't care don't have to worry about it. > > > > that you could crack it if you really > > > tried, (so what?), > > > > Exactly.. so what? WHY is the convention not enough? What REAL > > situation is there that the lack of *forced* encapsulation but policy > > based encapsulation not enough? > > > > See human intervention above - and as for > "real, forced data hiding" - have you ever > coded anything that produced a segmentation fault? > [ snip discussion of processor memory protection ] That's apples to... potatoes. I'm not opposed to memory protection :) Segmentation faults and memoy protection are an utterly different thing. One protects against a programmer accidentally going in and overwriting something that he shouldn't, when he doesn't even know he's doing it. The other protects against a programmer *intentionally* and *explicitly* going into source code and finding an undocumented internal detail to *intentionally* change it for some specific purpose. One stops someone from making a mistake. The other stops someone from doing something they /intend/ on doing. (Both may have an impact on someone with malicious intent, but that's a whole other subject) --S P.S. Aiee, this discussion is getting overwhelmingly long. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
> The reason is that I see a level of abstraction that makes it kind of > irrelevant whether something is run as a process, a thread, a time > multiplexed mainloop, on one or more processors, wherever or > whatever - almost like a fractal structure spread across the total > addressable space - and I would like to use the same rules > everywhere. And if there are reasons for forced encapsulation > *somewhere*, then it is more elegant (to my taste) to allow it > *everywhere*. - and conversely, of course. Hence the rather > *an der Haare herbeigezogen* (see ** below) argument > based on the forced restrictions in processors. Your argument would be valid if *any* of the *languages* implementing encapsulation would offer that real isolation. None does. So where from comes the feeling that this must be something a *language* should offer? Sure one could envision a system where each object is running in it's micro-process. So far, this hasn't been implemented (to the best of my knowledge) - so making assertions about the feasibility & robustness for running as well as for developing are somewhat "airy", don't you think? > Given this approach, there is no reason whatever for anything > to mess with any other thing's innards - in fact the less you know > about it, the more robust and predictable the system becomes. For a certain, very limited definition of robustness & predictability. As much as I like my OS not to go down, it's nothing that helps me to accomplish my actual goal using it if the software running on top of it crashes. From this POV, a chain is always only as strong as it's weakest member. And that might well be one of your encapsulated components. > And in embedded processes, there exist things that are time > critical, that are designed to be used in one way, and no other, > and that can have serious consequences if messed with- when > I have started moving the 100 tonne mass, then I *cannot* tolerate > other code changing my timeouts or speeds or feeds in an arbitrary > fashion - EXPENSIVE noises will result. Embedded programming most often even offers the memory protection one needs to make the "real" encapsulation, due to hardware restrictions. And even if it did, it won't help you with memory corruption that occurs in process. Which is of course a re-iteration of my argument. Again: the expensive noises haven't been avoided because of encapsulation. They might be the product of expensive testruns, either by trial-and-error, or by review. Not by encapsulation. >> I've seen a lot of programs segfault that are written in C++ with data >> encapsulation. And also a lot of them that overcame the restrictions the >> compiler or even runtime in java imposed on them, either by >> pointer-magic, or through some available backdoors that have been put in >> place for good reasons. > > I think that segfaulting is basically caused by programming error - > By the inability of the programmer actually to understand the > limitations of the compiler to "do what I mean". > > Encapsulation or data hiding will never "cure" that, because > at best it could move some of the errors from runtime to > compile time. > > I doubt the "good reasons for backdoors" part - I think that comes > from a design that has either not been done, or used, at the correct > level of granularity. > >> So far I haven't seen any argument for forced data encapsulation that >> went beyond a matter of personal taste. That's fine, but also just that. > > This could be true, and if it is, we are just beating our heads one > against the other, trying to win non existent prizes for pig-headedness. > > I could also turn that argument around, as well as stating it stronger: > > So far I have not seen any argument in favour of free access to > the internals of another piece of code that is based on ANY necessity, > (beside a handwaving "good reasons" ) or that goes beyond a matter > of personal taste based on a hacker's glee in meddling in somebody > else's code. The argument as apparent in Python: ducktyping is used everyday, to all our benefit. And every piece of code that only works precisely because it was possible to access the innards of some other piece of code is an example and a reason to allow it. You might say that these things are showing a lack of proper design - but the point is that design is a question of perspective, and a otherwise useful piece of code is rendered useless because of encapsulation if that prevents the usage from a new perspective the original author didn't think of. That's my stance on this, and as a coder, I want to (re)use code, not work around it. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com a écrit : On Feb 2, 2:55 am, Stephen Hansen wrote: This is proven by your statement above, whereby you are driving a user away, simply because the language, in one small aspect, does not give him what he wants, and the tenor of this thread has been very much: "That's how it is - like it or lump it", and no amount of careful explanation of why people want the feature has cut any ice - I'm missing the careful explanation. What I've heard is that the lack of enforced encapsulation is "a danger". What I've heard is that people want it because they've been told they should want it and believe that. Why? Who has said the latter? Are you just trying to spread FUD? There have been no "careful explanations" to answer that, in my mind. And thus my response is: the practical possibility of needing access vastly outweights the theoretical situation that might go bad if encapsulation wasn't there. Why? Because in any real situation, IMHO, *forced* encapsulation is pointless. I think you've gotten too subjective on this matter. > You might as well say that we don't need no stinkin' OOP, we could all just be programming with goto's. Sure, hey, let's do OOP in C, using structs, POD STRUCTS (), and PLAIN FUNCTIONS () Aren't you going a bit over the board here ? No need to go mad nor scream at us. (snip usual stuff about lack of access restriction perceived as dangerous or whatever - cargo cult, really...). -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 2:55 am, Stephen Hansen wrote: > > This is proven > > by your statement above, whereby you are driving a user away, > > simply because the language, in one small aspect, does not > > give him what he wants, and the tenor of this thread has been > > very much: "That's how it is - like it or lump it", and no amount > > of careful explanation of why people want the feature has cut > > any ice - > > I'm missing the careful explanation. What I've heard is that the lack > of enforced encapsulation is "a danger". What I've heard is that > people want it because they've been told they should want it and > believe that. Why? Who has said the latter? Are you just trying to spread FUD? > There have been no "careful explanations" to answer that, in my mind. > And thus my response is: the practical possibility of needing access > vastly outweights the theoretical situation that might go bad if > encapsulation wasn't there. Why? Because in any real situation, IMHO, > *forced* encapsulation is pointless. I think you've gotten too subjective on this matter. You might as well say that we don't need no stinkin' OOP, we could all just be programming with goto's. Sure, hey, let's do OOP in C, using structs, POD STRUCTS (), and PLAIN FUNCTIONS () Heck, why do we even need OOP?? Long live procedural!! We don't even need no stinkin programming languages, we could just program using 1's and 0's! What's with this luddite attitude, Python community? > > It has all the time been countered with statements > > about how the proponents of private attributes "don't need it", > > (as if they are plain dumb), > > They don't need it. No one has shown a *real* reason why. The only > reasons provided are "its a DANGER" that someone "MIGHT DO BAD". > That's not a real reason. If its your project that someone is doing > bad in, this is a situation which can be *clearly* specified in a > projects policy and coding standards and can be *trivially* tested for > with simple static analysis in nearly all cases. The problem is the > person and not the code then. There's *countless* other ways that > person can do bad if you're allowing them to commit blindly anything > into your project. Aha! I see this attitude quite often among C/C++ people, regarding buffer overflows and uninitialized pointer dereferences: someone will say "C and C++ are unsafe languages because they allow you to overrun buffers", then a C/C++ zealot will respond "Hire some good programmers". SAME ATTITUDE. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Hendrik: > > I wonder why the designers of processors do such silly things as having > > user and supervisor modes in the hardware - according to your > > arguments a code review would solve the problem, and then they > > could use the silicon saved to do other usefull stuff. - then any process > > could use any instruction, and it would be all right. - easy to manage > > out of the project - you just have to scan the object code for op codes > > that you have decided are dangerous (for whatever stupid reason). > Diez: > This is comparing apples to oranges. Forced data encapsulation or not take > place *inside one process*. So this whole argument is a straw-man. I do not agree with this, but then I won't will I? The reason is that I see a level of abstraction that makes it kind of irrelevant whether something is run as a process, a thread, a time multiplexed mainloop, on one or more processors, wherever or whatever - almost like a fractal structure spread across the total addressable space - and I would like to use the same rules everywhere. And if there are reasons for forced encapsulation *somewhere*, then it is more elegant (to my taste) to allow it *everywhere*. - and conversely, of course. Hence the rather *an der Haare herbeigezogen* (see ** below) argument based on the forced restrictions in processors. I see almost any piece of code that "does something" as a black box that has inputs and outputs - and I like to string them together in a style that resembles a systolic array - closer to unix piping , based on true queueing and message passing, where it becomes at all practical. Given this approach, there is no reason whatever for anything to mess with any other thing's innards - in fact the less you know about it, the more robust and predictable the system becomes. And in embedded processes, there exist things that are time critical, that are designed to be used in one way, and no other, and that can have serious consequences if messed with- when I have started moving the 100 tonne mass, then I *cannot* tolerate other code changing my timeouts or speeds or feeds in an arbitrary fashion - EXPENSIVE noises will result. > I've seen a lot of programs segfault that are written in C++ with data > encapsulation. And also a lot of them that overcame the restrictions the > compiler or even runtime in java imposed on them, either by pointer-magic, > or through some available backdoors that have been put in place for good > reasons. I think that segfaulting is basically caused by programming error - By the inability of the programmer actually to understand the limitations of the compiler to "do what I mean". Encapsulation or data hiding will never "cure" that, because at best it could move some of the errors from runtime to compile time. I doubt the "good reasons for backdoors" part - I think that comes from a design that has either not been done, or used, at the correct level of granularity. > So far I haven't seen any argument for forced data encapsulation that went > beyond a matter of personal taste. That's fine, but also just that. This could be true, and if it is, we are just beating our heads one against the other, trying to win non existent prizes for pig-headedness. I could also turn that argument around, as well as stating it stronger: So far I have not seen any argument in favour of free access to the internals of another piece of code that is based on ANY necessity, (beside a handwaving "good reasons" ) or that goes beyond a matter of personal taste based on a hacker's glee in meddling in somebody else's code. :-) - Hendrik ** -*an der Haare herbeigezogen* German, literally "drawn closer by the hair" expression denoting either a specious argument or a forced analogy. Sorry, but I could think of no English equivalent. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
wrote: > Quoth "Hendrik van Rooyen" : > > Now there are a LOT of dicey statements in the above passionate > > plea - python is a language, and not a philosophy, but I won't go > > into that, as that would lead off onto a tangent, of which there have > > been a surfeit in this thread. > > Ah, now I understand. This is where you part company from the > people you are arguing against. > > Python _is_ a philosophy. > > There is no smiley after that statement. :) > > --RDM > > PS: More accurately, Python _embodies_ a philosophy, and to advocate > changes that go against that philosophy is to advocate changing > Python into something that would no longer be Python. You can do > that, but you aren't likely to get the community to follow you. *sits on his hands to try to avoid the tangent, with the gaping hole of religion looming beneath the spiderweb of philosophy, and the language spec gathering dust in the corner, forgotten and forlorn* :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
wrote: > Quoth "Hendrik van Rooyen" : > > wrote: > > > > > > > > You, sir, should be programming in some language other than Python. 8<- reasons given > > This is IMO an arrogant attitude - > > My apologies!! There was a smiley missing from the end of that statement > above. However, you are right, even with the smiley added it would > still be arrogant, and I regret that. It was not actually aimed at you personally - more of a rant about the intolerance displayed by the "it's fine as it is" group. > > The problem is that there is a fundamental philosophical divide here, > and I don't think the advocates on either side are going to convince > the other. It certaintly looks like that - so far it has produced more heat than light, and very few funny comments > > This debate has happened many times. > So why are we dumb enough to repeat it? :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Quoth "Hendrik van Rooyen" : > Now there are a LOT of dicey statements in the above passionate > plea - python is a language, and not a philosophy, but I won't go > into that, as that would lead off onto a tangent, of which there have > been a surfeit in this thread. Ah, now I understand. This is where you part company from the people you are arguing against. Python _is_ a philosophy. There is no smiley after that statement. :) --RDM PS: More accurately, Python _embodies_ a philosophy, and to advocate changes that go against that philosophy is to advocate changing Python into something that would no longer be Python. You can do that, but you aren't likely to get the community to follow you. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Quoth "Hendrik van Rooyen" : > wrote: > > > > > You, sir, should be programming in some language other than Python. > > Why? - Python is object oriented, but I can write whole systems > without defining a single class. > By analogy, if data hiding is added to language, I could write a > whole system without hiding a single item. > Conversely, the lack of data hiding is perceived as a weakness, > and IMO harms the advocacy of the language - This is proven > by your statement above, whereby you are driving a user away, > simply because the language, in one small aspect, does not > give him what he wants, and the tenor of this thread has been > very much: "That's how it is - like it or lump it", and no amount > of careful explanation of why people want the feature has cut > any ice - It has all the time been countered with statements > about how the proponents of private attributes "don't need it", > (as if they are plain dumb), that an underscore convention is > "just as good", (It isn't), that you could crack it if you really > tried, (so what?), and other more specious reasons. > > This is IMO an arrogant attitude - My apologies!! There was a smiley missing from the end of that statement above. However, you are right, even with the smiley added it would still be arrogant, and I regret that. The problem is that there is a fundamental philosophical divide here, and I don't think the advocates on either side are going to convince the other. This debate has happened many times. --RDM -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
> I wonder why the designers of processors do such silly things as having > user and supervisor modes in the hardware - according to your > arguments a code review would solve the problem, and then they > could use the silicon saved to do other usefull stuff. - then any process > could use any instruction, and it would be all right. - easy to manage > out of the project - you just have to scan the object code for op codes > that you have decided are dangerous (for whatever stupid reason). This is comparing apples to oranges. Forced data encapsulation or not take place *inside one process*. So this whole argument is a straw-man. I've seen a lot of programs segfault that are written in C++ with data encapsulation. And also a lot of them that overcame the restrictions the compiler or even runtime in java imposed on them, either by pointer-magic, or through some available backdoors that have been put in place for good reasons. So far I haven't seen any argument for forced data encapsulation that went beyond a matter of personal taste. That's fine, but also just that. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
"Stephen Hansen" wrote: 8<--- arguments for the status quo -- > > I'm missing the careful explanation. What I've heard is that the lack > of enforced encapsulation is "a danger". What I've heard is that > people want it because they've been told they should want it and > believe that. Why? > > Part of my lack of understanding might be because people couldn't read > my previous messages because my mail client's configuration > accidentally got fubar'd and I was sending HTML mail instead of plain > text. But my question remains: Why do you need forced encapsulation? > > There have been no "careful explanations" to answer that, in my mind. > And thus my response is: the practical possibility of needing access > vastly outweights the theoretical situation that might go bad if > encapsulation wasn't there. Why? Because in any real situation, IMHO, > *forced* encapsulation is pointless. > > If you are writing end-level code, you can achieve forced > encapsulation by simply not playing with anyones privates. If you are > in a corporate environment who has rules about accessing privates > written by another team for valid reasons, your policy to not do so > should be enough or your review process should pick it up. If you are > in an open source environment accepting patches from various people, > you should have a clear policy about the subject if you think breaking > encapsulation is never acceptable and refuse the patches. Those who > have commit access and violate encapsulation anyways against your > projects policy are problems that you clearly need to deal with. The > problem is not the language at that point, its the contributor. > > > > It has all the time been countered with statements > > about how the proponents of private attributes "don't need it", > > (as if they are plain dumb), > > They don't need it. No one has shown a *real* reason why. The only Repeating it, (despite my assertion lately in another thread) does not make it true - what follows is simply an opinion on how to solve the problem "by management", instead of providing a different tool. > reasons provided are "its a DANGER" that someone "MIGHT DO BAD". > That's not a real reason. If its your project that someone is doing > bad in, this is a situation which can be *clearly* specified in a > projects policy and coding standards and can be *trivially* tested for > with simple static analysis in nearly all cases. The problem is the > person and not the code then. There's *countless* other ways that > person can do bad if you're allowing them to commit blindly anything > into your project. > > If its your projet which someone else is using, and accessing your > internals that are clearly private and not documented: its not your > problem if they stab themselves in the foot. On the contrary, why in > the name of all that is holy, do you care if they manipulate your > internals at their own risk, at their own cost, and achieve something > positive for them? How in any way does this hurt you? > > > > that an underscore convention is > > "just as good", (It isn't), > > Why isn't it? Because it needs human intervention. > > > that you could crack it if you really > > tried, (so what?), > > Exactly.. so what? WHY is the convention not enough? What REAL > situation is there that the lack of *forced* encapsulation but policy > based encapsulation not enough? > See human intervention above - and as for "real, forced data hiding" - have you ever coded anything that produced a segmentation fault? I wonder why the designers of processors do such silly things as having user and supervisor modes in the hardware - according to your arguments a code review would solve the problem, and then they could use the silicon saved to do other usefull stuff. - then any process could use any instruction, and it would be all right. - easy to manage out of the project - you just have to scan the object code for op codes that you have decided are dangerous (for whatever stupid reason). Another example out of the processor world is the fact that some modern processors actually force a process to keep in its own memory. What temerity! Who do these idiots think they are to try to keep "me" from accessing "your" memory - after all, I have a good reason - (I'm inquisitive) This is of course rather more difficult to pick up in a code review, as I could easily calculate the address, which makes it not immediately apparent that I will access something not belonging to me. And seeing that Python is not dynamic at all, there is no analogy here... > > Surely if "we are all adults here" we have to accept that the > > other man has as much right to get what he wants, as > > anybody else, and that his reasons are as valid as those of > > anybody else. > > Yes., We're all consenting adults. > > But if one adult decides to make rules that the other doesn't agree > to, is that consenting adults, or is that rape? I apologize for the > use o
Re: is python Object oriented??
Rhodri James a écrit : On Sun, 01 Feb 2009 17:31:27 -, Steve Holden wrote: Stephen Hansen wrote: [...] don't play with anyone else's privates. A good rule in life as well as programming. Unless, of course, you're both consenting adults. What? Someone had to say it! Indeed. Thanks for this useful clarification !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com a écrit : (snip) Anyway, it doesn't matter. We're losing the point here. The point is that language support for private access, by disallowing user access to private data, provides an unambiguous information hiding mechanism which encourages encapsulation. Python's approach, however, which is only a naming convention rather than a language feature, merely TRUSTS the programmer not to break encapsulation. And sure, if we're all good programmers, everything will go well and we'll end up with an organized application. But the danger is still there: at any given time, we COULD break encapsulation! Oh, my, What a shock! What a nightmare. Thanks, thanks thmpsn for opening our eyes. How can we have lived so many years with this permanent danger, and yet managed to write working, robust programs, I really wonder. Good God, we really need to fix this immediatly, because obviously, TRUSTING the programmer JUST CANT WORK. Or can it ? this-dead-horse-has-been-beaten-to-hell-and-back-pity-the-poor-animal-ly'yrs -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Michael Torrie a écrit : Steve Holden wrote: You can think what you like, but there is a fundamental difference between methods of a class and functions of a module. Until you appreciate that you will likely make mistakes. Don't worry, though, we all learn from our mistakes. And this fundamental difference is? That a method is bound to a class and (usually) an instance of this class. From what I can tell an instance method is an object that encapsulates the function object in a closure s/closure/object/ that makes sure it has a reference to "self." the method object is instanciated by the function object itself when it is looked up upon a class or instance (thanks to the descriptor protocol). It (the method object) stores the function, the class and (if bound) the instance as attributes, and it's __call__ method takes care of calling the function with the instance as first positional argument. I know that you dynamically add functions to objects creating methods dynamically, by using new.instancemethod or something. Or simply by manually invoking the descriptor protocol: def func(self): print "self is", self class Foo(object): pass f = Foo() f.func = func.__get__(f, type(f)) print dir(f.func) This seems to indicate to me that there are functions and there are functions. Methods are in fact functions, just with a callable wrapper around them. Methods *are* the callable wrapper around functions - so they can't be functions themselves. From this POV, the functions wrapped by methods are actually the *implementation* of the method. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
>> >> You, sir, should be programming in some language other than Python. > > Why? - Python is object oriented, but I can write whole systems > without defining a single class. > By analogy, if data hiding is added to language, I could write a > whole system without hiding a single item. > Conversely, the lack of data hiding is perceived as a weakness, > and IMO harms the advocacy of the language - This is an alarming statement. Advocacy should advocate the language-- it must not define the language. If a fundamental principle of the language harms the advocacy of the language: then the problem is not with the language but the advocacy. If you are going to advocate a thing: advocate that thing. Don't try to change that thing into what it is not so as to make your advocacy the end-goal. One of the reasons I love Python is because its practical first. It begins with its license, which some people argue allows companies to steal effort from its developers to use for their own purposes without contributing back. The Python license is about empowering people to accomplish things, to do things. It goes further. Guido and the core developers ask real questions: would this add a burden to practical use, or would it hinder another practical use? > This is proven > by your statement above, whereby you are driving a user away, > simply because the language, in one small aspect, does not > give him what he wants, and the tenor of this thread has been > very much: "That's how it is - like it or lump it", and no amount > of careful explanation of why people want the feature has cut > any ice - I'm missing the careful explanation. What I've heard is that the lack of enforced encapsulation is "a danger". What I've heard is that people want it because they've been told they should want it and believe that. Why? Part of my lack of understanding might be because people couldn't read my previous messages because my mail client's configuration accidentally got fubar'd and I was sending HTML mail instead of plain text. But my question remains: Why do you need forced encapsulation? There have been no "careful explanations" to answer that, in my mind. And thus my response is: the practical possibility of needing access vastly outweights the theoretical situation that might go bad if encapsulation wasn't there. Why? Because in any real situation, IMHO, *forced* encapsulation is pointless. If you are writing end-level code, you can achieve forced encapsulation by simply not playing with anyones privates. If you are in a corporate environment who has rules about accessing privates written by another team for valid reasons, your policy to not do so should be enough or your review process should pick it up. If you are in an open source environment accepting patches from various people, you should have a clear policy about the subject if you think breaking encapsulation is never acceptable and refuse the patches. Those who have commit access and violate encapsulation anyways against your projects policy are problems that you clearly need to deal with. The problem is not the language at that point, its the contributor. > It has all the time been countered with statements > about how the proponents of private attributes "don't need it", > (as if they are plain dumb), They don't need it. No one has shown a *real* reason why. The only reasons provided are "its a DANGER" that someone "MIGHT DO BAD". That's not a real reason. If its your project that someone is doing bad in, this is a situation which can be *clearly* specified in a projects policy and coding standards and can be *trivially* tested for with simple static analysis in nearly all cases. The problem is the person and not the code then. There's *countless* other ways that person can do bad if you're allowing them to commit blindly anything into your project. If its your projet which someone else is using, and accessing your internals that are clearly private and not documented: its not your problem if they stab themselves in the foot. On the contrary, why in the name of all that is holy, do you care if they manipulate your internals at their own risk, at their own cost, and achieve something positive for them? How in any way does this hurt you? > that an underscore convention is > "just as good", (It isn't), Why isn't it? > that you could crack it if you really > tried, (so what?), Exactly.. so what? WHY is the convention not enough? What REAL situation is there that the lack of *forced* encapsulation but policy based encapsulation not enough? > Surely if "we are all adults here" we have to accept that the > other man has as much right to get what he wants, as > anybody else, and that his reasons are as valid as those of > anybody else. Yes., We're all consenting adults. But if one adult decides to make rules that the other doesn't agree to, is that consenting adults, or is that rape? I apologize for the use of the term, but "consenting adults" has particul
Re: is python Object oriented??
wrote: > > You, sir, should be programming in some language other than Python. Why? - Python is object oriented, but I can write whole systems without defining a single class. By analogy, if data hiding is added to language, I could write a whole system without hiding a single item. Conversely, the lack of data hiding is perceived as a weakness, and IMO harms the advocacy of the language - This is proven by your statement above, whereby you are driving a user away, simply because the language, in one small aspect, does not give him what he wants, and the tenor of this thread has been very much: "That's how it is - like it or lump it", and no amount of careful explanation of why people want the feature has cut any ice - It has all the time been countered with statements about how the proponents of private attributes "don't need it", (as if they are plain dumb), that an underscore convention is "just as good", (It isn't), that you could crack it if you really tried, (so what?), and other more specious reasons. This is IMO an arrogant attitude - Surely if "we are all adults here" we have to accept that the other man has as much right to get what he wants, as anybody else, and that his reasons are as valid as those of anybody else. Somehow I don't think that the way this thread has run, is the way to "win friends and influence people" - not positively, anyway. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 2, 4:10 am, Stephen Hansen wrote: > Anyway, it doesn't matter. We're losing the point here. The point is > that language support for private access, by disallowing user access > to private data, provides an unambiguous information hiding mechanism > which encourages encapsulation. Python's approach, however, which is > only a naming convention rather than a language feature, merely TRUSTS > the programmer not to break encapsulation. And sure, if we're all good > programmers, everything will go well and we'll end up with an > organized application. But the danger is still there: at any given > time, we COULD break encapsulation! > > > I was long-winded the last time I responded to this point so no one probably > read it :) Yes, we read it. You made good points!! Cheers, Hung -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Steven D'Aprano wrote: > On Sun, 01 Feb 2009 12:31:27 -0500, Steve Holden wrote: > >> I think it's noticeable that the people who have been arguing against >> what I might tipify as this "libertarian view" are those for whom the >> consequences of programming error are serious to extreme. > ... >> Just the same, it still doesn't save them from the consequences of >> interface miscommunication, as int he case of the Mars lander that >> crashed because one module provided a (probably strongly-typed) value in >> meters, and the recipient interpreted it as (probably strongly-typed) >> feet, cutting the engine out too early. > > Of course. Nor will data hiding prevent off-by-one errors, or errors of > logic, or data corruption, or stray cosmic rays flipping bits in memory. > But it will prevent *some* errors. It's one tool in an entire toolbox for > writing correct code, not a magic bullet. > > Python already has enforced data hiding, but only for built-ins. > Consequently, anyone who uses a list can absolutely, categorically trust > that len(alist) will return the actual length of alist, and not some > mangled value stuffed into alist by some arbitrary piece of code > somewhere else. > Unless, of course, some piece of code masks (or worse still, replaces) the len() function in __builtins__ with one of their own. There's no such thing as a foolproof system. The minute you think you have one the world comes up with a superior class of fool. > (For those unaware, in CPython lists are arrays. They store the current > length as a private value inaccessible to Python code.) > > Short of cosmic rays flipping bits, any built-in list you receive from > anywhere is going to have a valid length, and no pure-Python code can > make it invalid. To read some of the posts in this thread, one would be > forgiven for thinking that this most be a disaster of the highest > consequences, unPythonic to the extreme, an example of unfree B&D > programming so unpleasant to work with that people hate every second of > it. > > Except of course it isn't. Nobody sensibly complains that they can't > mangle the length of a list, or move keys around inside dicts, or > whatever. This data hiding is a good thing. > > All I want is the ability to do with Python classes what I can do with C > extension types. I don't think that's an *unreasonable* ask, even if it > is *unpractical* given the current design of Python. > I think the whole issue has received far more attention than is good for it. Your requirements seem quite reasonable to me, even though I doubt I'd ever use them. But it isn't *me* you have to persuade to get them in the language, is it? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Rhodri James wrote: > On Sun, 01 Feb 2009 17:31:27 -, Steve Holden > wrote: > >> Stephen Hansen wrote: >>> [...] >>> don't play with anyone else's >>> privates. >>> >> A good rule in life as well as programming. > > Unless, of course, you're both consenting adults. > > What? Someone had to say it! > Nearly included it myself, but decided not to deny someone else the simple pleasure of posting it :) regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sunday 01 February 2009 08:00:18 pm Steven D'Aprano wrote: > On Sun, 01 Feb 2009 12:31:27 -0500, Steve Holden wrote: > Except of course it isn't. Nobody sensibly complains that they can't > mangle the length of a list, or move keys around inside dicts, or > whatever. This data hiding is a good thing. If lists and dictionaries were not C types, and python didn't have to shield us from the mess that is C and its pointers, that enforcement may not be such a good thing. And, while we are at it, that is not python having "selective" enforcement of data hiding but only for C, that's C/C++ having data hiding and not exporting the attributes back to python. > All I want is the ability to do with Python classes what I can do with C > extension types. I don't think that's an *unreasonable* ask, even if it > is *unpractical* given the current design of Python. Well, then. Do you want dynamic checks? Go fix Bastion/rexec (that would be a _good_ thing, valuable for way more than data hiding). Or do you want static checks? In that case, you have it already. -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sun, 01 Feb 2009 12:31:27 -0500, Steve Holden wrote: > I think it's noticeable that the people who have been arguing against > what I might tipify as this "libertarian view" are those for whom the > consequences of programming error are serious to extreme. ... > Just the same, it still doesn't save them from the consequences of > interface miscommunication, as int he case of the Mars lander that > crashed because one module provided a (probably strongly-typed) value in > meters, and the recipient interpreted it as (probably strongly-typed) > feet, cutting the engine out too early. Of course. Nor will data hiding prevent off-by-one errors, or errors of logic, or data corruption, or stray cosmic rays flipping bits in memory. But it will prevent *some* errors. It's one tool in an entire toolbox for writing correct code, not a magic bullet. Python already has enforced data hiding, but only for built-ins. Consequently, anyone who uses a list can absolutely, categorically trust that len(alist) will return the actual length of alist, and not some mangled value stuffed into alist by some arbitrary piece of code somewhere else. (For those unaware, in CPython lists are arrays. They store the current length as a private value inaccessible to Python code.) Short of cosmic rays flipping bits, any built-in list you receive from anywhere is going to have a valid length, and no pure-Python code can make it invalid. To read some of the posts in this thread, one would be forgiven for thinking that this most be a disaster of the highest consequences, unPythonic to the extreme, an example of unfree B&D programming so unpleasant to work with that people hate every second of it. Except of course it isn't. Nobody sensibly complains that they can't mangle the length of a list, or move keys around inside dicts, or whatever. This data hiding is a good thing. All I want is the ability to do with Python classes what I can do with C extension types. I don't think that's an *unreasonable* ask, even if it is *unpractical* given the current design of Python. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sun, 01 Feb 2009 17:31:27 -, Steve Holden wrote: Stephen Hansen wrote: [...] don't play with anyone else's privates. A good rule in life as well as programming. Unless, of course, you're both consenting adults. What? Someone had to say it! -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Quoth thmpsn@gmail.com: > Anyway, it doesn't matter. We're losing the point here. The point is > that language support for private access, by disallowing user access > to private data, provides an unambiguous information hiding mechanism > which encourages encapsulation. Python's approach, however, which is > only a naming convention rather than a language feature, merely TRUSTS > the programmer not to break encapsulation. And sure, if we're all good > programmers, everything will go well and we'll end up with an > organized application. But the danger is still there: at any given > time, we COULD break encapsulation! You, sir, should be programming in some language other than Python. --RDM -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Stephen Hansen wrote: > [...] > don't play with anyone else's > privates. > A good rule in life as well as programming. > The *idea* of encapsulation is good in many cases, it is quite often a > solid design point and admirable goal. The *implementation* of enforced > data encapsulation brings no value to any realistic situation. > I think it's noticeable that the people who have been arguing against what I might tipify as this "libertarian view" are those for whom the consequences of programming error are serious to extreme. I think we might have to accept that they are never going to be comfortable with Python as it's currently constituted, whether or not we suggest that discipline might replace enforcement. Just the same, it still doesn't save them from the consequences of interface miscommunication, as int he case of the Mars lander that crashed because one module provided a (probably strongly-typed) value in meters, and the recipient interpreted it as (probably strongly-typed) feet, cutting the engine out too early. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Quoting thmpsn@gmail.com: > > Or ``#define private public`` before including the header files. Which > > doesn't look complicated to me. > > Which again won't always work, if: > > (a) the header defines another macro, say, "PRIVATE", as "private", > and uses PRIVATE to declare private members [other reasons deleted] So, can I assume that most of the C++ code out there defines "PRIVATE" as "private" just to prevent breaking the encapsulation _intentionally_? Somehow I find that hard to believe. > Anyway, it doesn't matter. We're losing the point here. The point is > that language support for private access, by disallowing user access > to private data, provides an unambiguous information hiding mechanism > which encourages encapsulation. And Python, by providing a well defined convention of what is inaccessible, provides an unambiguous information hiding mechanism wich encourages encapsulation. > Python's approach, however, which is > only a naming convention rather than a language feature, merely TRUSTS > the programmer not to break encapsulation. And sure, if we're all good > programmers, everything will go well and we'll end up with an > organized application. But the danger is still there: at any given > time, we COULD break encapsulation! And what's the problem with that, exactly? I can break encapsulation... and I can jump off my roof. Why do _you_ care about what _I_ can do, as long as it doesn't harm _you_ (or others)? If you are worried about you breaking encapsulation, then just don't do it. It is not hard. Whenever you find yourself typing "._somehting", just check that the string before the dot is "self". If you can't trust yourself to access only the well identified "public" attributes, how can you trust that you will just not make "public" a private attribute anyway? -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Anyway, it doesn't matter. We're losing the point here. The point is that language support for private access, by disallowing user access to private data, provides an unambiguous information hiding mechanism which encourages encapsulation. Python's approach, however, which is only a naming convention rather than a language feature, merely TRUSTS the programmer not to break encapsulation. And sure, if we're all good programmers, everything will go well and we'll end up with an organized application. But the danger is still there: at any given time, we COULD break encapsulation! I was long-winded the last time I responded to this point so no one probably read it :)But to be concise: So what?If you believe encapsulation should never be broken: don't do it! If your corporation believes encapsulation should never be broken, the code review process (you do have one right?) will catch it and you can fire the person for not following policy. If your open source project believes encapsulation should never be broken, the code review process (you do have one right?) will catch it and you can chastise for not following policy and reject the patch. There is no actual "danger". The convention is unambiguous. If you believe encapsulation should be absolute, you can have that very easily: don't play with anyone else's privates.The *idea* of encapsulation is good in many cases, it is quite often a solid design point and admirable goal. The *implementation* of enforced data encapsulation brings no value to any realistic situation.--S signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Feb 1, 1:50 am, Marc 'BlackJack' Rintsch wrote: > On Sat, 31 Jan 2009 15:28:14 -0800, thmpsn.m.k wrote: > > On Jan 31, 2:27 pm, Christian Heimes wrote: > >> Do you honestly believe that C++'s private members are really private? > >> Privateness is only enforced during parsing time. Nobody can stop you > >> from messing around with header files or memory. You can still access > >> and modify private members but it's all messy and ugly. Even C# and > >> .NET don't stop you from doing nasty things from unmananged assemblies. > > > I don't know how you would do it in C# (or Java for that matter). > > In Java you can use reflection to get your fingers on private fields. > > > In C++ you can play with pointers to "get at" some memory location > > somewhere in the object. > > [Snipped pointer fiddling explanation] > > So: Sometimes it may work, usually it will be unsafe and/or non- > > portable, and in most cases the procedure will look complicated. > > Or ``#define private public`` before including the header files. Which > doesn't look complicated to me. Which again won't always work, if: (a) the header defines another macro, say, "PRIVATE", as "private", and uses PRIVATE to declare private members (b) the members are preceded with neither "private:" nor "public:" nor "protected:", in which case they'll be private by default (c) someone else suggested that point (b) is defeated by defining a macro named "class" as "struct", which will make members public by default; well, we can do something similar to what we did in point (a): define a macro, say, "CLASS", as "class", and use CLASS the define the class Anyway, it doesn't matter. We're losing the point here. The point is that language support for private access, by disallowing user access to private data, provides an unambiguous information hiding mechanism which encourages encapsulation. Python's approach, however, which is only a naming convention rather than a language feature, merely TRUSTS the programmer not to break encapsulation. And sure, if we're all good programmers, everything will go well and we'll end up with an organized application. But the danger is still there: at any given time, we COULD break encapsulation! -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
David Bolen wrote: thmpsn@gmail.com writes: I don't know how you would do it in C# (or Java for that matter). In C++ you can play with pointers to "get at" some memory location somewhere in the object. The only portable way to know the exact location between the beginning of the object and the desired member is the offsetof() macro, but as I understand it this only works for POD types, which means that it won't work for classes such as: class NonPOD { private: int a; int b; public: NonPOD(); ~NonPOD(); int C(); }; (I haven't ever actually tried it, so I'm not sure.) Nevertheless, you can play and hope for the best. For example, if the member you want to get at is 'b', then you can do: NonPOD obj; std::cout << "obj.b = " << *(int*) ((unsigned char*) &obj + sizeof (int)) << std::endl; and hope that the compiler didn't leave a hole between the 'a' member and the 'b' member. Probably moving off topic, but I don't think you have to get anywhere near that extreme in terms of pointers, unless you're trying to deal with instances for which you have no source but only opaque pointers. I haven't gotten stuck having to do this myself yet, but I believe one commmon "hack" for the sort of class you show above is to just "#define private public" before including the header file containing the class definition. No fiddling with pointers, offsets, or whatever, just normal object access syntax past that point. Of course, I believe such a redefinition violates the letter of the C++ standard, but most preprocessors do it anyway. Also, it won't handle the case where the "private:" is not used, but the members are just declared prior to any other definition, since a class is private by default. [snip] You can also "#define class struct" before including the header file. The only difference between 'class' and 'struct' in C++ is that the members of a class are private by default and the members of a struct are public by default. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sat, Jan 31, 2009 at 9:08 AM, wrote: > On Jan 30, 12:15 am, Chris Rebert wrote: >> - Python supports encapsulation. Prefixing an attribute/method with an >> underscore indicates that other programmers should treat it as >> 'private'. However, unlike B&D languages, Python itself does nothing >> to enforce this privacy, leaving it instead to the good judgement of >> the programmer, under the philosophy that "We're all consenting adults >> here". > > How do you know? (I know I'm not.) > > Seriously, though, the lack of private members does allow for ugly > hacks in user code, and you know there are always ugly hackers. Marc already addressed your points excellently, but I'll add that I once read somewhere (can't be bothered to find the source, PG maybe?) that mediocre programming languages are designed for average programmers and presume the language designers are smarter than the programmer, whereas the truly great languages are designed for great programmers and presume that the programmer is smarter than (or at least knows better than) the designer. This allows smart programmers using great languages to say: "I don't like X about the language, I think I'll change it" or "The language needs Y, I'll add it". For example, see the amazing magic some Python people have worked using metaclasses. Whereas smart programmers using a mediocre language are stuck: "I don't like X about the language and there's nothing I can do about it short of hacking the language implementation. Darn. Now I'm going to have to write Y lines every time I want to workaround X since the language doesn't let me factor the solution out any further! (sigh)". For example, consider looping through an array in Java before the new 'for' statement was added. Therefore, Python wisely chooses to not give a damn about how "ugly hackers" may abuse the language; they'll abuse *any* language they get their grubby mitts on; just let them and their ugly code quietly rot in the corner while the elite are allowed by the language the extra leeway they need to write their code masterpieces, which the common people can then use to improve their programs. Not that I'm saying any of us are necessarily elite; just don't be /particularly/ stupid by using anything *clearly marked* with an initial underscore without *extremely* good reason. And this isn't to say the language shouldn't take average programmers into account; just don't overly restrict the the 90% that are decent programmers in the name of trying to save the bottom 10% from themselves (it's rather like the "Save the Children!" retort on /.) Cheers, Chris -- Follow the path of the Iguana... http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sat, 31 Jan 2009 09:08:25 -0800, thmpsn.m.k wrote: > On Jan 30, 12:15 am, Chris Rebert wrote: >> - Python supports encapsulation. Prefixing an attribute/method with an >> underscore indicates that other programmers should treat it as >> 'private'. However, unlike B&D languages, Python itself does nothing to >> enforce this privacy, leaving it instead to the good judgement of the >> programmer, under the philosophy that "We're all consenting adults >> here". > > How do you know? (I know I'm not.) Then stay with B&D languages. :-) > Seriously, though, the lack of private members does allow for ugly hacks > in user code, and you know there are always ugly hackers. So what? The hacks in Java to access private fields are even uglier IMHO. >> This allows people to meddle with internals, at their own risk, if it >> ends up being absolutely necessary. > > If it ends up being necessary, the class's design is flawed. Maybe that's the reason why it is really necessary. > (Though in this case, the flaw is easily solved by simply providing a > getter.) Simply providing a getter for a private attribute? I thought that's not easily possible in C++ or Java!? ;-) >> The enforcement point is >> largely academic anyway, as most languages' reflection APIs let you >> poke at ostensibly "private" things. > > If you're talking about getters, then note that this doesn't let you > modify the member (unless there's a corresponding setter). It's not about getters but about accessing private fields without any getters or setters through the reflection API. See the article `Subverting Java Access Protection for Unit Testing`_ for examples. .. _Subverting Java Access Protection for Unit Testing: http://www.onjava.com/pub/a/onjava/2003/11/12/reflection.html Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sat, 31 Jan 2009 15:28:14 -0800, thmpsn.m.k wrote: > On Jan 31, 2:27 pm, Christian Heimes wrote: >> Do you honestly believe that C++'s private members are really private? >> Privateness is only enforced during parsing time. Nobody can stop you >> from messing around with header files or memory. You can still access >> and modify private members but it's all messy and ugly. Even C# and >> .NET don't stop you from doing nasty things from unmananged assemblies. > > I don't know how you would do it in C# (or Java for that matter). In Java you can use reflection to get your fingers on private fields. > In C++ you can play with pointers to "get at" some memory location > somewhere in the object. > [Snipped pointer fiddling explanation] > So: Sometimes it may work, usually it will be unsafe and/or non- > portable, and in most cases the procedure will look complicated. Or ``#define private public`` before including the header files. Which doesn't look complicated to me. > It certainly isn't something I'd try in a real application. However, it > WOULD be tempting to access the member if the language allows me to just > write: > > print "obj.b =", obj.b > > and be done with it. And that's perfectly okay, because the author would have prepended an underscore to `b` if you should not mess with it. > Personally, in Python, I use double underscores for "private" members, > so the above would look like: > > print "obj.b =", obj._NonPOD__b > > but it's still easier than the C++ example. The name mangling is there to prevent name clashes, not to make attributes inaccessible. It's useful for mixin classes for example. >> Seriously, 'private' and 'protected' are merely tools to stop bad >> programmers from doing bad stuff. And the serve as documentation, too. > > It's not just documentation. For example, suppose you're reading a class > definition and see the declaration of a veryInterestingMember and forget > that you're not supposed to access it. If you try to access it, the > compiler will give you a diagnostic message at compile time. I can't forget that because if I'm not supposed to access it, its name would be `_very_interesting_member`. I don't have to wait till compile time to see that, it is really obvious at the time I write the code to access it, or decide not to because it is not part of the API. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com writes: > I don't know how you would do it in C# (or Java for that matter). > > In C++ you can play with pointers to "get at" some memory location > somewhere in the object. The only portable way to know the exact > location between the beginning of the object and the desired member is > the offsetof() macro, but as I understand it this only works for POD > types, which means that it won't work for classes such as: > > class NonPOD > { > private: > int a; > int b; > public: > NonPOD(); > ~NonPOD(); > int C(); > }; > > (I haven't ever actually tried it, so I'm not sure.) > > Nevertheless, you can play and hope for the best. For example, if the > member you want to get at is 'b', then you can do: > > NonPOD obj; > std::cout << "obj.b = " << *(int*) ((unsigned char*) &obj + sizeof > (int)) << std::endl; > > and hope that the compiler didn't leave a hole between the 'a' member > and the 'b' member. Probably moving off topic, but I don't think you have to get anywhere near that extreme in terms of pointers, unless you're trying to deal with instances for which you have no source but only opaque pointers. I haven't gotten stuck having to do this myself yet, but I believe one commmon "hack" for the sort of class you show above is to just "#define private public" before including the header file containing the class definition. No fiddling with pointers, offsets, or whatever, just normal object access syntax past that point. Of course, I believe such a redefinition violates the letter of the C++ standard, but most preprocessors do it anyway. Also, it won't handle the case where the "private:" is not used, but the members are just declared prior to any other definition, since a class is private by default. But even then, if you had to, just make a copy of the class definition (or heck, just define a structure if it's just data elements), ensure the private portions are public, and then cast a pointer to the old class instance to one of your new class instance. Assuming you're building everything in a single compiler, the layouts should match just fine. Again, normal object member access, no casting or pointers needed (beyond the initial overall object pointer cast). -- David -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com wrote: > More interestingly, though, most compilers translate C and C++ code to > assembler first. Does that mean that you can do object-oriented > programming, generic programming, and procedural programming in > assembler? > > Answer: No, but you can probably -- very clumsily -- fake them.) This is getting quite far off the topic, but of course you can, and it's not faking anything. This should be obvious. You can certainly do OO programming in C, which is a glorified assembler. For example, the gobject system defines a complete object-oriented system with classes, inheritance, polymorphism, encapuslation. It uses structures for encapsulating the data and call tables for virtual methods (to use a c++ parlance). It's such a well defined object model that you can, with gtkmm, even extend a c-based gobject class with C++! Of course you can also extend gobject-based C classes with python as well using PyBank to import them. Back when assembly was still somewhat in vogue I read a book on programming assembly in an object-oriented manner. So of course you can. Yes it can be clumsy without syntactic sugar. If you set up call tables, you can handle polymorphism. How would this be faking it? By your definition C++ is faking it since C++ compiles to assembly. In the early days, C++ was first implemented as a preprocessor that emitted straight C code. And I guess python fakes it since the python interpreter is implemented in C compiled to ASM. Maybe the terminology would be less confusing if we considered the terms, object-oriented programming, object-oriented languages, object-oriented systems. Any language can be used for the first. Python, Java, C++ can be defined by the second, and things like Python (the runtime environment), .NET, JVM, Parrot, can be defined by the last term. Fair enough? Python is certainly an object-oriented language, and implements a complete object-oriented system. Python can support coding in an object-oriented methodology, or you can code traditionally while still taking advantage of the complete OO system. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Jan 31, 2:27 pm, Christian Heimes wrote: > thmpsn@gmail.com schrieb: > > > But it's only a faking, and things such as inheritance and > > polymorphism are implemented clumsily (actually I'm not even sure > > about polymorphism). And of course, there are still no private > > members. > > Do you honestly believe that C++'s private members are really private? > Privateness is only enforced during parsing time. Nobody can stop you > from messing around with header files or memory. You can still access > and modify private members but it's all messy and ugly. Even C# and .NET > don't stop you from doing nasty things from unmananged assemblies. I don't know how you would do it in C# (or Java for that matter). In C++ you can play with pointers to "get at" some memory location somewhere in the object. The only portable way to know the exact location between the beginning of the object and the desired member is the offsetof() macro, but as I understand it this only works for POD types, which means that it won't work for classes such as: class NonPOD { private: int a; int b; public: NonPOD(); ~NonPOD(); int C(); }; (I haven't ever actually tried it, so I'm not sure.) Nevertheless, you can play and hope for the best. For example, if the member you want to get at is 'b', then you can do: NonPOD obj; std::cout << "obj.b = " << *(int*) ((unsigned char*) &obj + sizeof (int)) << std::endl; and hope that the compiler didn't leave a hole between the 'a' member and the 'b' member. Getting at the 'a' member would be easier because the first member of a struct/class always has the same memory location as the object itself (although again I'm not sure if this is true for non-POD types as well). So: Sometimes it may work, usually it will be unsafe and/or non- portable, and in most cases the procedure will look complicated. It certainly isn't something I'd try in a real application. However, it WOULD be tempting to access the member if the language allows me to just write: print "obj.b =", obj.b and be done with it. Personally, in Python, I use double underscores for "private" members, so the above would look like: print "obj.b =", obj._NonPOD__b but it's still easier than the C++ example. > Seriously, 'private' and 'protected' are merely tools to stop bad > programmers from doing bad stuff. And the serve as documentation, too. It's not just documentation. For example, suppose you're reading a class definition and see the declaration of a veryInterestingMember and forget that you're not supposed to access it. If you try to access it, the compiler will give you a diagnostic message at compile time. So you can think of it as an error-checking tool as well. > Oh, by the way, the first C++ compilers just converted C++ code to C > code. Such much about "You can't do OOP in C."! More interestingly, though, most compilers translate C and C++ code to assembler first. Does that mean that you can do object-oriented programming, generic programming, and procedural programming in assembler? (Answer: No, but you can probably -- very clumsily -- fake them.) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Steve Holden wrote: > You can think what you like, but there is a fundamental difference > between methods of a class and functions of a module. Until you > appreciate that you will likely make mistakes. Don't worry, though, we > all learn from our mistakes. And this fundamental difference is? >From what I can tell an instance method is an object that encapsulates the function object in a closure that makes sure it has a reference to "self." I know that you dynamically add functions to objects creating methods dynamically, by using new.instancemethod or something. This seems to indicate to me that there are functions and there are functions. Methods are in fact functions, just with a callable wrapper around them. Is this not so? -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com wrote: >> To be clear, python does not force you to lay out your code according to >> some strict object-oriented paradigm. But Python itself is still purely >> object-oriented, as is your script when parsed. > > But it's only a faking, and things such as inheritance and > polymorphism are implemented clumsily (actually I'm not even sure > about polymorphism). And of course, there are still no private > members. How is it faking? The class of a function object is "function," which is of the metaclass "type." What more do you want? If Guido himself declared that functions are objects would you believe that? Or modules? Since a function object is an instance of the class "function" I don't see how you could inherit from it, and polymorphism has nothing to do with this either. Maybe what you are talking about is deriving a class from the class "function." Not sure if that's allowed, mainly because the language has defined a standard way of declaring a function (methods are functions too, of course), so creating a useful, derived function object would be difficult given how the syntax of the language works. Private members? I could stick add any attribute I wanted to a function object and ask that people treat it as private if I wanted to: def myfunc(): pass myfunc.__dict__['_private'] = 4 If you are insinuating that not forcing private attributes to be unaccessible by others (black box theory) is in somehow a violation of object-oriented semantics, think again. It's not. (There are no formal definitions of OO anyay, but wikipedia lists quite a few characteristics considered common to OO, and enforced private members is not one of them.) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com wrote >> This allows people to meddle with internals, at their own risk, >> if it ends up being absolutely necessary. > > If it ends up being necessary, the class's design is flawed. (Though > in this case, the flaw is easily solved by simply providing a getter.) No the class design is not necessarily flawed. Sometimes it is desirable to modify a class's behavior at a lower level. In Java this isn't possible directly and so it has led to an entire class of libraries that provide means of doing this. For more information, look up "Aspect-oriented Programming" on wikipedia. Since most aspect-oriented programming examples I've seen are in Java I never understood much about it ("cross-cutting concerns" is a pretty meaningless explanation) until I realized that metaprogramming in python, monkey-patching classes, and dynamically adding attributes to an existing class are all forms of aspect-oriented programming. And it turns out to be quite useful for some things. One area where aspect-oriented programming is useful is in libraries that add security layers to objects and methods. Rather than having to make code directly aware of the security layer (which could take different forms), we can instead reach into the classes and, for example, wrap certain methods in a function that enforces security. If we do it in the class directly, then even code that descends from this class will transparently "inherit" all of the newly added security layer code that was never there when the code was first written. By security layer I'm talking more about code that enforces certain user authentication before use (as in web programming) rather than "secure" code. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
thmpsn@gmail.com schrieb: > But it's only a faking, and things such as inheritance and > polymorphism are implemented clumsily (actually I'm not even sure > about polymorphism). And of course, there are still no private > members. Do you honestly believe that C++'s private members are really private? Privateness is only enforced during parsing time. Nobody can stop you from messing around with header files or memory. You can still access and modify private members but it's all messy and ugly. Even C# and .NET don't stop you from doing nasty things from unmananged assemblies. Seriously, 'private' and 'protected' are merely tools to stop bad programmers from doing bad stuff. And the serve as documentation, too. Oh, by the way, the first C++ compilers just converted C++ code to C code. Such much about "You can't do OOP in C."! Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sat, 31 Jan 2009 09:11:03 +0100 Laszlo Nagy wrote: > Python is not a pure object oriented language, because it has other > programming tools, for example functions. I'm not sure about the first part of the sentence, but Python's functions are objects. Check it in the interpreter: attributes, methods, the whole caboodle. regards, /W -- My real email address is constructed by swapping the domain with the recipient (local part). -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Jan 30, 2:32 pm, Michael Torrie wrote: > Veerendra Ganiger wrote: > > Python is not purely object oriented programming, because we can write > > functions without any class. > > You are right, predefined class attributes are available when we write or > > execute a piece of python code without defining class, that means it's just > > using objects for it's purpose. It does not mean its purely object oriented. > > To be clear, python does not force you to lay out your code according to > some strict object-oriented paradigm. But Python itself is still purely > object-oriented, as is your script when parsed. > > This function without a class that you mentioned, is in fact an object > with attributes. You can pass a function around just like any other > object. Even calling a function is invoked like so: > > myfunc.__call__(params) > > So necessitating that code be inside a class has nothing to do with > object-oriented programming. Let's not forget that classes are > themselves objects (metaobjects in smalltalk parlance if I recall > correctly). > > Now python does not have any way besides lambda expressions of creating > unbound function objects, but in practice this doesn't matter as I can > rebind names freely. I can still do: > > a=myfunc > myfunc=some other expression or object > > > It all depends on implementation, I think even we can make "C" object > > oriented with proper implementation. > > Indeed, any code based on gobject libraries can be object-oriented in > design and function. But it's only a faking, and things such as inheritance and polymorphism are implemented clumsily (actually I'm not even sure about polymorphism). And of course, there are still no private members. -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Sat, Jan 31, 2009 at 9:08 AM, wrote:On Jan 30, 12:15 am, Chris Rebertwrote: > - Python supports encapsulation. Prefixing an attribute/method with an > underscore indicates that other programmers should treat it as > 'private'. However, unlike B&D languages, Python itself does nothing > to enforce this privacy, leaving it instead to the good judgement of > the programmer, under the philosophy that "We're all consenting adults > here". How do you know? (I know I'm not.) Seriously, though, the lack of private members does allow for ugly hacks in user code, and you know there are always ugly hackers. So what, though?If you're a application developer, writing your own code: just don't do it.You've now achieved enforced encapsulation! Why does the languageneed to check that?If you're the user of a library and you need access to a private memberof that library: again, just don't do it! Write a patch and maintain aprivate fork to expose the member function, and submit it to the developerand hope it gets included so you don't have to maintain the private fork.For those people who need access to that internal Right Now and don'twant to wait for the developer to expose it, because its important to themwhy should the language forbid it? Sure, its an ugly hack. But so what? They're doing it, at the risk of future breakage if anything changes inthat undocumented internal detail, because they need to. There aresituations where maintaining a private fork to expose something in alibrary is a far greater burden and not worth it.If you're the writer of a library, why do you even care if the people whouse it access an undocumented internal? If anything breaks its notyour problem.If you're in some corporate environment which has a 'no fiddling withthe privates of another teams modules' -- why do you need the languageto enforce that restriction? If your employees aren't following the codingstandards of your own organization, that's a problem. Surely it'd come upvery quickly with even the most cursory of reviews, after all "obj._variable"is really obviously not "self._variable" and so pretty obviously accessingsomeone elses private state.If you're in an open source environment and are worried about qualityof code from lots of contributors who aren't being paid: again, reviewsshould be happening /anyways/.In the end, why bother? If you believe in absolute encapsulation itsextremely easy for you to get it in Python, today... don't touch someoneelses privates. > This allows people to meddle with internals, at their own risk, > if it ends up being absolutely necessary. If it ends up being necessary, the class's design is flawed. (Though in this case, the flaw is easily solved by simply providing a getter.)Sure, the design is flawed. Doesn't change the fact that you need to accessthat internal state. "Providing a getter" is not necessarily simple: what ifits someone elses code? At the very least you have to maintain a privatefork then /or/ wait until they get around to fixing the design. Sometimes that's no big deal. Sometimes it is. In the absence of private/protected, Python should at least provide something similar to C++'s 'const' or Java's 'final'. (Similar, not equivalent, because then the object itself wouldn't be able to manipulate its own members!)I find marking my constants as SOME_CONSTANT instead of some_constantto be more then sufficient usually. In the case where I do want to let someoneread a piece of data and not write it, I find a getter accessing a private membervariable without a corresponding setter perfectly fine.If the users of the code choose to dig inside my class and fiddle with thatprivate member -- woe on them! I wash my hands of any trouble theyhave.--Stephen signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
On Jan 30, 12:15 am, Chris Rebert wrote: > - Python supports encapsulation. Prefixing an attribute/method with an > underscore indicates that other programmers should treat it as > 'private'. However, unlike B&D languages, Python itself does nothing > to enforce this privacy, leaving it instead to the good judgement of > the programmer, under the philosophy that "We're all consenting adults > here". How do you know? (I know I'm not.) Seriously, though, the lack of private members does allow for ugly hacks in user code, and you know there are always ugly hackers. > This allows people to meddle with internals, at their own risk, > if it ends up being absolutely necessary. If it ends up being necessary, the class's design is flawed. (Though in this case, the flaw is easily solved by simply providing a getter.) > The enforcement point is > largely academic anyway, as most languages' reflection APIs let you > poke at ostensibly "private" things. If you're talking about getters, then note that this doesn't let you modify the member (unless there's a corresponding setter). In the absence of private/protected, Python should at least provide something similar to C++'s 'const' or Java's 'final'. (Similar, not equivalent, because then the object itself wouldn't be able to manipulate its own members!) -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
MC wrote: > Re > >> ‘builtin’ is not a class. > > I think "object" ; not only "class" > And "builtin" is an object. > You can think what you like, but there is a fundamental difference between methods of a class and functions of a module. Until you appreciate that you will likely make mistakes. Don't worry, though, we all learn from our mistakes. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: is python Object oriented??
Re ‘builtin’ is not a class. I think "object" ; not only "class" And "builtin" is an object. -- @-salutations Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list