Prototype OO

<fsqaj4$1kk$1@nemesis.news.neostrada.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Gmane-NNTP-Posting-Host: pool-71-126-145-65.washdc.fios.verizon.net
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
In-Reply-To: <fsqaj4$1kk$1@nemesis.news.neostrada.pl>
Sender: news <news@ger.gmane.org>
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion list for the Python programming language
<python-list.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/listinfo/python-list>,
<mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-list>,
<mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.2630.1206958828.9267.python-list@python.org>
Lines: 78
NNTP-Posting-Host: 194.109.207.14
X-Trace: 1206958828 news.xs4all.nl 14353 [::ffff:194.109.207.14]:34589
X-Complaints-To: abuse@xs4all.nl
Bytes: 5760
Xref: number1.nntp.dca.giganews.com comp.lang.python:578139

sam wrote:
> Steven D'Aprano napisał(a):
> 
>
> Sorry for a late reply (I was out of the office).
>
>
> 1. You have different syntax for named and unnamed (lambdas) functions.
> Functions and methods are different things in Python even if they have sam
e
> syntax. But all these are still a pieces of code that you use repeatedly t
o make
> some task.
>
A knife and scissors are both used to cut things, but that doesn't mean
they are the same.

> 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. Python is said "nothing is really private", but
> interpreter does some "tricks" to make __id hidden for a class.
>
Static functions don't even need to live in classes, and certainly don't
need references to "self", which only makes sense in the context of
acting on instances of classes.
>
> Some opinions:
>
> 1. In early days you could do OOP in C -- you just used additional paramet
er in
> a function. Then C++ appeared to make life easier: "when you write
> mystring.toupper(), then toupper function gets hidden argument called "thi
s"".
> Programs are written in a high level object oriented languages now. In the
se
> languages you still use the same syntax mystring.toupper(), but now you do
n'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"?
>
> This is not only my opinion
> (http://apache.ece.arizona.edu/~edat.../Prototypes.htm). Without "
self"
> you would use same syntax for ordinary functions, methods, and lambdas.
>
I think you are bundling quite different things together here. The
difference in semantics between bound methods (where the instance
reference is added as a first argument) and regular functions (where no
additional argument is supplied) has nothing to do with the difference
between function and lambda definition syntax.

>
> 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 priva
te or
> to do hidden actions (__id). For example all local variables in function a
re
> private, because you can't access them from outside that function. Why des
n't
> this work for objects?
>
> Again this is not only my opinion --
> http://www.crockford.com/javascript/private.html.
>
The desire to provide information hiding is fundamentally against the
Python philosophy, which basically says that attribute values are
exposed for all to see. This avoids the nonsense of having to provide
setter and getter methods which Java imposes on the programmer.

You use the references you provide as a drunken man uses a lamp post -
more for support than enlightenment. Python is not JavaScript, and never
will be. JavaScript is a better language than it's often given credit
for, but its object semantics are closer to Self than to Python.

regards
Steve
--
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/

Steve Holden napisał(a):
 
> A knife and scissors are both used to cut things, but that doesn't mean
> they are the same.

Well -- sometimes you have to use many, many types of scissors.




> I think you are bundling quite different things together here. The
> difference in semantics between bound methods (where the instance
> reference is added as a first argument) and regular functions (where no
> additional argument is supplied) has nothing to do with the difference
> between function and lambda definition syntax.

You are right. One is syntax issue, and the second is language implementatio
n
issue. It would be better to have one unified syntax and one unified
implementation.




> The desire to provide information hiding is fundamentally against the
> Python philosophy, which basically says that attribute values are
> exposed for all to see. This avoids the nonsense of having to provide
> setter and getter methods which Java imposes on the programmer.

This philosophy is great and makes Python such a good language. But you can'
t go
beyond what programmers need. If you do so, then you will have to implement
tricks as __id.

En Mon, 31 Mar 2008 07:59:13 -0300, sam <sam@mas.pl> escribió:

> Steve Holden napisał(a):
> 
>
> Well -- sometimes you have to use many, many types of scissors.

I don't get the point - weren't you criticizing Python for having many
different kind of functions?
 
>
> This philosophy is great and makes Python such a good language. But you
> can't go
> beyond what programmers need. If you do so, then you will have to
> implement
> tricks as __id.

The __id "trick" is not for hidding instance attributes, but to avoid name
collisions. Unlike other languages, all instance attributes share a single
namespace, you can't qualify a reference to say "the foo attribute from
this base class, not this other foo": it is always "the foo attribute" no
matter inside which class it was assigned.
The __ prefix creates mangled names so __foo used inside a certain class
is a different attribute name than __foo outside that class. It is not
used to "hide" the attribute, the rules for the mangled name are very easy
to emulate.

What are those programmers needs?

--
Gabriel Genellina

sam a écrit :
> Steven D'Aprano napisał(a):
> 
>
> 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/~edat.../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...

Bruno Desthuilliers napisał(a):


> 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

Ok -- thank you for your time and your strong opinions about current solutio
ns.

sam a écrit :
> Bruno Desthuilliers napisał(a):
>
> 
>
> Ok -- thank you for your time and your strong opinions about current
> solutions.

Don't misunderstand me : I'm not saying that class-based is better (or
worse) than prototype, I'm not saying that Python is perfect, I'm not
saying that your points are not worth any consideration, I'm just saying
that, from your arguments, I have the very strong impression that you
don't know enough about Python's object model to understand it's
coherence and strength (and I've probably expressed it a rather harsh
way - please bear with me). If I'm wrong, please say so, pardon me and
we'll move ahead.

regards,
bruno

Bruno Desthuilliers napisał(a):

> Don't misunderstand me : I'm not saying that class-based is better (or
> worse) than prototype, I'm not saying that Python is perfect, I'm not
> saying that your points are not worth any consideration, I'm just saying
> that, from your arguments, I have the very strong impression that you
> don't know enough about Python's object model to understand it's
> coherence and strength (and I've probably expressed it a rather harsh
> way - please bear with me). If I'm wrong, please say so, pardon me and
> we'll move ahead.

I understand you. Thanks for spending time to write all that things.




The point is that when I say:

-- you should have same syntax of lambdas and ordinary functions

then Python gurus say:

-- lambda is very good and is so special, that has its own syntax

But it seems to me, that lambda syntax was introduced because of interpreter
limitations -- indentation and expressions. So it is not perfect, but must b
e as
it is now.


Then I say:

-- __id is awful, because it is a trick to prefix names

and gurus say:

-- it is good solution for name conflicts

But somebody may prefix his names with class names and cause nameconflict, s
o
maybe it is not so good? I would prefer to hear something like "other soluti
ons
were very complex, and our zen says 'Simple is better than complex.', so we
decided to use this simple and not perfect solution"

On Apr 2, 10:52 am, sam <s...@mas.pl> wrote:
> Then I say:
>
>         -- __id is awful, because it is a trick to prefix names
>
> and gurus say:
>
>         -- it is good solution for name conflicts
>
> But somebody may prefix his names with class names and cause nameconflict,
 so
> maybe it is not so good? I would prefer to hear something like "other solu
tions
> were very complex, and our zen says 'Simple is better than complex.', so w
e
> decided to use this simple and not perfect solution"

The stated purpose of the name mangling attributes is to minimize
accidental conflicts, not to enforce data hiding.


Carl Banks

On 2 avr, 16:52, sam <s...@mas.pl> wrote:
> Bruno Desthuilliers napisa=B3(a):
> 
 
>
> I understand you. Thanks for spending time to write all that things.
>
> The point is that when I say:
>
>         -- you should have same syntax of lambdas and ordinary functions
>
> then Python gurus say:
>
>         -- lambda is very good and is so special, that has its own syntax
>
> But it seems to me, that lambda syntax was introduced because of interpret=[/color
]
er
> limitations -- indentation and expressions. So it is not perfect, but must=[/color
]
be as
> it is now.

You're of course right on this.

OTHO, I found out that with languages that let you define "full-blown"
inline anonymous functions (like javascript), I tend to make any non-
trivial function into an ordinary named one - mainly for readability.
So, while I often use Python's lambdas, the imposed limitations is ok
to me since I wouldn't use it for anything more complex. But I may be
a bit biased here since I discovered the concept of anonymous
functions (and quite a lot of other more or less functional
programming inspired stuff) with Python.

Also - as a side note - while the syntax is a bit different, the
resulting object is an ordinary function.

> Then I say:
>
>         -- __id is awful, because it is a trick to prefix names
>
> and gurus say:
>
>         -- it is good solution for name conflicts
>
> But somebody may prefix his names with class names and cause nameconflict,=[/color
]


Here the problem is more philosophical than anything else. Python's
philosophy is that most programmers are responsible and normally
intelligent, so treating them all like retarted dummies because
someone might one day do something stupid is just wasting everyone's
time. This is also why there's no language-enforced access
restriction, only a simple stupid convention to denote implementation
stuff from API. The fact is that it JustWork.

> so
> maybe it is not so good?

It's enough. FWIW, I'm not sure I had a use-case for this feature more
than a couple time in 7+ years.

>  I would prefer to hear something like "other solutions
> were very complex, and our zen says 'Simple is better than complex.', so w=[/color
]
e
> decided to use this simple and not perfect solution"

Simple, indeed. But why "not perfect" ? What else would you want ?

"bruno.desthuilliers@gmail.com" <bruno.desthuilliers@gmail.com> writes:
> Here the problem is more philosophical than anything else. Python's
> philosophy is that most programmers are responsible and normally
> intelligent, so treating them all like retarted dummies because
> someone might one day do something stupid is just wasting everyone's
> time. This is also why there's no language-enforced access
> restriction, only a simple stupid convention to denote implementation
> stuff from API. The fact is that it JustWork.

Additional Principles for C1X (new)
..
12. Trust the programmer, as a goal, is outdated in respect to the
security and safety programming communities.  While it should not
be totally disregarded as a facet of the spirit of C, the
C1X version of the C Standard should take into account that
programmers need the ability to check their work.

C - The C1X Charter
Document: WG14 N1250, p. 3
http://www.open-std.org/JTC1/SC22/W.../docs/n1250.pdf