can someone explain?

[Mongryong]

On Tue, 2003-02-18 at 01:53, Jp Calderone wrote:
> > To enforce true OO encapsulate would probably mean more work for the
> > Python VM -> hence, that makes Python slower.  Yes, it's true that you
> > can add attributes to a class whenever you want to - however, I believe
> > this feature had to be added to support inheritance.  The base class
> > initializes 'self' with attributes, then the extended class may add new
> > attributes to 'self'.  Now, if the Python VM were to forbid one from
> > being able to add new attributes to 'self' outside of the '__init__'
> > method, then the Python VM would have to do checks everytime 'self' is
> > assigned a value.
> > 
> 
>   Encapsulation isn't the same as data hiding.  Python does not enforce data
> hiding, but it allows as much or as little encapsulation as you like.

Again, JP...you're being a prick.  Neither I, nor the original poster,
said encapsulation is the 'same thing' as data hiding.  By definition
encapsulation means "the process of combining elements to create a new
entity."  A procedure is a type of encapsulation because it 'combines' a
series of computer instructions into one entity.  A complex data type,
such as a class, is a form of encapsulation because it 'combines'
elements into a new type.  In the above comments, I and the original
poster were talking about the process of 'adding' (combining)
'attributes' (elements) to self.  That by definition, is
'encapsulation'.  Look it up.

> 
> > Python in a way is very much like C++.  C++ has all these OO features,
> > but it provides a 'back door' to support 'C' so that it can easily be
> > integrated with legacy 'C' code and optimized at the 'hardware' level. 
> > More importantly, C++ provides these escape routes for situations where
> > there is no other 'clean (OO) way' to solve a problem - so, you just
> > 'hack it' with a 'C' solution.  Python's no different.
> 
>   Unless you're referring to extension modules written in C (which I doubt),
> this is wrong, too.

The comparison here is that both C++ and Python provide 'back doors' to
other less elegant ways of solving problems.  In the perfect world,
every programmer would have hindsight and great OO design skills.  These
'back doors' exist because the world is not perfect. Also, because
Python's is a scripting language the more strict it is, the slower the
VM will be.  You know these back doors exist - the trick is to not use
them if at all possible (eventhough its tempting).  



> 
> > In fact, because Java is so strict, it makes it difficult for non-OO
> > programmers to use the language.
> 
>   It is a stretch to call Java an OO language at all.

You can do OO programming in language that supports the notion of
'encapsulation'.  Some languages are just more convient than others.

> 
> > 
> > If you're a OO purist, Python has the 'essential' features for you.  If
> > you're a procedural type programmer, Python has all the features you
> > need as well.
> 
>   Python isn't "pure" in any real sense.  It's a pragmatist's language. 
> You're right that it provides many features for many paradigms, though.

Who said Python was 'pure'?

> 
> > 
> > > 
> > > And the last question.
> > > def f(a,L=[]):
> > >   L.append(a)
> > >   return L
> > > 
> > > >>f(1)
> > > [1]
> > > >>f(2)
> > > [1,2]
> > > >>f(3)
> > > [1,2,3]
> > > 
> > > L is a default argument so every time when a function f is invoked, L
> > > should be created and as a result f should return a list with only one
> > > value.
> > > Why doesn't it work that way?
> > 
> > Default parameters are initialized at import time.  Don't know why it
> > was done this way - maybe to support 'static method variables'?
> > 
> 
>   This is also wrong.  A thread on this topic recently appeared in this
> group, with many good answers, as well as pointers to at least two FAQs
> which give the correct answer to the question.

Again, you have a great way pointing out that 'something' is wrong but
you don't mention what's wrong.  
 

> 
> -- 
>  up 9 days, 10:28, 3 users, load average: 0.00, 0.02, 0.03