Prototype OO

On 2 avr, 20:46, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> "bruno.desthuilli...@gmail.com" <bruno.desthuilli...@gmail.com> writes: 
>
>     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. 3http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1250.pd
f

Fine. But totally irrelevant here - this is comp.lang.python, not
comp.lang.c, and we *do not* (I repeat : we *do not*) face the same
safety and security problems as those existing in C.

"bruno.desthuilliers@gmail.com" <bruno.desthuilliers@gmail.com> writes:
> Fine. But totally irrelevant here - this is comp.lang.python, not
> comp.lang.c, and we *do not* (I repeat : we *do not*) face the same
> safety and security problems as those existing in C.

We have it better than they do in some ways.  In some other ways, we have
it worse.

En Wed, 02 Apr 2008 09:23:21 -0300, sam <sam@mas.pl> escribió:

> Gabriel Genellina napisał(a):
> 
>
> Yes. Funciton is always a piece of code (program) that does something.
> There is
> no need for different syntax.

Guido has regretted lambda for a long time; it was scheduled for deletion
on Python 3000 [2] but finally will stay [3].
Class methods and instance methods are not just standard functions;
instance methods were plain functions before 2.2 and the Class object was
in charge of doing the "self magic". Now the descriptor protocol provides
far more possibilities.

> And you said that it is good to have these two types of syntax. It
> sounds like:
> "it is good to have knife and scissors to cut the _same_ thing, because
> they are
> not the same".

I didn't say that (note that you trimmed most attribution lines) but I
like to have "short anonymous functions" altough the syntax might be
different. Perhaps in Python 4000.
 
>
> Programmers need to protect name in a namespace. Name mangling is not
> the best
> choice.

Why to "protect" names in a namespace? We are all adults here. Name
mangling is a reasonable and simple way to avoid name conflicts in a
shared namespace. I don't know whether it's the "best" way or not, but has
worked fine for me for a long time.

[1] http://www.python.org/doc/essays/pp...thonRegrets.ppt
(couldn't find easily an older reference, but there are)
[2] http://www.artima.com/weblogs/viewpost.jsp?thread=98196
[3] http://mail.python.org/pipermail/py...ary/060415.html

--
Gabriel Genellina

On 2 avr, 22:23, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> "bruno.desthuilli...@gmail.com" <bruno.desthuilli...@gmail.com> writes: 
>
> We have it better than they do in some ways.
>In some other ways, we have
> it worse.

Care to elaborate ? Or are we supposed to guess ?-)

On Apr 2, 5:41=A0pm, "bruno.desthuilli...@gmail.com"
<bruno.desthuilli...@gmail.com> wrote:
> On 2 avr, 22:23, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> 
> 
>
> Care to elaborate ? Or are we supposed to guess ?-)

Has anyone thought about putting code in a Data file?  Am I the only
one that wants Python stored procedures in DB?

bruno.desthuilliers@gmail.com napisa³(a):


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

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

And people start asking why this is that or the other way in Python, and you
can't give a good answer to newcomers, especially if Python was chosen as a
first learning language. You can't tell "because Python's parsing mechanism
don't allow statements in expressions...".






 
>
> Here the problem is more philosophical than anything else.

Almost the whole discussion is philosofical, but clear philosophy is a good 
thing.





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

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

I would expect you to told me at the beginning that this is enough to solve 
the
problem and that somebody can still cause name conflict, but Python was buil
t
for wise people.

Gabriel Genellina napisał(a):
 
>
> Guido has regretted lambda for a long time; it was scheduled for
> deletion on Python 3000 [2] but finally will stay [3].

Thanks for that info and links.



> Class methods and instance methods are not just standard functions;
> instance methods were plain functions before 2.2 and the Class object
> was in charge of doing the "self magic". Now the descriptor protocol
> provides far more possibilities.

Actually I don't know what is "descriptor protocol", so maybe I should have
finished discussing. I will aslo search for "self magic" -- some pieces of o
ld
code, or something.



> I didn't say that (note that you trimmed most attribution lines) but I
> like to have "short anonymous functions" altough the syntax might be
> different. Perhaps in Python 4000.

And I say "syntax should be the same". These are only opinions, so forgive m
e
for wasting your time.

> And I say "syntax should be the same". These are only opinions, so
> forgive me for wasting your time.

You mean like in JS?

function foo(args) {}

foo = function(args) {}

Somehow the JS-designers also made a compromise to allow to create
unnamed and named functions. Could it be that it make *sense* to
sacrifice simplicity and orthogonality here, so that different usage
scenarios get to be written concisely?

Start coding in python. And enjoy it. Is it perfect? Heck no! But it
sure is fun enough to deal with the occasional wart.

Diez

sam a écrit :
> bruno.desthuilliers@gmail.com napisa³(a):
>
> 
> 
>
> And people start asking why this is that or the other way in Python, and
> you can't give a good answer to newcomers, especially if Python was
> chosen as a first learning language. You can't tell "because Python's
> parsing mechanism don't allow statements in expressions...".


If the people asking is able to understand this explanation, I'll
happily give it. Else, I'd answer "for reasons that are perhaps too
complex to explain to you right now, but I'll try if you insist" !-)
 
>
> Almost the whole discussion is philosofical, but clear philosophy is a
> good thing.
>
>
> 
> 
>
> I would expect you to told me at the beginning

which "beginning" ?

> that this is enough to
> solve the problem

what did I do ?

> and that somebody can still cause name conflict,

Why should I tell you something that's so obvious you observed it by
yourself ?

> but
> Python was built for wise people.

for normally intelligent people. I don't play russian roulette, and
don't claim being any "wiser" for this.

Ok, I'm going to be a bit harsh, but this time I'll assume it.

Sam, you started this thread by asking about prototype vs class based
pros and cons - with a (somewhat cargo-cult IMHO) a priori in favor of
prototype. Then you started arguing about limitations and complexity
induced by the class-based approach, without being able to back any of
your claims wrt/ Python's object model. Then you started arguing about
minor syntactic points that, whether you like them or not (and
you're of course entitled to not like them) have nothing to do with
Python's object model nor prototypes vs classes. Now you're complaining
that "we didn't tell you x and z from the start" - like we were supposed
to do your education. Are we supposed to teach you reading and writing
too ?  What's your problem anyway ? If you're a trolling - which I start
to suspect -, then your not too bad at it. Else, it may be time to grow up.

Bruno Desthuilliers napisa³(a):

> Ok, I'm going to be a bit harsh, but this time I'll assume it.

> Sam, you started this thread by asking about prototype vs class based

> minor syntactic points that, whether you like them or not (and

I think I will get back to this discussion after learning "descriptor protoc
ol"
and maybe I will not talk about syntax then, and maybe it won't get off topi
c.

As you can see I'm novice in Python, but I can show python-experts some newb
ie
opinions. If somebody is an expert then he can't take a fresh look at his ma
ny
years work.

Anyway -- thank you for spending time and giving explanations.