Prototype OO

[Bruno Desthuilliers]

sam a écrit :
> Steven D'Aprano napisał(a):
> 
>>> I can see that Python and Javascript inheritance model is almost the
>>> same. Both languages are dynamically typed. And it seems that using
>>> "classes" in Python makes some things more complicated then it is
>>> necessary (eg functions, methods and lambdas are differen beeing in
>>> Python concept).
>>
>> Please explain why you think that functions are more complicated in 
>> Python because of the class model.
> 
> Sorry for a late reply (I was out of the office).
> 
> 
> 1. You have different syntax for named and unnamed (lambdas) functions.

That doesn't make the resulting object different, and this has nothing 
to do with Python's object model.

> Functions and methods are different things in Python even if they have 
> same syntax.

There's *no* syntax for Python methods. Whether you define it at the 
module's top level, within a class statement or within another function, 
what you define is a function, period. It's the collaboration between 
the attribute lookup mechanism and the function objects themselves that 
yields method objects.


> 2. Static function doesn't need to reference "self", and Python forces 
> programmer to put "self" explicitly.
 > Then you have to do some "tricks"
 > on function to become static.

Hem... Shouldn't smoke that weird weed they gave you, for sure...

If you're talking about staticmethods, they - by definition - don't take 
the instance as first param. And the 'trick' is mostly: decorate the 
function with the staticmethod type. Here's how you do it:

class Parrot(object):
    @staticmethod
    def vroom():
       print "vroom"

No self, no trick.


Now anyway, staticmethod are rarely used - usually, all you need is a 
plain function (remember that Python doesn't force you into putting 
everything in a class).

Now this still have nothing to do with Python being class-based (for a 
definition of class-based that's *very* different from Java).

> Python is said "nothing is really 
> private", but interpreter does some "tricks" to make __id hidden for a 
> class.

Not to hide it, but to avoid name clash.

> 
> Some opinions:
> 
> 1. In early days you could do OOP in C -- you just used additional 
> parameter in a function.

While possible, OO in C is definitively a PITA (cf GTK+, OOPC etc).

> Then C++ appeared to make life easier: "when 
> you write mystring.toupper(), then toupper function gets hidden argument 
> called "this"". Programs are written in a high level object oriented 
> languages now. In these languages you still use the same syntax 
> mystring.toupper(), but now you don't pass object to a function (as in 
> C), but you act on that object. So in the body of toupper() you can 
> REFERENCE object "mystring". So why do I have to put that "strange" 
> argument "self"?

To allow a simple, uniform and *highly* flexible way to handle functions 
and methods. Learn about Python's object model (you obviously don't have 
a clue about it), and specially about the descriptor protocol and how 
functions implement it, take time to experiment with it and think about 
all it let you do that you just can't do in C+ or Java, and then I'll be 
happy to continue this discussion.

> This is not only my opinion 
> (http://apache.ece.arizona.edu/~edatools/Python/Prototypes.htm). Without 
> "self" you would use same syntax for ordinary functions, methods, and 
> lambdas.

Once again, there's *no* syntax difference between functions and 
methods, because you *never* define a method. wrt/ lambda, the problem 
has to do with Python being statemement-based and having significant 
indentation.


> 2. Something is private because you can't reference that from outside 
> the scope. The wrong way is to make object properties private by 
> declaring them private or to do hidden actions (__id). For example all 
> local variables in function are private, because you can't access them 
> from outside that function. Why desn't this work for objects?

Because Python's designer didn't think that language-enforced access 
restriction was such a good idea. BTW, where are "private" attributes in 
javascript ?-)

> Again this is not only my opinion -- 
> http://www.crockford.com/javascript/private.html.

Answer: a dirty trick using closures...


Sam, seriously, why don't start with *learning* about Python's object 
model ? Seriously ? Not that it's "perfect", not that you have to like 
it, but if you hope your criticism to be taken seriously, you'd better 
know what you're talking about.

My 2 cents...