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...
--
http://mail.python.org/mailman/listinfo/python-list
