Re: Prototype OO
[EMAIL PROTECTED] 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 But somebody may prefix his names with class names and cause nameconflict, 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 built for wise people. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
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]. 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 old 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 me for wasting your time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
sam a écrit : [EMAIL PROTECTED] 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 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 !-) But somebody may prefix his names with class names and cause nameconflict, 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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On 3 avr, 10:32, sam [EMAIL PROTECTED] wrote: 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 protocol and maybe I will not talk about syntax then, and maybe it won't get off topic. may I recommend this http://www.cafepy.com/article/ (the first 2)? -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
sam a écrit : 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 protocol Add lookup (name resolution) rules, metaclasses, 'magic' methods etc to the list then, so you'll get a general view of Python's object model. and maybe I will not talk about syntax then, and maybe it won't get off topic. As you can see I'm novice in Python, but I can show python-experts some newbie opinions. If somebody is an expert then he can't take a fresh look at his many years work. This is indeed true. But be assured their are quite a few newbies (whether nwebie to Python or newbie to programming) posting here to comment on what they perceive as warts - sometimes making good points, sometimes just not knowing enough about the language's inners and/or philosophy to understand why what they think is a wart is considered a feature by more advanced users. As some other contributor (hi Diez !) to this thread already mentionned, Is [Python] perfect? Heck no! But it sure is fun enough to deal with the occasional wart. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
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 protocol and maybe I will not talk about syntax then, and maybe it won't get off topic. As you can see I'm novice in Python, but I can show python-experts some newbie opinions. If somebody is an expert then he can't take a fresh look at his many years work. Anyway -- thank you for spending time and giving explanations. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Thu, 03 Apr 2008 10:07:38 +0200, sam wrote: [EMAIL PROTECTED] 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 But one can tell because the way Python's syntax is based on indentation, no one has come up with a syntax for anonymous functions without the limitations of the current ``lambda``, that doesn't need 'curly braces' and is still as readable as Python is now. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
En Thu, 03 Apr 2008 05:20:48 -0300, sam [EMAIL PROTECTED] escribió: Gabriel Genellina napisał(a): 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 old code, or something. I meant the way instance methods acquire their self argument; the transformation from someobject.foo(arg1,arg2) into (ClassOfSomeobject.foo)(someobject, arg1, arg2) that classic classes do themselves and could not be changed nor extended. The descriptor protocol provides a way for attributes to modify the way they're handled; this is how instance methods get their self argument, and allows for the existence of class methods, static methods, and properties, among other things. The descriptor protocol is very important for Python and understanding it is a good idea, but not before you are rather fluent with the language or it will be fairly incomprehensible. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Wed, 2008-04-02 at 21:03 -0700, [EMAIL PROTECTED] wrote: On Apr 2, 5:41 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 2 avr, 22:23, Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] 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. 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? postgreSQL supports Python stored procedures. Take a look: http://www.postgresql.org/docs/8.1/static/plpython.html -Larry -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
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 solutions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
Gabriel Genellina napisał(a): 1. You have different syntax for named and unnamed (lambdas) functions. Functions and methods are different things in Python even if they have same syntax. But all these are still a pieces of code that you use repeatedly to make some task. 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 don't get the point - weren't you criticizing Python for having many different kind of functions? Yes. Funciton is always a piece of code (program) that does something. There is no need for different syntax. 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. What are those programmers needs? Programmers need to protect name in a namespace. Name mangling is not the best choice. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
sam a écrit : 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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
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 be 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, so maybe it is not so good? I would prefer to hear something like other solutions were very complex, and our zen says 'Simple is better than complex.', so we decided to use this simple and not perfect solution -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Apr 2, 10:52 am, sam [EMAIL PROTECTED] 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 solutions were very complex, and our zen says 'Simple is better than complex.', so we 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On 2 avr, 16:52, sam [EMAIL PROTECTED] wrote: 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 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, 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 we decided to use this simple and not perfect solution Simple, indeed. But why not perfect ? What else would you want ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
[EMAIL PROTECTED] [EMAIL PROTECTED] 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/WG14/www/docs/n1250.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On 2 avr, 20:46, Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] 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. 3http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1250.pdf 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
[EMAIL PROTECTED] [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
En Wed, 02 Apr 2008 09:23:21 -0300, sam [EMAIL PROTECTED] escribió: Gabriel Genellina napisał(a): 1. You have different syntax for named and unnamed (lambdas) functions. Functions and methods are different things in Python even if they have same syntax. But all these are still a pieces of code that you use repeatedly to make some task. 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 don't get the point - weren't you criticizing Python for having many different kind of functions? 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. What are those programmers needs? 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/ppt/regrets/PythonRegrets.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/python-dev/2006-February/060415.html -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On 2 avr, 22:23, Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] 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. Care to elaborate ? Or are we supposed to guess ?-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Apr 2, 5:41 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 2 avr, 22:23, Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] 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. 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
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
Re: Prototype OO
Diez B. Roggisch napisał(a): no inheritance model in Javascript. Or why does each JS-lib provide it's own version of an extend-function [1]? Ok -- thank you! The only point you might have is the somwhat unfortunate distinction between lambda and function in python - but this is on a syntactical level only. Once created, you can use them as you like. Yes -- everybody searches for a perfect language to his needs... -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
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. Functions and methods are different things in Python even if they have same syntax. But all these are still a pieces of code that you use repeatedly to make some task. 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. Some opinions: 1. In early days you could do OOP in C -- you just used additional parameter in a function. 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? 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. 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? Again this is not only my opinion -- http://www.crockford.com/javascript/private.html. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
sam wrote: 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. Functions and methods are different things in Python even if they have same syntax. But all these are still a pieces of code that you use repeatedly to 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 parameter in a function. 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? 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. 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 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? 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
Steve Holden napisał(a): 1. You have different syntax for named and unnamed (lambdas) functions. Functions and methods are different things in Python even if they have same syntax. But all these are still a pieces of code that you use repeatedly to make some task. 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 implementation 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
En Mon, 31 Mar 2008 07:59:13 -0300, sam [EMAIL PROTECTED] escribió: Steve Holden napisał(a): 1. You have different syntax for named and unnamed (lambdas) functions. Functions and methods are different things in Python even if they have same syntax. But all these are still a pieces of code that you use repeatedly to make some task. 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 don't get the point - weren't you criticizing Python for having many different kind of functions? 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Mar 26, 3:14 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Wed, 26 Mar 2008 02:03:24 -0300, Gabriel Genellina [EMAIL PROTECTED] declaimed the following in comp.lang.python: No:http://en.wikipedia.org/wiki/Saruman Ask him any time over. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
sam a écrit : Bruno Desthuilliers napisał(a): In dynamically typed language when you create object A that is inherited from another object B, than object A knows that B is his predecessor. So when you reference A.prop, then prop is looked in A first, then in B, then in predecessors of B, and so on. What you're describing here is the inheritance mechanism of Python. And could apply just as well to javascript prototype mechanism. A javascript object has a reference to it's prototype object - that you can customize, rebind etc -, a Python object has a reference to it's class object - that you can customise, rebind etc... 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 I have to disagree here. (eg functions, methods and lambdas are differen beeing in Python concept). The lambda statement creates an ordinary function object, so no difference here - and it has nothing to do with classes vs prototypes. wrt/ functions and methods, what you declare with a def statement within a class statement is actually a plain function (and FWIW, you can add dynamically add methods to classes or instances). Python 'methods' are only thin callable wrappers around the function/class/instance set, wrappers that are dynamically generated by the function object itself when it's looked up on a class or instance, thanks to the descriptor protocol. Don't be fooled by the term class itself - it's meaning is totally different in a language like Python. Probably I'm not alone. Many people who think dymanic types are Rhight Thing in programming will also prefer prototype-based programming to class-based. Chapter and verse, please ? Ok, I repeat (please read more carefully): Don't be fooled by the term class itself - it's meaning is totally different in a language like Python. suspect you don't have a serious knowledge of Python's object model. Yes -- I'm new to Python. So may I suggest you actually *learn* how Python's object model works ? -- http://mail.python.org/mailman/listinfo/python-list
RE: Prototype OO
John Machin wrote: On Mar 23, 12:32 am, Diez B. Roggisch [EMAIL PROTECTED] wrote: John Machin schrieb: On Mar 21, 11:48 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: [1] Just one example:http://docs.mootools.net/Class/Class.js Mootools being something a coworker might use? I don't understand the question. Diez It presupposes that the reader on first seeing coworker has mentally decomposed it as cow-ork-er. As an aside, having lived much of my early life on a hobby farm, I've often wondered to myself just what cow-orking involves ... ;) Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Mar 25, 11:24 pm, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Wed, 26 Mar 2008 06:49:57 +0800, Delaney, Timothy (Tim) [EMAIL PROTECTED] declaimed the following in comp.lang.python: As an aside, having lived much of my early life on a hobby farm, I've often wondered to myself just what cow-orking involves ... ;) Probably millennia too late to ask Saruman... G Solomon? -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
En Wed, 26 Mar 2008 01:27:15 -0300, [EMAIL PROTECTED] escribió: On Mar 25, 11:24 pm, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Wed, 26 Mar 2008 06:49:57 +0800, Delaney, Timothy (Tim) [EMAIL PROTECTED] declaimed the following in comp.lang.python: As an aside, having lived much of my early life on a hobby farm, I've often wondered to myself just what cow-orking involves ... ;) Probably millennia too late to ask Saruman... G Solomon? No: http://en.wikipedia.org/wiki/Saruman -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
John Machin schrieb: On Mar 21, 11:48 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: [1] Just one example:http://docs.mootools.net/Class/Class.js Mootools being something a coworker might use? I don't understand the question. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Mar 23, 12:32 am, Diez B. Roggisch [EMAIL PROTECTED] wrote: John Machin schrieb: On Mar 21, 11:48 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: [1] Just one example:http://docs.mootools.net/Class/Class.js Mootools being something a coworker might use? I don't understand the question. Diez It presupposes that the reader on first seeing coworker has mentally decomposed it as cow-ork-er. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
sam a écrit : Bruno Desthuilliers napisał(a): Most of the arguments in favor of prototypes seems to come to, mainly: 1/ it lets you customize behaviour on a per-object base 2/ it removes the mental overhead of inheritance, classes etc Point 1. is a non-problem in Python, since you can already add/replace methods on a per-objec basis (ok, with a couple restrictions wrt/ __magic__ methods and such). Point 2. is not (IMHO) such a problem in Python, where inheritance is mainly an implementation detail (it's not needed for polymorphic dispatch to work) and class hierarchy tend to be very flat, when they even exist. Mainly, Python's object system is actually quite close to javascript here. That is, you get more or less the same flexibility. And a couple of powerful features you don't have with javascript (like hooks in the attribute lookup mechanism), too. Thanks for precise opinion and spending your time. I think that when you use statically typed language, than you have to define classes, because compiler has to know what is allowed to do with instances of that class. But when you use dynamically typed language, then classes are redundant, because object is looked at when it is referenced. Dynamically typed language needs only objects hierarchy and you can add properties (methods, values) to that object during program execution. Dynamic typing does not necessarily imply that you can add properties of modify behaviour at runtime. Most dynamically typed languages let you do that, but that's still orthogonal. And FWIW, you could emulate this in static languages using a hashtable, functors, and a couple accessors (a la __getattr__/__setattr__). In dynamically typed language when you create object A that is inherited from another object B, than object A knows that B is his predecessor. So when you reference A.prop, then prop is looked in A first, then in B, then in predecessors of B, and so on. What you're describing here is the inheritance mechanism of Python. And could apply just as well to javascript prototype mechanism. A javascript object has a reference to it's prototype object - that you can customize, rebind etc -, a Python object has a reference to it's class object - that you can customise, rebind etc... Don't be fooled by the term class itself - it's meaning is totally different in a language like Python. I may be plain wrong here but I suspect you don't have a serious knowledge of Python's object model. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
Bruno Desthuilliers napisał(a): In dynamically typed language when you create object A that is inherited from another object B, than object A knows that B is his predecessor. So when you reference A.prop, then prop is looked in A first, then in B, then in predecessors of B, and so on. What you're describing here is the inheritance mechanism of Python. And could apply just as well to javascript prototype mechanism. A javascript object has a reference to it's prototype object - that you can customize, rebind etc -, a Python object has a reference to it's class object - that you can customise, rebind etc... 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). Don't be fooled by the term class itself - it's meaning is totally different in a language like Python. Probably I'm not alone. Many people who think dymanic types are Rhight Thing in programming will also prefer prototype-based programming to class-based. suspect you don't have a serious knowledge of Python's object model. Yes -- I'm new to Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Fri, 21 Mar 2008 11:43:33 +0100, sam wrote: 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
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). Sorry, but that is utter nonsense. It begins with the fact that there is no inheritance model in Javascript. Or why does each JS-lib provide it's own version of an extend-function [1]? Which one has to grasp before really being able to use inheritance in JS. And of course everybody does it a bit different, including possible access to parent classes and such. Calling that an advantage is rather bold. And it continues with the abnomination the implicit this in Javascript is - e.g. MochiKit offers a bindThis-method to ensure that a method-call always gets the actual instance passed as this - something that can get lost when dealing with event-handling. Whereas python here offers the bound-method-concept. The only point you might have is the somwhat unfortunate distinction between lambda and function in python - but this is on a syntactical level only. Once created, you can use them as you like. I do like JS for what it is - but everybody who uses it in an OO-manner ends up inventing the same wheels Python already comes with. Diez [1] Just one example: http://docs.mootools.net/Class/Class.js -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Mar 21, 11:48 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: [1] Just one example:http://docs.mootools.net/Class/Class.js Mootools being something a coworker might use? -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
sam a écrit : Some time ago (2004) there were talks about prototype-based languages and Prothon emerged. Can someone tell me why class-based OO is better that Prototype based, For which definition of better ?-) especially in scripting langage with dynamic types as Python is? Here are some links: http://c2.com/cgi/wiki?PrototypeBasedProgramming Most of the arguments in favor of prototypes seems to come to, mainly: 1/ it lets you customize behaviour on a per-object base 2/ it removes the mental overhead of inheritance, classes etc Point 1. is a non-problem in Python, since you can already add/replace methods on a per-objec basis (ok, with a couple restrictions wrt/ __magic__ methods and such). Point 2. is not (IMHO) such a problem in Python, where inheritance is mainly an implementation detail (it's not needed for polymorphic dispatch to work) and class hierarchy tend to be very flat, when they even exist. Mainly, Python's object system is actually quite close to javascript here. That is, you get more or less the same flexibility. And a couple of powerful features you don't have with javascript (like hooks in the attribute lookup mechanism), too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
Bruno Desthuilliers napisał(a): Most of the arguments in favor of prototypes seems to come to, mainly: 1/ it lets you customize behaviour on a per-object base 2/ it removes the mental overhead of inheritance, classes etc Point 1. is a non-problem in Python, since you can already add/replace methods on a per-objec basis (ok, with a couple restrictions wrt/ __magic__ methods and such). Point 2. is not (IMHO) such a problem in Python, where inheritance is mainly an implementation detail (it's not needed for polymorphic dispatch to work) and class hierarchy tend to be very flat, when they even exist. Mainly, Python's object system is actually quite close to javascript here. That is, you get more or less the same flexibility. And a couple of powerful features you don't have with javascript (like hooks in the attribute lookup mechanism), too. Thanks for precise opinion and spending your time. I think that when you use statically typed language, than you have to define classes, because compiler has to know what is allowed to do with instances of that class. But when you use dynamically typed language, then classes are redundant, because object is looked at when it is referenced. Dynamically typed language needs only objects hierarchy and you can add properties (methods, values) to that object during program execution. In dynamically typed language when you create object A that is inherited from another object B, than object A knows that B is his predecessor. So when you reference A.prop, then prop is looked in A first, then in B, then in predecessors of B, and so on. Having object A you can access its predecessor B. When you have access to object B, then you can add properties to it and these properties could be accessed by all other objects inherited from B. You can do all these things in Python. But why it uses classes? So you can say: CLASS BASED PROGRAMMING == STATICALY TYPED LANGUAGE -- http://mail.python.org/mailman/listinfo/python-list
Re: Prototype OO
On Wed, 19 Mar 2008 17:59:40 +0100, sam wrote: Can someone tell me why class-based OO is better that Prototype based, especially in scripting langage with dynamic types as Python is? Is it better!? Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
