Re: Not fully OO ?
Lawrence D'Oliveiro a écrit : In message [EMAIL PROTECTED], James Mills wrote: On Fri, Sep 26, 2008 at 8:20 AM, Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: Object orientation IS procedural. Correction: OOP is Imperative. No, procedural. Nope, imperative !-) The functional unit is called an expression, the encapsulation of which is called a function. Hence functional. Similarly, the procedural unit is commonly called a statement, the encapsulation of which is a procedure, not an imperator. Hence procedural. imperative means that the computation is done through statements that modify the program's state. procedural means that these statements are organized in procedures, that group a serie of statements. OO is based on objects (that carry and manage internal state) and messages. A message can happen to trigger a serie of statements that modifies a program state, so you could say (and this wouldn't be totally false) that an OO method can be seen as a procedure (or at least some methods...), but the whole program's organization is still not the same as one seen in procedural programming. IOW, it's more a matter of how you design / organize your (otherwise imperative) program than anything else. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
In message [EMAIL PROTECTED], James Mills wrote: On Fri, Sep 26, 2008 at 8:20 AM, Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: Object orientation IS procedural. Correction: OOP is Imperative. No, procedural. The functional unit is called an expression, the encapsulation of which is called a function. Hence functional. Similarly, the procedural unit is commonly called a statement, the encapsulation of which is a procedure, not an imperator. Hence procedural. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
In message [EMAIL PROTECTED], Aaron Castironpi Brady wrote: I understand that formal proof systems, as well as automated theorem provers, have been difficult to develop. The basic problem is: having proved that a program satisfies certain formally-specified criteria, how do you prove that those formal criteria specifications actually correspond to the original problem you were trying to solve? The proof just pushes the correctness problem back another level. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Tim Rowe a écrit : 2008/9/26 Bruno Desthuilliers [EMAIL PROTECTED]: Not to start a troll, but from what I've seen of C# so far I do find this a bit surprising and really suspect more of a library issue than a language one. Care to tell more about the problem and solution ? (NB : I wouldn't even asked if you had mentionned say Erlang or Prolog or OCaml - well, some mostly different language - instead of C#) IIRC it was library issues -- for one thing I still find it a lot harder to manage an MS Windows GUI under Python than I do under .NET (I've never succeeded in getting Iron Python to run properly). In one sense you could argue that that's not a language issue, and you'd be right: there's nothing in the syntax or semantics of either language that makes it so. But in another sense I'd say it is a language issue (and of course I think I'm right!) And - after reading the following argument - I think you're wrong !-) because Python aims to be platform independent, and whilst that means gains in portability it means that in return it loses the ease-of-programming of a tightly integrated platform. Still a library issue. Python doesn't defines platform-independant the way Java does, and there are quite a couple Python packages (third-part or even in the standard lib) that are clearly platform-specific - including MS Windows COM stuff, which was a major PITA using VB6. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
2008/9/28 Aaron Castironpi Brady [EMAIL PROTECTED]: Before I tried wxFormBuilder, I imagined that C# would be vastly faster to develop than Python, for anything requiring any non-trivial graphical interface. I've done extensive VB, so I can attest to that personally. It is not. I'm confused about where VB comes in -- I find VB just *slightly* harder than INTERCAL. C# I find fairly easy. You can come up with examples that favor either. But the opposite of statistical is anecdotal. Sorry again. Yes, it's anecdotal, but development time isn't just about how fast the program is to type (otherwise, why aren't we all using APL?) The last time I 'checked in' at your post, your claim was an hour or so vs. ages. Hence my responses. You could probably sneak by by claiming a factor of *two*, but if you were exaggerating, please say so at any time. Ok. I was exaggerating when I said that VB was harder than INTERCAL. It's marginally easier. As for the program I was working on, I worked for over a day on it in Python, and did it in about an hour in C#, although in fairness I didn't forget all the thinking I'd done on the previous day. I have a lot more Python experience than C# experience, but don't claim to be a guru in either. And no, I don't work two hour days (unfortunately). I have indicated that the GUI wasn't the only issue; in C# it was just easy in that case to find all the library bits I needed to in order to accomplish the task. It isn't always so. on this, that it's pretty generally applicable I'm with you on that. I do not believe that C# is pretty generally applicable. I agree on that, but *only* because it's a proprietary language with imperfect support once you move away from the .net platform. It's a generally applicable language to .net, but .net is not a general platform. fact, outside of my VB, COM, and MFC experience, you could say I have no clue. Very tongue in cheek.) If you see C# as being in any way related to VB, it's no wonder you're down on it! Python has a lot of things C# doesn't. Can we agree on that? And C# has things that Python doesn't (such as static typing). Can we agree on that, too? -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Fri, Sep 26, 2008 at 1:11 PM, Bruno Desthuilliers [EMAIL PROTECTED] wrote: Steven D'Aprano a écrit : On Fri, 26 Sep 2008 17:00:59 +0200, Bruno Desthuilliers wrote: Patrick Mullen a écrit : Depending on the scale of the website I am making, how much I care about editing it in the future, and how much I just want to get something up, I will occasionally use php. And I am a self confessed php hater :) But it's generally the fastest way I know to get something up. So even terrible languages can have their uses! Sorry but I fail to see how it relates to the current thread ??? I think Patrick is responding to a comment from Tino Wildenhain: That didn't showed here (reading this from c.l.py via free.fr). Sorry. [quote] Well then it still depends on the perception of job done. For example PHP programmers would bet their soul that their language of choice is exactly the right one to get the job done. [end quote] Patrick, you will cause much less confusion if you quote relevant parts of the text you are replying too. Indeed. At least it would have made clear (to me) there was something missing in the thread... -- http://mail.python.org/mailman/listinfo/python-list Whoops, sorry for the confusion everyone. Usually I do keep the comments, don't know what happened there. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 28, 4:41 pm, Tim Rowe [EMAIL PROTECTED] wrote: 2008/9/28 Aaron Castironpi Brady [EMAIL PROTECTED]: Before I tried wxFormBuilder, I imagined that C# would be vastly faster to develop than Python, for anything requiring any non-trivial graphical interface. I've done extensive VB, so I can attest to that personally. It is not. I'm confused about where VB comes in -- I find VB just *slightly* harder than INTERCAL. C# I find fairly easy. You can come up with examples that favor either. But the opposite of statistical is anecdotal. Sorry again. Yes, it's anecdotal, but development time isn't just about how fast the program is to type (otherwise, why aren't we all using APL?) The last time I 'checked in' at your post, your claim was an hour or so vs. ages. Hence my responses. You could probably sneak by by claiming a factor of *two*, but if you were exaggerating, please say so at any time. Ok. I was exaggerating when I said that VB was harder than INTERCAL. It's marginally easier. As for the program I was working on, I worked for over a day on it in Python, and did it in about an hour in C#, although in fairness I didn't forget all the thinking I'd done on the previous day. I have a lot more Python experience than C# experience, but don't claim to be a guru in either. And no, I don't work two hour days (unfortunately). I have indicated that the GUI wasn't the only issue; in C# it was just easy in that case to find all the library bits I needed to in order to accomplish the task. It isn't always so. on this, that it's pretty generally applicable I'm with you on that. I do not believe that C# is pretty generally applicable. I agree on that, but *only* because it's a proprietary language with imperfect support once you move away from the .net platform. It's a generally applicable language to .net, but .net is not a general platform. fact, outside of my VB, COM, and MFC experience, you could say I have no clue. Very tongue in cheek.) If you see C# as being in any way related to VB, it's no wonder you're down on it! Python has a lot of things C# doesn't. Can we agree on that? And C# has things that Python doesn't (such as static typing). Can we agree on that, too? -- Tim Rowe Maybe too much of my personal life is affecting my judgment of C#. You mention tools (that are doing the work for you) and I think incompatibility. Maybe that part is just because I feel like tools are like 'excuses'. And maybe that part is just because... awkward. I'm going to have to bow out of the dispute, sorry, because I am not a person that knows both of them. (How you decide who knows a language isn't exactly clear, by the way. It's been stated, for example, that I don't know Python, as well as that I don't know English.) You said C# = 1 hour, Python = ages. I said I could see that if it came to developing a GUI with a draw-on tool in one and not in the other. (Write that C# GUI spec by hand or position your controls from scratch.) You could make a case that you can get bad habits from developing in a tightly-coupled (tightly-integrated) framework, as you suggested C# was. I would agree to it. I do not find that the Python library is particularly lacking, and the VB6 library was. If you're referring to documentation, though, I really like the win32 API docs. They're precise and thorough. The Python docs leave some stuff unsaid; there's a lot of stuff you can do in Python that people have to tell you or you have to discover on your own. Which one are the C# docs like? Not to reopen the wound, or rather to reopen it patiently: I classify 'static-typing' as handcuffs. C# has handcuffs and lots of kinds of them. But static-typing lets you do fill in the blank. ? Other than that, I don't know of any examples, from which I won't infer that there aren't any. (That was -won't- infer.) Call, I guess; I'll bite. What? If you're referring to library depth, there's a lot of stuff that probably classifies as wheel reinvention that shouldn't necessarily go in the library. There was a good example today. 'Return a string of 5 random digits.' You could put that in the library, and call it 'RandomDigitString( int length )'. Doing it by hand only takes one line though: '%05i%random.randint(0,9)'. Does it belong in the library? Otherwise you're technically reinventing the wheel, right? If you want to talk about your application, the day-to-hour ratio example, please do. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
2008/9/27 Aaron Castironpi Brady [EMAIL PROTECTED]: No way. It's *zero* instead of one, if so, because the only thing C# has is a bunch of handcuffs and implicit 'self'. You have a line like: You don't follow what I said, and from your tone I get the feeling you don't *want* to follow what I'm saying, not because I'm criticising Python (I'm not), but because I'm guilty of the heresy of suggesting that it's not actually simultaneoulsy optimised for every possible use. My point is that there are zero parameters as far as I am concerned because I don't actually touch most of the GUI code. There could actually be hundreds of parameters, for all I care. They're not my concern. Most of the time I like that -- the tools are doing my work for me. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 27, 6:55 pm, Tim Rowe [EMAIL PROTECTED] wrote: 2008/9/27 Aaron Castironpi Brady [EMAIL PROTECTED]: No way. It's *zero* instead of one, if so, because the only thing C# has is a bunch of handcuffs and implicit 'self'. You have a line like: You don't follow what I said, and from your tone I get the feeling you don't *want* to follow what I'm saying, not because I'm criticising Python (I'm not), but because I'm guilty of the heresy of suggesting that it's not actually simultaneoulsy optimised for every possible use. My point is that there are zero parameters as far as I am concerned because I don't actually touch most of the GUI code. There could actually be hundreds of parameters, for all I care. They're not my concern. Most of the time I like that -- the tools are doing my work for me. -- Tim Rowe flamewar.avert( ), please. Yes, I agree, I did not follow every word. It's a fundamental disagreement about successful ways to communicate, and, for the philosophers, successful communication, whether I should have nitpicked first thing, or tried to go along with the gist. I tried the latter. In your case, I guessed wrong. Sorry. Before I tried wxFormBuilder, I imagined that C# would be vastly faster to develop than Python, for anything requiring any non-trivial graphical interface. I've done extensive VB, so I can attest to that personally. It is not. The difference in dev times is about the time it takes to write: def onClick( event ): ... controlA.bind( wx.MOUSEDOWN, onClick ) perhaps several times, which, glances at watch, is not long. You do get the IDE, true, and that code is auto-crafted for you. But 'wx' does give you data in an XML file, instead of a script. And talk about a difference in identifiers: form button pos20,30/pos colorgray/color /button /form vs. form.button.pos= 20, 30 form.button.color= gray You can come up with examples that favor either. But the opposite of statistical is anecdotal. Sorry again. The last time I 'checked in' at your post, your claim was an hour or so vs. ages. Hence my responses. You could probably sneak by by claiming a factor of *two*, but if you were exaggerating, please say so at any time. Penultimately, forgive my sarcasm--- I'm a bit feisty right now. I was distinguishing between arguments in particular, and identifiers in general. And lastly, simultaneoulsy optimised for every possible use is a bold claim that I didn't make, at least, to come forward, in so many words. I do believe, and it shows, as of today, and you can quote me on this, that it's pretty generally applicable, though I reserve the right to change my mind on the matter with or without notice. Especially if I learn something. I do not believe that C# is pretty generally applicable. I maintain that I will adjust that estimate if I ever get any facts about C#, since I don't have very many. (In fact, outside of my VB, COM, and MFC experience, you could say I have no clue. Very tongue in cheek.) In fact, do a Google for 'castironpi every possible'. You get a can't ... every possible, and your post, and something else. That's it. Python has a lot of things C# doesn't. Can we agree on that? -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
In message [EMAIL PROTECTED], Aaron Castironpi Brady wrote: Wikipedia puts it decently: mainly for OO programming, but with some procedural elements. Procedural is the opposite of functional, not object-oriented. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Lawrence D'Oliveiro a écrit : In message [EMAIL PROTECTED], Aaron Castironpi Brady wrote: Wikipedia puts it decently: mainly for OO programming, but with some procedural elements. Procedural is the opposite of functional, not object-oriented. AFAIK, the opposite if functional is imperative, not procedural. But let's not waste too much time on terminology arguments... -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Fri, 26 Sep 2008 09:58:39 +0200, Bruno Desthuilliers wrote: Procedural is the opposite of functional, not object-oriented. AFAIK, the opposite if functional is imperative, not procedural. But let's not waste too much time on terminology arguments... We're not wasting time on terminology arguments, we're wasting time on definitional debates. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Hi, Tim Rowe wrote: 2008/9/23 Craig Allen [EMAIL PROTECTED]: So python may turn out to be pure OO ... The question I usually ask is Does this language help me get the job done? Python often does. That's all that really matters, isn't it? Well then it still depends on the perception of job done. For example PHP programmers would bet their soul that their language of choice is exactly the right one to get the job done. :-) You and me would indeed see a different picture on the level of doneness of such jobs ;-) T. smime.p7s Description: S/MIME Cryptographic Signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Depending on the scale of the website I am making, how much I care about editing it in the future, and how much I just want to get something up, I will occasionally use php. And I am a self confessed php hater :) But it's generally the fastest way I know to get something up. So even terrible languages can have their uses! -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Patrick Mullen a écrit : Depending on the scale of the website I am making, how much I care about editing it in the future, and how much I just want to get something up, I will occasionally use php. And I am a self confessed php hater :) But it's generally the fastest way I know to get something up. So even terrible languages can have their uses! Sorry but I fail to see how it relates to the current thread ??? -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Fri, 26 Sep 2008 17:00:59 +0200, Bruno Desthuilliers wrote: Patrick Mullen a écrit : Depending on the scale of the website I am making, how much I care about editing it in the future, and how much I just want to get something up, I will occasionally use php. And I am a self confessed php hater :) But it's generally the fastest way I know to get something up. So even terrible languages can have their uses! Sorry but I fail to see how it relates to the current thread ??? I think Patrick is responding to a comment from Tino Wildenhain: [quote] Well then it still depends on the perception of job done. For example PHP programmers would bet their soul that their language of choice is exactly the right one to get the job done. [end quote] Patrick, you will cause much less confusion if you quote relevant parts of the text you are replying too. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
2008/9/26 Tino Wildenhain [EMAIL PROTECTED]: The question I usually ask is Does this language help me get the job done? Python often does. That's all that really matters, isn't it? Well then it still depends on the perception of job done. For example PHP programmers would bet their soul that their language of choice is exactly the right one to get the job done. :-) You and me would indeed see a different picture on the level of doneness of such jobs ;-) Well, I did say Often. Before now I've struggled for ages to write a Python program to do a job, then when I've tried C# all the problems have fallen away and the job was done in an hour or so. But other times it has been the other way around; I've done stuff in Python that I wouldn't know where to begin with in other languages. One of my constant refrains is that *no* tool is ideal for *all* jobs! -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 26, 11:48 am, Tim Rowe [EMAIL PROTECTED] wrote: 2008/9/26 Tino Wildenhain [EMAIL PROTECTED]: The question I usually ask is Does this language help me get the job done? Python often does. That's all that really matters, isn't it? Well then it still depends on the perception of job done. For example PHP programmers would bet their soul that their language of choice is exactly the right one to get the job done. :-) You and me would indeed see a different picture on the level of doneness of such jobs ;-) Well, I did say Often. Before now I've struggled for ages to write a Python program to do a job, then when I've tried C# all the problems have fallen away and the job was done in an hour or so. But other times it has been the other way around; I've done stuff in Python that I wouldn't know where to begin with in other languages. One of my constant refrains is that *no* tool is ideal for *all* jobs! -- Tim Rowe I thought procedural and imperative were the same. Sorry, but you forgot to phrase your expression in the form of a command. I'll take 'modules' for $500, Alex. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Steven D'Aprano a écrit : On Fri, 26 Sep 2008 09:58:39 +0200, Bruno Desthuilliers wrote: Procedural is the opposite of functional, not object-oriented. AFAIK, the opposite if functional is imperative, not procedural. But let's not waste too much time on terminology arguments... We're not wasting time on terminology arguments, we're wasting time on definitional debates. Point taken. But still a waste of time !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Steven D'Aprano a écrit : On Fri, 26 Sep 2008 17:00:59 +0200, Bruno Desthuilliers wrote: Patrick Mullen a écrit : Depending on the scale of the website I am making, how much I care about editing it in the future, and how much I just want to get something up, I will occasionally use php. And I am a self confessed php hater :) But it's generally the fastest way I know to get something up. So even terrible languages can have their uses! Sorry but I fail to see how it relates to the current thread ??? I think Patrick is responding to a comment from Tino Wildenhain: That didn't showed here (reading this from c.l.py via free.fr). Sorry. [quote] Well then it still depends on the perception of job done. For example PHP programmers would bet their soul that their language of choice is exactly the right one to get the job done. [end quote] Patrick, you will cause much less confusion if you quote relevant parts of the text you are replying too. Indeed. At least it would have made clear (to me) there was something missing in the thread... -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Tim Rowe a écrit : 2008/9/26 Tino Wildenhain [EMAIL PROTECTED]: The question I usually ask is Does this language help me get the job done? Python often does. That's all that really matters, isn't it? Well then it still depends on the perception of job done. For example PHP programmers would bet their soul that their language of choice is exactly the right one to get the job done. :-) You and me would indeed see a different picture on the level of doneness of such jobs ;-) Well, I did say Often. Before now I've struggled for ages to write a Python program to do a job, then when I've tried C# all the problems have fallen away and the job was done in an hour or so. Not to start a troll, but from what I've seen of C# so far I do find this a bit surprising and really suspect more of a library issue than a language one. Care to tell more about the problem and solution ? (NB : I wouldn't even asked if you had mentionned say Erlang or Prolog or OCaml - well, some mostly different language - instead of C#) -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 26, 11:48 am, Tim Rowe [EMAIL PROTECTED] wrote: 2008/9/26 Tino Wildenhain [EMAIL PROTECTED]: The question I usually ask is Does this language help me get the job done? Python often does. That's all that really matters, isn't it? Well then it still depends on the perception of job done. For example PHP programmers would bet their soul that their language of choice is exactly the right one to get the job done. :-) You and me would indeed see a different picture on the level of doneness of such jobs ;-) Well, I did say Often. Before now I've struggled for ages to write a Python program to do a job, then when I've tried C# all the problems What problems? have fallen away and the job What job? was done in an hour or so. But other times it has been the other way around; I've done stuff in Python that I wouldn't know where to begin with in other languages. One of my constant refrains is that *no* tool is ideal for *all* jobs! -- Tim Rowe If you have wxFormBuilder and the win32 library, it's pretty fast. Python's philosophy is to make common things easy and everything possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
2008/9/26 Bruno Desthuilliers [EMAIL PROTECTED]: Not to start a troll, but from what I've seen of C# so far I do find this a bit surprising and really suspect more of a library issue than a language one. Care to tell more about the problem and solution ? (NB : I wouldn't even asked if you had mentionned say Erlang or Prolog or OCaml - well, some mostly different language - instead of C#) IIRC it was library issues -- for one thing I still find it a lot harder to manage an MS Windows GUI under Python than I do under .NET (I've never succeeded in getting Iron Python to run properly). In one sense you could argue that that's not a language issue, and you'd be right: there's nothing in the syntax or semantics of either language that makes it so. But in another sense I'd say it is a language issue (and of course I think I'm right!) because Python aims to be platform independent, and whilst that means gains in portability it means that in return it loses the ease-of-programming of a tightly integrated platform. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
2008/9/26 Aaron Castironpi Brady [EMAIL PROTECTED]: If you have wxFormBuilder and the win32 library, it's pretty fast. Speed has never been an issue for me with Python. For my masters degree I did a project that involved a lot of number crunching, and in my proposal I wrote that I'd use Python for most of the code and C for any parts that were unacceptably slow. In practice, not only did I never need to replace any parts with C, I never even needed to use numpy; it was quite fast enough as it was. Python's philosophy is to make common things easy and everything possible. But what's common for one person may be uncommon for another. And sometimes possible isn't enough, or we'd all be using INTERCAL! Another, quite different example to the one I was referring to earlier is the fact that I often work with safety critical systems. I don't think formal proof of program behaviour would be at all straightforward in Python (or C# for that matter, and although Spec# gets closer, it really needs a language like Spark Ada). -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 26, 6:40 pm, Tim Rowe [EMAIL PROTECTED] wrote: 2008/9/26 Aaron Castironpi Brady [EMAIL PROTECTED]: If you have wxFormBuilder and the win32 library, it's pretty fast. Speed has never been an issue for me with Python. For my masters degree I did a project that involved a lot of number crunching, and in my proposal I wrote that I'd use Python for most of the code and C for any parts that were unacceptably slow. In practice, not only did I never need to replace any parts with C, I never even needed to use numpy; it was quite fast enough as it was. Python's philosophy is to make common things easy and everything possible. But what's common for one person may be uncommon for another. And sometimes possible isn't enough, or we'd all be using INTERCAL! Another, quite different example to the one I was referring to earlier is the fact that I often work with safety critical systems. I don't think formal proof of program behaviour would be at all straightforward in Python (or C# for that matter, and although Spec# gets closer, it really needs a language like Spark Ada). -- Tim Rowe No. I understand that formal proof systems, as well as automated theorem provers, have been difficult to develop. When I took ML, the homeworks were to prove the correctness of an interpretation of a program, and the unique existence of a meaning by induction. But I, and I imagine I'm not the only one, would love to know the example that C# developed faster than Python. I suppose the fact that the line of wx specification that has two identifiers where C# has one is more of a drain on programmer resources than may commonly be recognized--- not the same as the cost of one extra word in a paper or in an editorial. Similarly, maybe the program that has one extra identifier in a line takes a lot more time to develop. Perhaps it's the 7 +/- 1 trend in attention span that makes the difference large in that case. 8 identifiers would in that theory be a big deal, so the example in C# could make the case for it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
2008/9/27 Aaron Castironpi Brady [EMAIL PROTECTED]: But I, and I imagine I'm not the only one, would love to know the example that C# developed faster than Python. I suppose the fact that the line of wx specification that has two identifiers where C# has one is more of a drain on programmer resources than may commonly be recognized--- not the same as the cost of one extra word in a paper or in an editorial. Similarly, maybe the program that has one extra identifier in a line takes a lot more time to develop. But I didn't use wx -- that's rather the point. Long before the days of Python, I kept wanting to use Modula2 but kept getting driven back to C because in Modula2 I kept having to write stuff that was already in C libraries. Modula2 was a far better language, but C usually was far more productive because of what went around it. C#'s tight integration with .net and VS mean that it's not a question of one identifier instead of two, it's *zero* identifiers instead of two because the tool does it all for me. Does that mean that C# is a better language than Python? No, of course not. Does it mean that what I was doing was not possible in Python? No, of course not. Does it mean that C# was more productive than Python for me doing that particular job? Yes it does. (FWIW, I also found the .net XML handling easier to cope with on that same job). One day Iron Python plus the VS integration might wean me off C# but last time I looked it wasn't close. Maybe I should take another look and see how it's coming on. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 26, 8:10 pm, Tim Rowe [EMAIL PROTECTED] wrote: 2008/9/27 Aaron Castironpi Brady [EMAIL PROTECTED]: But I, and I imagine I'm not the only one, would love to know the example that C# developed faster than Python. I suppose the fact that the line of wx specification that has two identifiers where C# has one is more of a drain on programmer resources than may commonly be recognized--- not the same as the cost of one extra word in a paper or in an editorial. Similarly, maybe the program that has one extra identifier in a line takes a lot more time to develop. But I didn't use wx -- that's rather the point. Long before the days of Python, I kept wanting to use Modula2 but kept getting driven back to C because in Modula2 I kept having to write stuff that was already in C libraries. Modula2 was a far better language, but C usually was far more productive because of what went around it. C#'s tight integration with .net and VS mean that it's not a question of one identifier instead of two, it's *zero* identifiers instead of two because the tool does it all for me. Does that mean that C# is a better language than Python? No, of course not. Does it mean that what I was doing was not possible in Python? No, of course not. Does it mean that C# was more productive than Python for me doing that particular job? Yes it does. (FWIW, I also found the .net XML handling easier to cope with on that same job). One day Iron Python plus the VS integration might wean me off C# but last time I looked it wasn't close. Maybe I should take another look and see how it's coming on. -- Tim Rowe No way. It's *zero* instead of one, if so, because the only thing C# has is a bunch of handcuffs and implicit 'self'. You have a line like: n= aTree.ExpandedCount What in 'wx', which I -am- using, avoids insubordinate tone, takes more identifiers: n= self.aTree.ExpandedCount or if you're 'inlining', for lack of better words, everything, outside a class, n= aForm.aTree.ExpandedCount. For a grand total of 1 'aForm' identifier that C# infers implicitly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
In message [EMAIL PROTECTED], Craig Allen wrote: It is clearly possible to write procedural code... that is, Python does not force object oriented syntax or concepts on you ... Object orientation IS procedural. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
In message [EMAIL PROTECTED], candide wrote: ... Python supports OOP and classes to an extent, but is not a full OOP language. Python allows you to use OO-style constructs, but doesn't force you to have inheritance and subclasses if you don't want to. Duck typing is usually a much more flexible approach. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Fri, Sep 26, 2008 at 8:20 AM, Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: Object orientation IS procedural. Correction: OOP is Imperative. --JamesMills -- -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
2008/9/23 Craig Allen [EMAIL PROTECTED]: So python may turn out to be pure OO I think that's the sort of thing the pedants would hang that hats on, too. Python isn't *pure* OO, in that it lets the programmers do non-OO if they want to, but it is *fully* OO in that it includes everything required to do OO. But maybe the original blogger meant by fully OO what I mean by Pure OO? The question I usually ask is Does this language help me get the job done? Python often does. That's all that really matters, isn't it? -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
if they want to, but it is *fully* OO in that it includes everything required to do OO. But maybe the original blogger meant by fully OO what I mean by Pure OO? it seems to me this is what was meant... pure OO, AND forced to use it. My personal feeling is that python is multiparadigmed and I'm more than fine with that. BUT, I am going to hold onto what I've noticed which is that Python seems to use OO deeply, well into the interpreter, and that the procedural styles available at the Python source level pretty much are built on top of this OO model, given you accept a module as an object, which it seems to be within the source code... but in the end, it's just words and the most important thing is that python is a tool you can use to make a computer do what you want, and whatever you call it may just be a distraction. cheers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Kay Schluehr wrote: On 20 Sep., 23:07, Aaron \Castironpi\ Brady [EMAIL PROTECTED] wrote: On Sep 20, 3:22 pm, Kay Schluehr [EMAIL PROTECTED] wrote: On 20 Sep., 18:33, Bruno Desthuilliers [EMAIL PROTECTED] wrote: The following definitions are AFAIK the only commonly accepted definitions about OO: 1/ an object is defined by identity, state and behaviour 2/ objects interacts by sending messages each other 3/ an OO program is made of interacting objects I let you find out whether Python meets these 3 definitions - and if Java does (hint : in Python, everything you can bind to a name is an object - this is not true in Java or C++). This is correct but it detracts from a more general problem of language paradigms. Assume you type 2+2 4 Now you are free to interpret this as a simple, primitive arithmetic operation but you can also claim that 2 sends an __add__ message to 2. Hereby the state of the 2 objects are not altered but a new 4 object is created. OO babble is more impressive isn't it? Actually it is simply wrong in the mentioned case and here is the proof: def foo(): return 2+2 import dis dis.dis(foo) 2 0 LOAD_CONST 2 (4) 3 RETURN_VALUE OO is a heuristic method used to understand the semantics of a programming language. It can also inspire language design but as you've rightly said: jugde yourself and see how far you get with it. Applying OO on interpreter level is by no means a sign of a high quality implementation whereas structuring programs in the large will likely benefit from class based organization and encapsulation. Of course one can also reverse the value hierarchy and find perverse joy in having a pure OO language but apply monkey patching everywhere. I suppose you know which language I'm talking about... It sounds like you think that you -can- write OO programs in Python, but you don't have to. I agree. The whole point of OO is providing high level ( system level ) not low level ( interpreter level ) semantics. Partitioning a system into isolated and communicating objects is a strong and important metaphor. Recently there were some comments on the web that mentioned Erlang to be pretty much OO in this respect although Erlang is functional and has no base level notion of an object. It's even well known that Joe Armstrong holds low opinions about the entire object business. Notice that I believe that the popular meme that OO is bolted on Python has little if nothing to do with OO itself but with API consistency. When people have to type len(x) instead of x.len() this breaks their expectations on how the language has to behave. x.__len__() -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
It is clear to me that Python is a multiparadigmed object oriented language. It is clearly possible to write procedural code... that is, Python does not force object oriented syntax or concepts on you and insist you define everything in such a structure. Is the OO it allows full OO, I think so, and the only way to argue otherwise I think is to point out that the main function is just the module level itself, and is not part of an object... which is just the sort of pedantic things purists like to hang their hat on. personally I am very much the sort that believe in trust the programmer and likes languages that provide a freedom to use various complementary paradigms, in the style of C++. Compared to that, it's clear that Python is quite object oriented even in the sense of drawing you to build things in object oriented ways... just not strictly requiring it. Which is good, it allows some interesting patterns which play quite well with object oriented desirgn (i.e. module as singleton)... in fact, that plays so well as a singleton, some would say the module is just an object anyway, and indeed, the intepreter tends to agree. So python may turn out to be pure OO, where Objects SIMULATE procedural programming paradigms and allow that paradigm as a result, on top of OO. cheers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Hi! Everything ... are an object. It's true ; but a language built around the objects, and OOP, are two different concepts. @-salutations -- Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Bonjour ! AMHA, ceux qui ont écrit ce texte ont une mauvaise idée de ce que sont les variables en Python. Ils ont sans doute trop en tête les notions des variables en C ou en Basic, et ne se sont pas penchés sur les spécificités de Python. @-salutations -- Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Christian Heimes wrote: Kay Schluehr wrote: Actually it is simply wrong in the mentioned case [...] It's not wrong. You have found a simple optimization. Lot's of compilers for lots of languages optimize code by code folding. I don't think he meant that Python is wrong somehow, but that the OO babble of what happens for 2+2 is wrong. The babble said that, when the code is executed, an __add__ message is sent to the 2 object, with another 2 object as the parameter. That statement is incorrect: no message is sent at all, but the result is available even before the program starts. FWIW, 2+2 is not a good case for OO in Smalltalk, either. In a typical implementation, SmallInteger is not a real class, in the sense that 2 is not a real object. Instead, it lives in a tagged pointer, i.e. it has no identity. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Martin v. Löwis wrote: I don't think he meant that Python is wrong somehow, but that the OO babble of what happens for 2+2 is wrong. The babble said that, when the code is executed, an __add__ message is sent to the 2 object, with another 2 object as the parameter. That statement is incorrect: no message is sent at all, but the result is available even before the program starts. On the other hand, the inability to distinguish between as if and hah, I've looked under the covers isn't necessarily a good trait for a programmer. If he bases his mental model on concrete implementation details of a production quality software product, he's bound to end up with a cargo-cultish understanding of fundamental issues. If he uses it to win arguments, people will flip his bozo bit pretty quickly. /F -- http://mail.python.org/mailman/listinfo/python-list
Not fully OO ?
Excerpt quoted from http://www.astro.ufl.edu/~warner/prog/python.html : About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
This is wrong. Python _is_ a full OOP language. Everything form modules, functions to basic data types are an object. --JamesMills On Sat, Sep 20, 2008 at 7:23 PM, candide [EMAIL PROTECTED] wrote: Excerpt quoted from http://www.astro.ufl.edu/~warner/prog/python.html : About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. -- http://mail.python.org/mailman/listinfo/python-list -- -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On 20 Sep., 11:23, candide [EMAIL PROTECTED] wrote: Excerpt quoted fromhttp://www.astro.ufl.edu/~warner/prog/python.html: About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. This is somewhat true. But what is OO, really? Answer: if you want to define an entity it has to be defined inside a class. If you want to access an entity you have to use the dot operator. Therefore Java is OO but Python is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Kay Schluehr wrote: Answer: if you want to define an entity it has to be defined inside a class. If you want to access an entity you have to use the dot operator. Therefore Java is OO but Python is not. you're satirising the quoted author's cargo-cultish view of object orientation, right? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 20, 2:23 am, candide [EMAIL PROTECTED] wrote: Excerpt quoted fromhttp://www.astro.ufl.edu/~warner/prog/python.html: About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. Python is what it is, whatever you call it. That page has a whole list of features (we'll give the author the benefit of the doubt and assume they're accurate and fairly up-to-date). Those features (more or less) define what Python is, not trendy computer science catch words. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
candide wrote: Excerpt quoted from http://www.astro.ufl.edu/~warner/prog/python.html : About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. foreach: for x in array: statements Loops over the array given by array. On each iteration, the value of the current element is assigned to x and the internal array pointer is advanced by one. This could be a useful addition to Python. numarray is no longer supported. It has been supplanted by numpy. How is OOP defined? Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Colin J. Williams wrote: foreach: for x in array: statements Loops over the array given by array. On each iteration, the value of the current element is assigned to x and the internal array pointer is advanced by one. This could be a useful addition to Python. for-in could be a useful addition to Python? looks like Guido's used his time machine again, then, since it's been around since the pre-1.0 days: http://www.python.org/doc/ref/for.html /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
for-in could be a useful addition to Python? looks like Guido's used his time machine again, then, since it's been around since the pre-1.0 days: http://www.python.org/doc/ref/for.html He somehow must have misinterpreted http://www.astro.ufl.edu/~warner/prog/python.html which has the exact text he quoted. Unfortunately, this text has foreach in bold, so he might have assumed foreach to be a keyword (despite the example to the right demonstrating the contrary). What this has to do with OO, or with numpy, is beyond me. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
candide [EMAIL PROTECTED] wrote: Excerpt quoted from http://www.astro.ufl.edu/~warner/prog/python.html : About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. General comments about the page: Section 2: Poor demonstration of 'global'. The declaration of 'a' as global is unnecessary and misleading. Section 4: Maths: Requires import math The supplied examples won't work if you just import math, they need a from math import ... (either * or better an explicit list of functions). Worse, the random number examples won't work whatever you import as they include both 'random.seed()' which assumes 'random' is the module and 'x = random()' which requires 'from random import random'. Section 5: Strings do not expand escape sequences unless it is defined as a raw string by placing an r before the first quote What is that supposed to mean? Describing triple quoted strings as 'optional syntax' is a bit weird too: the syntax is no more optional than any other form of string literal, you can use it or not. Another pointless example given under the heading 'String Operators': Concatenation is done with the + operator. Converting to numbers is done with the casting operations: x = 1 + float(10.5) String functions actually mostly describes string methods with len hidden in the middle but only the example tells you that it is different than the other examples. Section 6 is all about numarray but bizarrely (for something purporting to be an overview of Python) there is nothing at all about either list or dict types. Section 7 says There is no switch or case statement so multiple elifs must be used instead. omitting to mention other possibly more appropriate options such as dicts or inheritance. This is a good indication that the author doesn't know much about OOP. Section 8 for x in array: statements shows that the author doesn't understand things like iterators. Section 10 has such interesting facts as Only constant initializers for class variables are allowed (n = 1) or Objects can be compared using the == and != operators. Two objects are equal only if they are the same instance of the same object. and an example with a completely spurious class attributes, some pointless getter/setter methods, and contorted calls to base class methods. Section 11 demonstrates again that the author doesn't understand about iterable objects. I'd say the claim that Python isn't a full OOP language is not the most important reason to ignore the page. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sat, 20 Sep 2008 13:13:08 +, Duncan Booth wrote: This is a good indication that the author doesn't know much about OOP. I think you can drop the last two words :) Actually that's unfair -- it looks like he knows quite a bit about the metallicity of quasers, but he's just parroting a bunch of Java concepts as if Java was the be-all and end-all of object oriented programming, which is clearly wrong because we all know that Python's object model is the One True OOP. *wink* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On 20 Sep., 12:14, Fredrik Lundh [EMAIL PROTECTED] wrote: Kay Schluehr wrote: Answer: if you want to define an entity it has to be defined inside a class. If you want to access an entity you have to use the dot operator. Therefore Java is OO but Python is not. you're satirising the quoted author's cargo-cultish view of object orientation, right? /F I wonder if the OO fetish hasn't already lost much of its magic powers. What are the most powerful fetishes these days? A year ago I would have suspected purely functional but I'm not sure it has really caught on. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sat, Sep 20, 2008 at 11:26 AM, Kay Schluehr [EMAIL PROTECTED] wrote: On 20 Sep., 12:14, Fredrik Lundh [EMAIL PROTECTED] wrote: Kay Schluehr wrote: Answer: if you want to define an entity it has to be defined inside a class. If you want to access an entity you have to use the dot operator. Therefore Java is OO but Python is not. you're satirising the quoted author's cargo-cultish view of object orientation, right? /F I wonder if the OO fetish hasn't already lost much of its magic powers. What are the most powerful fetishes these days? A year ago I would have suspected purely functional but I'm not sure it has really caught on. I think the current fetish is paralelism and erlang's share-nothing concurrency model. Or something like it. -- http://mail.python.org/mailman/listinfo/python-list -- Eduardo de Oliveira Padoan http://djangopeople.net/edcrypt/ http://stopforwarding.us/etiq.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 20, 5:23 am, candide [EMAIL PROTECTED] wrote: Excerpt quoted fromhttp://www.astro.ufl.edu/~warner/prog/python.html: About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. My comment is Who cares? I was always under the impression that if any language truly was OO it would be smalltalk. And I don't derive any benefit from smalltalk at all. I do however derive substantial benefit from other languages that OO zealots would likely poo poo on including python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Fredrik Lundh wrote: Colin J. Williams wrote: foreach: for x in array: statements Loops over the array given by array. On each iteration, the value of the current element is assigned to x and the internal array pointer is advanced by one. This could be a useful addition to Python. for-in could be a useful addition to Python? looks like Guido's used his time machine again, then, since it's been around since the pre-1.0 days: http://www.python.org/doc/ref/for.html /F Thanks. for_stmt ::= for target_list in expression_list : suite [else : suite] Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 20, 5:14 am, Fredrik Lundh [EMAIL PROTECTED] wrote: Kay Schluehr wrote: Answer: if you want to define an entity it has to be defined inside a class. If you want to access an entity you have to use the dot operator. Therefore Java is OO but Python is not. you're satirising the quoted author's cargo-cultish view of object orientation, right? /F If you define OO as implementation inheritance, then Java is not. It inherits interface only. Another possibility is, has a virtual function table. The fact that Python indexes by name doesn't disqualify it from that definition. I don't know if Java meets it. I don't think raw C structures would be included, and you can define function pointers in them. Wikipedia puts it decently: mainly for OO programming, but with some procedural elements. ducks -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On 20 Sep, 19:42, Aaron \Castironpi\ Brady [EMAIL PROTECTED] wrote: Wikipedia puts it decently: mainly for OO programming, but with some procedural elements. ducks When it comes to Python and object-oriented programming, you can't leave out the ducks. ;-) Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
candide a écrit : Excerpt quoted from http://www.astro.ufl.edu/~warner/prog/python.html : About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. The following definitions are AFAIK the only commonly accepted definitions about OO: 1/ an object is defined by identity, state and behaviour 2/ objects interacts by sending messages each other 3/ an OO program is made of interacting objects I let you find out whether Python meets these 3 definitions - and if Java does (hint : in Python, everything you can bind to a name is an object - this is not true in Java or C++). -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On 20 Sep., 18:33, Bruno Desthuilliers [EMAIL PROTECTED] wrote: The following definitions are AFAIK the only commonly accepted definitions about OO: 1/ an object is defined by identity, state and behaviour 2/ objects interacts by sending messages each other 3/ an OO program is made of interacting objects I let you find out whether Python meets these 3 definitions - and if Java does (hint : in Python, everything you can bind to a name is an object - this is not true in Java or C++). This is correct but it detracts from a more general problem of language paradigms. Assume you type 2+2 4 Now you are free to interpret this as a simple, primitive arithmetic operation but you can also claim that 2 sends an __add__ message to 2. Hereby the state of the 2 objects are not altered but a new 4 object is created. OO babble is more impressive isn't it? Actually it is simply wrong in the mentioned case and here is the proof: def foo(): return 2+2 import dis dis.dis(foo) 2 0 LOAD_CONST 2 (4) 3 RETURN_VALUE OO is a heuristic method used to understand the semantics of a programming language. It can also inspire language design but as you've rightly said: jugde yourself and see how far you get with it. Applying OO on interpreter level is by no means a sign of a high quality implementation whereas structuring programs in the large will likely benefit from class based organization and encapsulation. Of course one can also reverse the value hierarchy and find perverse joy in having a pure OO language but apply monkey patching everywhere. I suppose you know which language I'm talking about... -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 20, 3:22 pm, Kay Schluehr [EMAIL PROTECTED] wrote: On 20 Sep., 18:33, Bruno Desthuilliers [EMAIL PROTECTED] wrote: The following definitions are AFAIK the only commonly accepted definitions about OO: 1/ an object is defined by identity, state and behaviour 2/ objects interacts by sending messages each other 3/ an OO program is made of interacting objects I let you find out whether Python meets these 3 definitions - and if Java does (hint : in Python, everything you can bind to a name is an object - this is not true in Java or C++). This is correct but it detracts from a more general problem of language paradigms. Assume you type 2+2 4 Now you are free to interpret this as a simple, primitive arithmetic operation but you can also claim that 2 sends an __add__ message to 2. Hereby the state of the 2 objects are not altered but a new 4 object is created. OO babble is more impressive isn't it? Actually it is simply wrong in the mentioned case and here is the proof: def foo(): return 2+2 import dis dis.dis(foo) 2 0 LOAD_CONST 2 (4) 3 RETURN_VALUE OO is a heuristic method used to understand the semantics of a programming language. It can also inspire language design but as you've rightly said: jugde yourself and see how far you get with it. Applying OO on interpreter level is by no means a sign of a high quality implementation whereas structuring programs in the large will likely benefit from class based organization and encapsulation. Of course one can also reverse the value hierarchy and find perverse joy in having a pure OO language but apply monkey patching everywhere. I suppose you know which language I'm talking about... It sounds like you think that you -can- write OO programs in Python, but you don't have to. I agree. -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
Kay Schluehr wrote: Actually it is simply wrong in the mentioned case and here is the proof: def foo(): return 2+2 import dis dis.dis(foo) 2 0 LOAD_CONST 2 (4) 3 RETURN_VALUE OO is a heuristic method used to understand the semantics of a programming language. It can also inspire language design but as you've rightly said: jugde yourself and see how far you get with it. It's not wrong. You have found a simple optimization. Lot's of compilers for lots of languages optimize code by code folding. Python's peephole optimizer replaces code like 2+2 with 4. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On Sep 20, 8:06 pm, Christian Heimes [EMAIL PROTECTED] wrote: Kay Schluehr wrote: Actually it is simply wrong in the mentioned case and here is the proof: def foo(): return 2+2 import dis dis.dis(foo) 2 0 LOAD_CONST 2 (4) 3 RETURN_VALUE OO is a heuristic method used to understand the semantics of a programming language. It can also inspire language design but as you've rightly said: jugde yourself and see how far you get with it. It's not wrong. The meaning of the Python program is, internally, on a cycle-by-cycle basis, Object 2; send add( Object 2 ) to Object 2; Return object 4. CPython doesn't do this, but due to the fact that there are no cases in which that distinction affects the output, it's still an implementation of Python. Or at least, a practical implementation. You have found a simple optimization. Lot's of compilers for lots of languages optimize code by code folding. Python's peephole optimizer replaces code like 2+2 with 4. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
In article [EMAIL PROTECTED], Thomas G. Willis [EMAIL PROTECTED] wrote: On Sep 20, 5:23=A0am, candide [EMAIL PROTECTED] wrote: Excerpt quoted fromhttp://www.astro.ufl.edu/~warner/prog/python.html: About Python: Python is a high level scripting language with object oriented features. (...) Python supports OOP and classes to an extent, but is not a full OOP language. Thanks for any comment. My comment is Who cares? I was always under the impression that if any language truly was OO it would be smalltalk. And I don't derive any benefit from smalltalk at all. I do however derive substantial benefit from other languages that OO zealots would likely poo poo on including python. ...some experts might say a C++ program is not object-oriented without inheritance and virtual functions. As one of the early Smalltalk implementors myself, I can say they are full of themselves. --zconcept -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Argue for your limitations, and sure enough they're yours. --Richard Bach -- http://mail.python.org/mailman/listinfo/python-list
Re: Not fully OO ?
On 20 Sep., 23:07, Aaron \Castironpi\ Brady [EMAIL PROTECTED] wrote: On Sep 20, 3:22 pm, Kay Schluehr [EMAIL PROTECTED] wrote: On 20 Sep., 18:33, Bruno Desthuilliers [EMAIL PROTECTED] wrote: The following definitions are AFAIK the only commonly accepted definitions about OO: 1/ an object is defined by identity, state and behaviour 2/ objects interacts by sending messages each other 3/ an OO program is made of interacting objects I let you find out whether Python meets these 3 definitions - and if Java does (hint : in Python, everything you can bind to a name is an object - this is not true in Java or C++). This is correct but it detracts from a more general problem of language paradigms. Assume you type 2+2 4 Now you are free to interpret this as a simple, primitive arithmetic operation but you can also claim that 2 sends an __add__ message to 2. Hereby the state of the 2 objects are not altered but a new 4 object is created. OO babble is more impressive isn't it? Actually it is simply wrong in the mentioned case and here is the proof: def foo(): return 2+2 import dis dis.dis(foo) 2 0 LOAD_CONST 2 (4) 3 RETURN_VALUE OO is a heuristic method used to understand the semantics of a programming language. It can also inspire language design but as you've rightly said: jugde yourself and see how far you get with it. Applying OO on interpreter level is by no means a sign of a high quality implementation whereas structuring programs in the large will likely benefit from class based organization and encapsulation. Of course one can also reverse the value hierarchy and find perverse joy in having a pure OO language but apply monkey patching everywhere. I suppose you know which language I'm talking about... It sounds like you think that you -can- write OO programs in Python, but you don't have to. I agree. The whole point of OO is providing high level ( system level ) not low level ( interpreter level ) semantics. Partitioning a system into isolated and communicating objects is a strong and important metaphor. Recently there were some comments on the web that mentioned Erlang to be pretty much OO in this respect although Erlang is functional and has no base level notion of an object. It's even well known that Joe Armstrong holds low opinions about the entire object business. Notice that I believe that the popular meme that OO is bolted on Python has little if nothing to do with OO itself but with API consistency. When people have to type len(x) instead of x.len() this breaks their expectations on how the language has to behave. -- http://mail.python.org/mailman/listinfo/python-list
