Re: is python Object oriented??

[agile]

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??

[Bruno Desthuilliers]

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??

[Thorsten Kampe]

* 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??

[Luis Zarrabeitia]

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??

[Mark Wooding]

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??

[Mark Wooding]

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

[thmpsn . m . k]

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??

[Terry Reedy]

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??

[Gabriel Genellina]

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??

[Russ P.]

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??

[Luis Zarrabeitia]

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??

[Luis Zarrabeitia]

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??

[Bruno Desthuilliers]

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??

[Bruno Desthuilliers]

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??

[Bruno Desthuilliers]

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??

[Bruno Desthuilliers]

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??

[Hendrik van Rooyen]

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

[Steven D'Aprano]

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??

[Russ P.]

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??

[Rhodri James]

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??

[Russ P.]

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??

[Russ P.]

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??

[David Cournapeau]

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??

[Steven D'Aprano]

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??

[Rhodri James]

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??

[Rhodri James]

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??

[Gabriel Genellina]

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??

[rdmurray]

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??

[thmpsn . m . k]

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??

[David Cournapeau]

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??

[thmpsn . m . k]

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??

[Scott David Daniels]

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??

[Bruno Desthuilliers]

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??

[Thorsten Kampe]

* 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??

[Marco Mariani]

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??

[Thorsten Kampe]

* 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??

[Thorsten Kampe]

* 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??

[Russ P.]

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??

[Steven D'Aprano]

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??

[Hendrik van Rooyen]

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

[Hendrik van Rooyen]

 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??

[David Cournapeau]

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??

[Russ P.]

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??

[Luis Zarrabeitia]

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??

[Rhodri James]

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??

[Grant Edwards]

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??

[Russ P.]

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??

[Mark Wooding]

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

[Rhodri James]

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??

[Tim Rowe]

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??

[Benjamin Kaplan]

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??

[Russ P.]

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??

[Luis Zarrabeitia]

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??

[Tim Rowe]

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??

[Russ P.]

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??

[Stephen Hansen]

>
> > >  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??

[Diez B. Roggisch]

> 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??

[Bruno Desthuilliers]

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??

[thmpsn . m . k]

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 van Rooyen]

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??

[Hendrik van Rooyen]

 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??

[Hendrik van Rooyen]

 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??

[rdmurray]

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??

[rdmurray]

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??

[Diez B. Roggisch]

> 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??

[Hendrik van Rooyen]

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

[Bruno Desthuilliers]

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??

[Bruno Desthuilliers]

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??

[Bruno Desthuilliers]

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??

[Stephen Hansen]

>>
>> 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??

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

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??

[Hung Vo]

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??

[Steve Holden]

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??

[Steve Holden]

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??

[Luis Zarrabeitia]

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??

[Steven D'Aprano]

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??

[Rhodri James]

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??

[rdmurray]

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??

[Steve Holden]

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??

[Luis Zarrabeitia]

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??

[Stephen Hansen]

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??

[thmpsn . m . k]

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??

[MRAB]

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??

[Chris Rebert]

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??

[Marc 'BlackJack' Rintsch]

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??

[Marc 'BlackJack' Rintsch]

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??

[David Bolen]

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??

[Michael Torrie]

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??

[thmpsn . m . k]

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??

[Michael Torrie]

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??

[Michael Torrie]

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??

[Michael Torrie]

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??

[Christian Heimes]

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??

[Andreas Waldenburger]

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??

[thmpsn . m . k]

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??

[Stephen Hansen]

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

[thmpsn . m . k]

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??

[Steve Holden]

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??

[MC]

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