Re: Python 3K or Python 2.9?
TheFlyingDutchman wrote: I am not talking about the way it does it, but rather, the way it could do it or... could have done it. That requires no knowledge of how the interpreter currently does it unless I am proposing something that no interpreter in the world could ever do. Yes, there are a couple of things that could have been changed. But from what I can tell there are a number of reasons why things where chosen to be the way they are. Two of those reasons is to make the core C code smaller and easier to maintain and also to make it easier to understand how things work. Exposing the inner workings as visible python code vs hidden C code helps both of those. Another benefit of exposing more of the class machinery of Pythons objects as python code, is it makes it possible to modify more of how things work directly with python code. A good way to see how this works is studying how descriptors and properties work. http://users.rcn.com/python/download/Descriptor.htm You will find there is much more of python written in python than it may first seem. In some cases the built in classes and modules are written in C, yet they still work as if they are written in Python. So if you can find a way to do things like removing self in python in such a way that it doesn't require adding more to the Core interpreter, then it might be considered. What I've found is as my skills improve, I take more advantage of being able to modify and/or introspect how things work. This allows more choices on how I might solve a particular problem. I also think there a lots of improvements that could be made to other parts of python such as the libraries that would be of much more practical benefit. Regards, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Ron Adam a écrit : TheFlyingDutchman wrote: I am not talking about the way it does it, but rather, the way it could do it or... could have done it. That requires no knowledge of how the interpreter currently does it unless I am proposing something that no interpreter in the world could ever do. (snip) So if you can find a way to do things like removing self in python in such a way that it doesn't require adding more to the Core interpreter, then it might be considered. By who ? As far as I'm concerned, I don't want 'self' to be removed, and I'm probably not the only one here. What I've found is as my skills improve, I take more advantage of being able to modify and/or introspect how things work. This allows more choices on how I might solve a particular problem. The changes required by removing self would make most of this either painfull or near impossible AFAICT. I also think there a lots of improvements that could be made to other parts of python such as the libraries that would be of much more practical benefit. indeed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bruno Desthuilliers wrote: Ron Adam a écrit : TheFlyingDutchman wrote: I am not talking about the way it does it, but rather, the way it could do it or... could have done it. That requires no knowledge of how the interpreter currently does it unless I am proposing something that no interpreter in the world could ever do. (snip) So if you can find a way to do things like removing self in python in such a way that it doesn't require adding more to the Core interpreter, then it might be considered. By who ? As far as I'm concerned, I don't want 'self' to be removed, and I'm probably not the only one here. The term might be considered in this case is a very very small possibility. It would need to be a very good solution which has some very nice benifits over the current way. As you say below, it's probably not possible. This was more of a challenge to get anyone who thinks it's worth doing to learn more about how python works rather than just propose arbitrary ideas. What I've found is as my skills improve, I take more advantage of being able to modify and/or introspect how things work. This allows more choices on how I might solve a particular problem. The changes required by removing self would make most of this either painfull or near impossible AFAICT. Right, It would have a cascade effect in many places. I also think there a lots of improvements that could be made to other parts of python such as the libraries that would be of much more practical benefit. indeed. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)
In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: Aahz a écrit : In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Aahz wrote: In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? What exactly is a pseudo, pray tell? Sorry : a pseudonym (a nickname). You apparently missed the thrust of my sarcasm. You can't tell what is or is not a pseudonym online. For all I know, Bruno Desthulliers is a pseudonym. While I recognize that there is some social advantage to linking consistent identifiers with people, I have I think understandable irritation with people who insist that names follow certain patterns. (For those joining only recently, my full legal name is Aahz, which I changed from my former name precisely because of attitudes like Bruno's.) For the record, I usually don't give a damn about what name/nickname/whatever peoples use. Then why mention pseudonyms at all? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The best way to get information on Usenet is not to ask a question, but to post the wrong information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)
Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: (snip) (For those joining only recently, my full legal name is Aahz, which I changed from my former name precisely because of attitudes like Bruno's.) For the record, I usually don't give a damn about what name/nickname/whatever peoples use. Then why mention pseudonyms at all? My fault - I'm sometimes a bit overreactive, and Mr TheFlyingDutchman, (aka zzbbaadd) was starting to get on my nerves. I know I shouldn't have post this one, and I apologize. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? What exactly is a pseudo, pray tell? Sorry : a pseudonym (a nickname). -- http://mail.python.org/mailman/listinfo/python-list
Using pseudonyms (was Re: Python 3K or Python 2.9?)
In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? What exactly is a pseudo, pray tell? Sorry : a pseudonym (a nickname). You apparently missed the thrust of my sarcasm. You can't tell what is or is not a pseudonym online. For all I know, Bruno Desthulliers is a pseudonym. While I recognize that there is some social advantage to linking consistent identifiers with people, I have I think understandable irritation with people who insist that names follow certain patterns. (For those joining only recently, my full legal name is Aahz, which I changed from my former name precisely because of attitudes like Bruno's.) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The best way to get information on Usenet is not to ask a question, but to post the wrong information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)
Aahz wrote: In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? What exactly is a pseudo, pray tell? Sorry : a pseudonym (a nickname). You apparently missed the thrust of my sarcasm. You can't tell what is or is not a pseudonym online. For all I know, Bruno Desthulliers is a pseudonym. While I recognize that there is some social advantage to linking consistent identifiers with people, I have I think understandable irritation with people who insist that names follow certain patterns. (For those joining only recently, my full legal name is Aahz, which I changed from my former name precisely because of attitudes like Bruno's.) ... coupled with a certain bloody-mindedness that forces you to rub people's noses in your ability to choose to do so? ;-) regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Sorry, the dog ate my .sigline -- http://mail.python.org/mailman/listinfo/python-list
Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)
In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Aahz wrote: In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? What exactly is a pseudo, pray tell? Sorry : a pseudonym (a nickname). You apparently missed the thrust of my sarcasm. You can't tell what is or is not a pseudonym online. For all I know, Bruno Desthulliers is a pseudonym. While I recognize that there is some social advantage to linking consistent identifiers with people, I have I think understandable irritation with people who insist that names follow certain patterns. (For those joining only recently, my full legal name is Aahz, which I changed from my former name precisely because of attitudes like Bruno's.) ... coupled with a certain bloody-mindedness that forces you to rub people's noses in your ability to choose to do so? ;-) While there's certainly some truth to that, it is also the case that I have seen people like Bruno take exception to some people's born names. After all, there are people whose parents chose to name them Moon Unit. For that matter, there are plenty of people who are better known by some nickname that is not their legal name. And even before I changed my name, I had plenty of problems from people believing that my name was a nickname and helpfully fixing it. (Which is really where my attitude comes from, and the practical difficulties of having only one legal name are not that much larger than my former difficulties.) Overall, I think that Bruno's attitude is more injurious to community than letting people be known by whatever name they choose. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The best way to get information on Usenet is not to ask a question, but to post the wrong information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)
Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? What exactly is a pseudo, pray tell? Sorry : a pseudonym (a nickname). You apparently missed the thrust of my sarcasm. Obviously, yes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using pseudonyms (was Re: Python 3K or Python 2.9?)
Aahz a écrit : In article [EMAIL PROTECTED], Steve Holden [EMAIL PROTECTED] wrote: Aahz wrote: In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: Aahz a écrit : In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? What exactly is a pseudo, pray tell? Sorry : a pseudonym (a nickname). You apparently missed the thrust of my sarcasm. You can't tell what is or is not a pseudonym online. For all I know, Bruno Desthulliers is a pseudonym. While I recognize that there is some social advantage to linking consistent identifiers with people, I have I think understandable irritation with people who insist that names follow certain patterns. (For those joining only recently, my full legal name is Aahz, which I changed from my former name precisely because of attitudes like Bruno's.) For the record, I usually don't give a damn about what name/nickname/whatever peoples use. ... coupled with a certain bloody-mindedness that forces you to rub people's noses in your ability to choose to do so? ;-) While there's certainly some truth to that, it is also the case that I have seen people like Bruno take exception to some people's born names. After all, there are people whose parents chose to name them Moon Unit. But then adding the lastname (ie 'Zappa') could clear the possible confusion !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Ironic Hi, I'm new to Python, I don't even fully know the language, never done a full project in Python. What's more, probably I'll never will. But that's not the point, the point is I want YOU people to modify the language you know in and out, the program with which you've done many systems, I want you to change it to suit my whims, so that I'll be comfortable with the 3 ten liners I'll write. TIA /Ironic Zobionic Hi, I've used Python and have fallen in love with it. I know exactly how Guido pronounces his name and since I saw him use the obtuse phrase syntactic sugar I try and work it into every discussion I have on Python syntax. I hate it when anyone offers criticism of Guido's language. I have a picture of Bruce Eckel with a red universal not sign over it on my wall and I throw my mechanical pencils at it every night. I am especially upset when someone talks bad about kluges like @staticmethod or FunctionName = staticmethod(FunctionName). Sure def static or static def would be so much cleaner, simpler and clearer but let's face it my fellow Pythonistas, this language may have started out based on what was easy for people to learn and use but we're in Nerdville now and clean and clear have become roadblocks! I have so much more respect for Perl and the way it developed now! /Zombionic -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
The other half of the confusion is cleared up by considering that Python methods are ordinary functions that don't magically know in which class context they are executing: they must be told via the first parameter. They can be told all they want by the compiler/runtime - implicitly - under-the-covers, out-of-sight. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman a écrit : Ironic Hi, I'm new to Python, I don't even fully know the language, never done a full project in Python. What's more, probably I'll never will. But that's not the point, the point is I want YOU people to modify the language you know in and out, the program with which you've done many systems, I want you to change it to suit my whims, so that I'll be comfortable with the 3 ten liners I'll write. TIA /Ironic Zobionic Hi, I've used Python and have fallen in love with it. I know exactly how Guido pronounces his name and since I saw him use the obtuse phrase syntactic sugar I try and work it into every discussion I have on Python syntax. I hate it when anyone offers criticism of Guido's language. I have a picture of Bruce Eckel with a red universal not sign over it on my wall and I throw my mechanical pencils at it every night. I am especially upset when someone talks bad about kluges like @staticmethod or FunctionName = staticmethod(FunctionName). Sure def static or static def would be so much cleaner, simpler and clearer but let's face it my fellow Pythonistas, this language may have started out based on what was easy for people to learn and use but we're in Nerdville now and clean and clear have become roadblocks! I have so much more respect for Perl and the way it developed now! /Zombionic AolStrikesBack Hi, I'm totally unable to understand the difference between higher order functions and language statements, nor why the first approach is way better than the second. I'm totally clueless about Python's object model despite many posts explaining it and pointing to relevant documentation. And, ho, yes, I don't even understand the expression syntactic sugar, but I guess it must some dummy concept invented by the guy that wrote Python whatever his name might be. So I insist on posting that all this is a kludge and that Python should be how I think it could be instead of trying to understand why it is the way it is and why people actually using it like the way it is. But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? /AolStrikesBack -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
VivaLaFrance If you wanna know why the Renault Dauphine requires the driver to pull down on the rearview mirror in order to shift into reverse you simply need to open the hood and remove the engine and disassemble the transmission and you will see that it has no way of distinguishing a shift into third from a shift into reverse without a rearview mirror pull. But these days most people just open the glove compartment when shifting into reverse which works just as well! /VivaLaFrance -- http://mail.python.org/mailman/listinfo/python-list
RE: Python 3K or Python 2.9?
Ben Finney wrote: The latter two statements are equivalent. The 'instance.method(args)' syntax is just sugar for 'Class.method(instance, args)'. Only in the case that instance is an instance of Class, and not an instance of a subclass of Class. For example, the following are not equivalent: class A(object): def func(self): print 'A' class B(A): def func(self): super(B, self).func() print 'B' a = A() b = B() A.func(a) A.func(b) B.func(b) a.func() b.func() Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman a écrit : VivaLaFrance If you wanna know why the Renault Dauphine requires the driver to pull down on the rearview mirror in order to shift into reverse you simply need to open the hood and remove the engine and disassemble the transmission and you will see that it has no way of distinguishing a shift into third from a shift into reverse without a rearview mirror pull. But these days most people just open the glove compartment when shifting into reverse which works just as well! /VivaLaFrance Very interesting engineering problem. But a bit out of date and totally unrelated to Python. Anything else ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman wrote: The other half of the confusion is cleared up by considering that Python methods are ordinary functions that don't magically know in which class context they are executing: they must be told via the first parameter. They can be told all they want by the compiler/runtime - implicitly - under-the-covers, out-of-sight. I wish you would keep these deep insightful comments to yourself. Your knowledge of the interpreter internals appears to be based on examination by crystal ball. You conveniently ignore the fact that the situation described by David Trudgett (and, by the way, your quoting with no attributions is also becoming tiresome very quickly) is a *design choice*, not a mistake. It's done precisely to make an explicit reference to the instance available to methods. You also conveniently ignore the fact that changing tis would also change other aspects of the language, such as the ability to graft functions into instances and classes as methods. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Sorry, the dog ate my .sigline -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On 9/13/07, Stefan Bellon [EMAIL PROTECTED] wrote: On Thu, 13 Sep, TheFlyingDutchman wrote: Bruce said that no other mainstream OO language is explicitly passing the object as a parameter to class methods. Ada 95 does. And Ada 95 was the first standardized OO language. Now that's debatable :) SIMULA 67 was formally standardized on the first meeting of the SIMULA Standards Group (SSG) in February 1968. http://en.wikipedia.org/wiki/Simula -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Graham Dumpleton wrote: ... In that blog, Guido says: Concurrency: It seems we're now happily out exploring here. I'm looking forward to benchmarks showing that PP or similar (or dissimilar!) solutions actually provide a performance gain. Another route I'd like to see explored is integrating one such solution into an existing web framework (or perhaps as WSGI middleware) so that web applications have an easy way out without redesigning their architecture. ... Well I have been trying out a system very like PP. For various reasons I prefer to write my own scheduler based on more traditional code, but it's very easy to get SSH based workers going. Agreed it's a noddy system, but I find the following timings for the pp callback demo with start=1, end=2. All the workers are similar to a pp local worker, but some are controlled via ssh and hence have to be initialised by an argument like -cexec input() which downloads some bootstrap code; I find that an easy way to utilize a server which already has ssh. The local workers are clearly dominant, but even though app1,app3,app4 are not in the same country they can still be used to provide useful work. I suspect most people won't want to use either ssh or socket based workers when 64 cpu machines arrive. The worker farm topology is also a bit wrong for massively parallel stuff. Starting scheduler with 1 workers(1 local) Partial sum is 0.69314718306 | diff = -2.50006693125e-009 Job execution statistics: job count | % of all jobs | job time sum | time per job | worker 128 |100.00 | 59.7190 | 0.466555 | local:3676 128 |100.00 | 59.7190 | 0.466555 | all local 128 |100.00 | 59.7190 | 0.466555 | total Time elapsed since scheduler creation 59.782648 Real average time 0.467046875507 Starting scheduler with 2 workers(2 local) Partial sum is 0.69314718306 | diff = -2.50006693125e-009 Job execution statistics: job count | % of all jobs | job time sum | time per job | worker 64 | 50.00 | 31.5300 | 0.492656 | local:324 64 | 50.00 | 31.2190 | 0.487797 | local:3684 128 |100.00 | 62.7490 | 0.490227 | all local 128 |100.00 | 62.7490 | 0.490227 | total Time elapsed since scheduler creation 31.546038 Real average time 0.24645312503 Starting scheduler with 3 workers(2 local) Partial sum is 0.69314718306 | diff = -2.50006704228e-009 Job execution statistics: job count | % of all jobs | job time sum | time per job | worker 53 | 41.41 | 25.6580 | 0.484113 | local:2392 52 | 40.63 | 25.5150 | 0.490673 | local:416 23 | 17.97 | 24.2500 | 1.054348 | ssh:RLUK_robin:20457 105 | 82.03 | 51.1730 | 0.487362 | all local 128 |100.00 | 75.4230 | 0.589242 | total Time elapsed since scheduler creation 25.7349998951 Real average time 0.20105468668 Starting scheduler with 4 workers(2 local) Partial sum is 0.69314718306 | diff = -2.50006704228e-009 Job execution statistics: job count | % of all jobs | job time sum | time per job | worker 46 | 35.94 | 22.2200 | 0.483043 | local:2328 46 | 35.94 | 22.4670 | 0.488413 | local:3580 21 | 16.41 | 22.3150 | 1.062619 | ssh:RLUK_robin:20500 15 | 11.72 | 21.9730 | 1.464867 | ssh:app1:3549 92 | 71.88 | 44.6870 | 0.485728 | all local 128 |100.00 | 88.9750 | 0.695117 | total Time elapsed since scheduler creation 23.032648 Real average time 0.179937500507 Starting scheduler with 5 workers(2 local) Partial sum is 0.69314718306 | diff = -2.50006704228e-009 Job execution statistics: job count | % of all jobs | job time sum | time per job | worker 40 | 31.25 | 19.3600 | 0.484000 | local:1376 41 | 32.03 | 19.7030 | 0.480561 | local:3608 18 | 14.06 | 19.1090 | 1.061611 | ssh:RLUK_robin:20524 14 | 10.94 | 19.1110 | 1.365071 | ssh:app1:3596 15 | 11.72 | 19.0950 | 1.273000 | ssh:app3:44316 81 | 63.28 | 39.0630 | 0.482259 | all local 128 |100.00 | 96.3780 | 0.752953 | total Time elapsed since server creation 19.9850001335 Real average time 0.156132813543 Starting scheduler with 7 workers(2 local) Partial sum is 0.69314718306 | diff = -2.50006693125e-009 Job execution statistics: job count | % of all jobs | job time sum | time per job | worker 31 | 24.22 | 14.9540 | 0.482387 | local:2588 31 | 24.22 | 15.0630 | 0.485903 | local:472 13 | 10.16 |
Re: Python 3K or Python 2.9?
On Sep 17, 4:02 am, Steve Holden [EMAIL PROTECTED] wrote: TheFlyingDutchman wrote: The other half of the confusion is cleared up by considering that Python methods are ordinary functions that don't magically know in which class context they are executing: they must be told via the first parameter. They can be told all they want by the compiler/runtime - implicitly - under-the-covers, out-of-sight. I wish you would keep these deep insightful comments to yourself. Your knowledge of the interpreter internals appears to be based on examination by crystal ball. I am not talking about the way it does it, but rather, the way it could do it or... could have done it. That requires no knowledge of how the interpreter currently does it unless I am proposing something that no interpreter in the world could ever do. You conveniently ignore the fact that the situation described by David Trudgett (and, by the way, your quoting with no attributions is also becoming tiresome very quickly) is a *design choice*, not a mistake. It's done precisely to make an explicit reference to the instance available to methods. For your own information, supercilious references to the interpreter internals become tiresome quickly. I made a complaint about a small design choice. I also made it in the past tense at least once (should have done it) and explicitly expressed that I knew it wasn't going to happen. Python was created based on a language that was designed to make it easy to use by beginners. Doing so made it a clean and clear language. My preference is for everything to be as clean and clear as possible. If I didn't I'd never have bothered with Python since Perl is much more popular among programmers I have come across. Jury-rigging new features is going to make the elite happy but very likely will be viewed differently by us average programmers. change other aspects of the language, such as the ability to graft functions into instances and classes as methods. Those are elite-type features that make code harder to understand by average programmers and probably the elite as well. To paraphrase someone He thought he'd solve the problem by grafting functions into classes and grafting classes into methods. Then he had two problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman a écrit : On Sep 17, 4:02 am, Steve Holden [EMAIL PROTECTED] wrote: (snip) I made a complaint about a small design choice. It's by no mean a small design choice. I also made it in the past tense at least once (should have done it) and explicitly expressed that I knew it wasn't going to happen. Python was created based on a language that was designed to make it easy to use by beginners. Most beginners still find Python easy to use AFAICT. At least, I know a lot of *non* programmers using it. Doing so made it a clean and clear language. My preference is for everything to be as clean and clear as possible. Mine too, and that's why I like Python the way it is : syntactic sugar for the common cases, *and* and easy way to play with lower levels when necessary. (snip) Jury-rigging new features is going to make the elite happy but very likely will be viewed differently by us average programmers. us ? Who is us ? change other aspects of the language, such as the ability to graft functions into instances and classes as methods. Those are elite-type features that make code harder to understand by average programmers and probably the elite as well. Good news, there's a language designed exactly for average programmers that find these kind of features - as well as anything as complex as operator overloading, metaclasses, descriptors, higher order functions, multiple inheritance, lazy evaluation, and anything dynamic - way too elite. It's named Java. The only drawback is that instead of elite features, you'll have to resort to mumbo-jumbo overcomplexified design patterns and write ten times more code to solve the simplest things. To make a long story short: if you don't understand some advanced Python's features, then just don't use them. But have mercy and let us elite programmers (lol...) use more of Python's power. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
In article [EMAIL PROTECTED], Bruno Desthuilliers [EMAIL PROTECTED] wrote: But what, given that I'm an AOL user still thinking it's kewl to hide behind a pseudo, what else would you expect ? What exactly is a pseudo, pray tell? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The best way to get information on Usenet is not to ask a question, but to post the wrong information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
John Roth a écrit : On Sep 12, 11:35 am, TheFlyingDutchman [EMAIL PROTECTED] wrote: On Sep 12, 4:40 am, Bjoern Schliessmann [EMAIL PROTECTED] wrote: Ivan Voras wrote: What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. If this was needless, why do C++ and Java have the this pointer? this in C++ and Java is not shown in the parameter list, which was what he was complaining about. He wants class MyClass: def SomeFunction(someParameter): self.someParameter = someParameter not class MyClass: def SomeFunction(self, someParameter): self.someParameter = someParameter The confusing way about the current Python method when you first encounter it is why is self being passed in when you write the function but not when you call it. If the compiler is smart enough to know that a = MyClass() a.SomeFunction(12) SomeFunction() has a self implicitly added to the parameter list, it seems that it should be smart enough to know that a function defined in a class has a self implicitly added to the parameter list. Pretty close. This is one of the things that's always puzzled me about the discussion. Making self and cls keyword pseudo-constants that get the current instance and class from the stack frame (or raise an exception) would eliminate them from the method header. I suppose that by header, you mean prototype or signature. But anyway, it's not a *method* signature, it's a *function* signature - and the compiler persists to have nothing to do with all this... It would ALSO eliminate a whole level of indirection in method invocation and get rid of the instancemethod, classmethod and staticmethod wrapper classes. This would be a significant simplification. If it had been done earlier, it would have eliminated most of the justification for method attributes (those silly @ things), those silly @ things has *nothing* to do with methods nor with attributes. It's just syntactic sugar for HOFs. Period. thus showing that unneeded complexity breeds more unneeded complexity. John, there are plenty of other OOPls around that don't requires neither explicit use of the instance/class reference nor mention of it in the function . If after having read this whole thread and all relevant documentation, you still don't understand why Python works that way and why most of us are *totally* happy with the way it works, I strongly suggest that you switch to another language. Not that I have nothing personal against you, but it should be quite clear that this part of Python is not going to change - FWIW, as Alex pointed out, I doubt even GvR could impose such a change now. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Erik Jones a écrit : On Sep 14, 2007, at 11:54 PM, David Trudgett wrote: TheFlyingDutchman [EMAIL PROTECTED] writes: (snip) Several languages use the object.method(args) form, which is syntactic sugar for method(object, other_args) which Ada, for instance, uses. Knowing this clears up half the confusion (the object /is/ passed as a parameter whichever syntax is used). The other half of the confusion is cleared up by considering that Python methods are ordinary functions that don't magically know in which class context they are executing: they must be told via the first parameter. Yes, that is really the crux of the issue, though. While the former may be syntactic sugar for the latter, once any syntactic sugar has become prevalent enough, it becomes the expected norm Being the expected norm is not enough to qualify has being the right thing to do. and the latter becomes clutter or, at best, awkward. Until you want to dynamically add some generic function taking an object as first arg as a method of a class or instance. Exposing most of the inner working of it's object model is one of the greatest strength of Python. And that's one of the reasons I (and probably other people here) like this language. It's something that really just takes a little use until you get to the point where you don't usually think of it but, every so often, the thought creeps in. I'm not complaining, just pointing out if you step out of this particular box, you'll realize that it really is a pointless one. Saying, because that's how Python does it may be the only valid reason, but that argument is about on par with a six year old's just because If you really think the only rationale for this is just because, then you're missing something IMHO. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Sep 14, 2007, at 11:54 PM, David Trudgett wrote: TheFlyingDutchman [EMAIL PROTECTED] writes: The confusing way about the current Python method when you first encounter it is why is self being passed in when you write the function but not when you call it. If the compiler is smart enough to know that a = MyClass() a.SomeFunction(12) SomeFunction() has a self implicitly added to the parameter list, it seems that it should be smart enough to know that a function defined in a class has a self implicitly added to the parameter list. Several languages use the object.method(args) form, which is syntactic sugar for method(object, other_args) which Ada, for instance, uses. Knowing this clears up half the confusion (the object /is/ passed as a parameter whichever syntax is used). The other half of the confusion is cleared up by considering that Python methods are ordinary functions that don't magically know in which class context they are executing: they must be told via the first parameter. Yes, that is really the crux of the issue, though. While the former may be syntactic sugar for the latter, once any syntactic sugar has become prevalent enough, it becomes the expected norm and the latter becomes clutter or, at best, awkward. It's something that really just takes a little use until you get to the point where you don't usually think of it but, every so often, the thought creeps in. I'm not complaining, just pointing out if you step out of this particular box, you'll realize that it really is a pointless one. Saying, because that's how Python does it may be the only valid reason, but that argument is about on par with a six year old's just because Erik Jones Software Developer | Emma® [EMAIL PROTECTED] 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate market in style. Visit us online at http://www.myemma.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bjoern Schliessmann [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | - only functions being attributes of a class... |What, IYHO, is the difference between a method and a function? A method is a function accessed as an attribute of a class or instance. As an object type, it is a *runtime* function wrapper. | (ok, I know, you meant functions declared within a class statement). | I think that those functions _are_ special ones Thinking does not make things so. |since the compiler is able to make method(instance, a, b) out of |instance.method(a, b). No it does not. The method wrapping is done at runtine. The compiler is ignorant of the wrapping that will be done. class C: def meth(self): pass c = C() import dis def f(): return c.meth() dis.dis(f) 1 0 LOAD_GLOBAL 0 (c) 3 LOAD_ATTR1 (meth) 6 CALL_FUNCTION0 9 RETURN_VALUE The function gets wrapped as a bound method as part of LOAD_ATTR. When the compiler sees expr(args), it does not know and does not care about the particular type that expr will become. It just assumes that it will be callable and emits the code to call it. Consider def g(): return C() dis.dis(g) 1 0 LOAD_GLOBAL 0 (C) 3 CALL_FUNCTION0 6 RETURN_VALUE It does not notice and does not care that 'C' will be bound to a class. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bjoern Schliessmann a écrit : Bruno Desthuilliers wrote: Bjoern Schliessmann a écrit : Why don't you make a preprocessor which accepts method declarations without self and fixes them? The problem being that there's no such thing as a method declaration in Python Yep, there are only definitions. I'm sorry. - only functions being attributes of a class... What, IYHO, is the difference between a method and a function? A method is a thin wrapper around a function, usually instanciated and returned by the __get__ method [1] of the function itself when the function is looked up as an attribute of a class or an instance: class Foo(object): ... def meth(self): ... print in %s meth % self ... Foo.__dict__['meth'] function meth at 0xb7d76374 Foo.meth unbound method Foo.meth Foo().meth bound method Foo.meth of __main__.Foo object at 0xb7d7acac [1] you may want to read about the descriptor protocol which is the base mechanism on which methods and properties (computed attributes) are based. (ok, I know, you meant functions declared within a class statement). I think that those functions _are_ special ones They aren't, and you should perhaps read the manual - all this is documented. since the compiler is able to make method(instance, a, b) out of instance.method(a, b). Once again, the compiler has *nothing* to do with this. Else, how could you do this: def fun(obj): ... print obj ... Foo.fun = fun Foo.fun unbound method Foo.fun Foo().fun bound method Foo.fun of __main__.Foo object at 0xb7d7ad6c fun function fun at 0xb7d763ac Foo.__dict__['fun'] function fun at 0xb7d763ac So IMHO, method definition makes sense. It doesn't. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bruno Desthuilliers wrote: A method is a thin wrapper around a function, usually instanciated and returned by the __get__ method [1] of the function itself when the function is looked up as an attribute of a class or an instance: [...] That's interesting, thank you for the explanation. They aren't, and you should perhaps read the manual - all this is documented. Found it. :) Regards, Björn -- BOFH excuse #144: Too few computrons available. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Terry Reedy wrote: No it does not. The method wrapping is done at runtine. The compiler is ignorant of the wrapping that will be done. Agreed, after reading the docs. dis.dis(f) 1 0 LOAD_GLOBAL 0 (c) 3 LOAD_ATTR1 (meth) 6 CALL_FUNCTION0 9 RETURN_VALUE The function gets wrapped as a bound method as part of LOAD_ATTR. When the compiler sees expr(args), it does not know and does not care about the particular type that expr will become. It just assumes that it will be callable and emits the code to call it. Consider That's interesting. BTW, do you know something (apart from the dis docs) that's worth reading if you're interested in Python byte code? Regards, Björn -- BOFH excuse #138: BNC (brain not connected) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Piet van Oostrum [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] (BF) wrote: BF The latter two statements are equivalent. The 'instance.method(args)' BF syntax is just sugar for 'Class.method(instance, args)'. It is more than just syntactic sugar because the Class is derived from the instance at runtime. Other differences that mean it isn't just sugar: you can save the bound method created by 'instance.method' but not with the expanded version. The equivalence depends on the type of 'method', other expansions are possible: e.g. Class.method(Class, args) or Class.method(args) or invent your own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bjoern Schliessmann [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That's interesting. BTW, do you know something (apart from the dis docs) that's worth reading if you're interested in Python byte code? -- That is the only Python specific thing I remember reading. Of course, it helps that I learned assembler a long time ago, and that I have used an HP reverse-polish notation calculator (a fixed-size stack machine), and that I have seen and understand algorithms for turning prefix and infix to postfix notation. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Sep 12, 11:35 am, TheFlyingDutchman [EMAIL PROTECTED] wrote: On Sep 12, 4:40 am, Bjoern Schliessmann [EMAIL PROTECTED] wrote: Ivan Voras wrote: What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. If this was needless, why do C++ and Java have the this pointer? this in C++ and Java is not shown in the parameter list, which was what he was complaining about. He wants class MyClass: def SomeFunction(someParameter): self.someParameter = someParameter not class MyClass: def SomeFunction(self, someParameter): self.someParameter = someParameter The confusing way about the current Python method when you first encounter it is why is self being passed in when you write the function but not when you call it. If the compiler is smart enough to know that a = MyClass() a.SomeFunction(12) SomeFunction() has a self implicitly added to the parameter list, it seems that it should be smart enough to know that a function defined in a class has a self implicitly added to the parameter list. Pretty close. This is one of the things that's always puzzled me about the discussion. Making self and cls keyword pseudo-constants that get the current instance and class from the stack frame (or raise an exception) would eliminate them from the method header. It would ALSO eliminate a whole level of indirection in method invocation and get rid of the instancemethod, classmethod and staticmethod wrapper classes. This would be a significant simplification. If it had been done earlier, it would have eliminated most of the justification for method attributes (those silly @ things), thus showing that unneeded complexity breeds more unneeded complexity. John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Sep 12, 1:35 pm, TheFlyingDutchman [EMAIL PROTECTED] wrote: On Sep 12, 4:40 am, Bjoern Schliessmann [EMAIL PROTECTED] wrote: Ivan Voras wrote: What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. If this was needless, why do C++ and Java have the this pointer? this in C++ and Java is not shown in the parameter list, which was what he was complaining about. He wants class MyClass: def SomeFunction(someParameter): self.someParameter = someParameter not class MyClass: def SomeFunction(self, someParameter): self.someParameter = someParameter If one *really* wants this, it is doable in python too: http://www.voidspace.org.uk/python/weblog/arch_d7_2006_12_16.shtml#e583 George -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bruno Desthuilliers wrote: TheFlyingDutchman a écrit : Well I'm with Bruce Eckel - there shouldn't be any argument for the object in the class method parameter list. def fun(obj, *args, **kw): # generic code here that do something with obj import some_module some_module.SomeClass.fun = fun This is why uniformity is important. But anyway, I think it's quite clear that Python won't drop the explicit self, so it looks like you have to live with it or choose another language. Bruce said that no other mainstream OO language is explicitly passing the object as a parameter to class methods. to methods. class methods gets the class as first parameter. Anyway, there are a lot of things that Python doesn't do like other mainstream OO languages, and that's a GoodThing. What I would like to have seen added to class definitions was the forced declaration of all object variables in the class outside of methods. I don't like the fact that they have to be, and can be created in any method on the fly. I definitively think you'd be happier with some other language. Ironic Hi, I'm new to Python, I don't even fully know the language, never done a full project in Python. What's more, probably I'll never will. But that's not the point, the point is I want YOU people to modify the language you know in and out, the program with which you've done many systems, I want you to change it to suit my whims, so that I'll be comfortable with the 3 ten liners I'll write. TIA /Ironic -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman [EMAIL PROTECTED] writes: The confusing way about the current Python method when you first encounter it is why is self being passed in when you write the function but not when you call it. If the compiler is smart enough to know that a = MyClass() a.SomeFunction(12) SomeFunction() has a self implicitly added to the parameter list, it seems that it should be smart enough to know that a function defined in a class has a self implicitly added to the parameter list. Several languages use the object.method(args) form, which is syntactic sugar for method(object, other_args) which Ada, for instance, uses. Knowing this clears up half the confusion (the object /is/ passed as a parameter whichever syntax is used). The other half of the confusion is cleared up by considering that Python methods are ordinary functions that don't magically know in which class context they are executing: they must be told via the first parameter. David Trudgett -- These are not the droids you are looking for. Move along. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman a écrit : On Sep 12, 4:40 am, Bjoern Schliessmann usenet- [EMAIL PROTECTED] wrote: Ivan Voras wrote: What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. If this was needless, why do C++ and Java have the this pointer? this in C++ and Java is not shown in the parameter list, which was what he was complaining about. He wants class MyClass: def SomeFunction(someParameter): self.someParameter = someParameter not class MyClass: def SomeFunction(self, someParameter): self.someParameter = someParameter The confusing way about the current Python method when you first encounter it is why is self being passed in when you write the function At this stage, it's not passed in, it's declared in the arguments list. but not when you call it. It *is* passed when you call the function. If the compiler is smart enough to know that The compiler has absolutely nothing to do with it. It's the object model that takes care of this. Quick explanation: - functions objects implement the descriptor protocol. - when a function which is an attribute of a class is looked up on an instance of that class, the __get__ method of the function object is called with the instance (and class) as arguments. - this method returns a closure wrapping the instance, the class and the function object itself - when this closure is called, it itself prepends the instance to the args it receives, calls the function with these args, and returns the result. This is why you need tho declare the instance as the first argument, but don't need to pass it explicitely *when calling the function as a method of an object*. Notice that you can still use the function directly, passing the instance by yourself. And that you can define a function outside a class and then attach it to a class. To make a long story short, Python's methods are just thin temporary wrappers around plain functions. a = MyClass() a.SomeFunction(12) SomeFunction() has a self implicitly added to the parameter list, it seems that it should be smart enough to know that a function defined in a class has a self implicitly added to the parameter list. The compiler has nothing to do with it, and where you define the function is totally orthogonal: def truc(obj): print obj class Toto(object): pass Toto.trac = truc t = Toto() t.trac() -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman a écrit : Foo.bar(foo, spam) foo.bar(spam) That looks like a case of There's more than one way to do it. ;) Nope, on the contrary. The nice thing with this model is that you don't have distinct rules for functions and methods, since methods are just plain functions. The latter two statements are equivalent. The 'instance.method(args)' syntax is just sugar for 'Class.method(instance, args)'. I think I saw where Guido Van Rossum had referred to something as syntactic sugar in some python.org page. I am not familiar with sugar as related to syntax. Is it being used as a synonym for easier way of doing it? Yes. syntactic sugar mostly means nicer, simpler syntax for something that could be done without. And one of the *great* strength of Python is that it exposes both the syntactic sugar for the most common uses case and the underlying implementation for most advanced tricks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman [EMAIL PROTECTED] (T) wrote: T The confusing way about the current Python method when you first T encounter it is T why is self being passed in when you write the function but not T when you call it. It *is* passed when you call it, but it is written before the method name instead of after it. Some people have called this an infix call similar to infix operators. -- Piet van Oostrum [EMAIL PROTECTED] URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Ben Finney [EMAIL PROTECTED] (BF) wrote: BF The latter two statements are equivalent. The 'instance.method(args)' BF syntax is just sugar for 'Class.method(instance, args)'. It is more than just syntactic sugar because the Class is derived from the instance at runtime. -- Piet van Oostrum [EMAIL PROTECTED] URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman wrote: I am not talking about how the implementation of a C++ or Java compiler uses the this pointer/this reference internally. I am talking about how an author describes in English the this pointer/reference in their book on programming C++ or Java. Ah, okay. I don't think you will find them saying that under the covers this was passed to the method (if in fact it is). They just say that it refers to the current object inside that object's method. Mh, in my book, there is (quickly translated from german): | Instance pointer (C++ only) | | The /this/ pointer is a feature of all non-static class methods. | Every non static method is extended internally by a /this/ | argument. To that argument the compiler passes a pointer to the | instance for which the method is being called. (Dirk Louis, C/C++-Kompendium, MarktTechnik-Verlag, 2000) And that's only from the pointer chapter. The OOP chapters are more detailed. And no, it's no book about compiler architecture, it's a compendium. Here is a link to a tutorial where Sun is talking about the this reference: http://java.sun.com/docs/books/tutorial/java/javaOO/thiskey.html That's a tutorial for getting you started, no reference documentation or in-depth course. I am referring to C++. If someone is trying to learn the language, knowledge of the internal implemenation is counter-productive in my opinion because it distracts from the details they need to learn. In a language like C++ it is beneficial to know some inner workings -- in the same way like it's beneficial to know some inner workings of a computer if you want to use it. BTW, C is not for nothing called portable assembler :) If they are experienced and want to learn about the internals to potentially help them code in the most blazingingly fast manner they ideally would just be reminded they are using C++ and not some slower byte-code executed language where it could possibly matter. ;) I don't know if it's just me, but I tend to understand stuff like virtual methods much better if I know *why* they exist, and not just *that* they do. That makes judging if and when I need them easier. Regards, Björn -- BOFH excuse #192: runaway cat on system. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman [EMAIL PROTECTED] wrote:
Foo.bar(foo, spam)
foo.bar(spam)
That looks like a case of There's more than one way to do it. ;)
The first form is definitely consistent with the
method declaration, so there's a lot to be said for using that style
when teaching people to make classes - send self, receive self.
On the other hand, the second form is not polymorphic: it doesn't allow
for foo to be an instance of some OTHER class (possibly subclassing Foo
and overriding bar) -- it will call the Foo version of bar anyway.
type(foo).bar(foo, spam) *IS* almost semantically equivalent to the
obviousy simpler foo.bar(spam) -- but doesn't cover the possibility
for foo to do a *per-instance* override of 'bar'.
getattr(foo, 'bar', functools.partial(type(foo).bar, foo))(spam) is
getting closer to full semantic equivalence. And if you think that's
another OBVIOUS way of doing it wrt foo.bar(spam), I think your
definition of obvious may need a reset (not to mention the fact that
the equivalent version is way slower;-).
Foo.bar(foo, spam)'s different semantics are important when any
implementation of type(foo).bar (or other method yet) wants to BYPASS
polymorphism to redirect part of the functionality to a specific type's
implementation of bar ('super' may help in some cases, but it keeps some
polymorphic aspects and pretty often you just want to cut all
polymorphism off and just redirect to ONE specific implementation).
Alex
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Well I'm with Bruce Eckel - there shouldn't be any argument for the object in the class method parameter list. But since Python 3 was code-named 3000 (implying but not delivering big changes... I don't think it required big changes) and since it still has an explicit object parameter it's a given that it's not gonna happen in any revisions. Bruce said that no other mainstream OO language is explicitly passing the object as a parameter to class methods. But Perl does it as well. I think the label mainstream OO language is as valid being applied to Perl as it is to Python. What I would like to have seen added to class definitions was the forced declaration of all object variables in the class outside of methods. I don't like the fact that they have to be, and can be created in any method on the fly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Here is a link to a tutorial where Sun is talking about the this reference: http://java.sun.com/docs/books/tutorial/java/javaOO/thiskey.html That's a tutorial for getting you started, no reference documentation or in-depth course. Here's a FAQ item where they refer to it as I think Python should have done it - a special predefined variable: http://www.faqs.org/docs/javap/c5/s5.html Java provides a special, predefined variable named this that you can use for such purposes. The variable, this, is used in the source code of an instance method to refer to the object that contains the method. This intent of the name, this, is to refer to this object, the one right here that this very method is in. If x is an instance variable in the same object, then this.x can be used as a full name for that variable. If otherMethod() is an instance method in the same object, then this.otherMethod() could be used to call that method. Whenever the computer executes an instance method, it automatically sets the variable, this, to refer to the object that contains the method. this is hard to query on but I would be interested in seeing some site talking about Java where this is mentioned as being passed in. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman wrote: What I would like to have seen added to class definitions was the forced declaration of all object variables in the class outside of methods. I don't like the fact that they have to be, and can be created in any method on the fly. Isn't one of the main ideas behind python that it doesn't force you to do (well, declare) anything? And by ideas I mean design decisions. Thats exactly what makes python great for prototyping; you just do it and see if it works. As soon as you need to declare things you have to change stuff in at least 2 places for every change of heart you have. (Can you tell I'm currently forced to developing in Java? ;) (Which I'm currently avoiding to do, by wasting my time on usenet.)) /W -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Isn't one of the main ideas behind python that it doesn't force you to do (well, declare) anything? And by ideas I mean design decisions. Thats exactly what makes python great for prototyping; you just do it and see if it works. As soon as you need to declare things you have to change stuff in at least 2 places for every change of heart you have. (Can you tell I'm currently forced to developing in Java? ;) (Which I'm currently avoiding to do, by wasting my time on usenet.)) But if you are looking at code you didn't write, it's nice to be able to see all the member variables that a class has listed separate from method code. I think static typing helps in trying to deduce what code is doing, particularly when you are looking at function definitions. You don't have to work to find out what type of variables it takes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Thu, 13 Sep, TheFlyingDutchman wrote: Bruce said that no other mainstream OO language is explicitly passing the object as a parameter to class methods. Ada 95 does. And Ada 95 was the first standardized OO language. Now with Ada 2005 you can either pass the the object explicitly as first parameter (like in Ada 95) or you can call the method on the object (like in Java, C++, Python, ...) and the object is passed implicitly. -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Thu, 13 Sep 2007 10:10:57 -0700, TheFlyingDutchman wrote: Isn't one of the main ideas behind python that it doesn't force you to do (well, declare) anything? And by ideas I mean design decisions. Thats exactly what makes python great for prototyping; you just do it and see if it works. As soon as you need to declare things you have to change stuff in at least 2 places for every change of heart you have. (Can you tell I'm currently forced to developing in Java? ;) (Which I'm currently avoiding to do, by wasting my time on usenet.)) But if you are looking at code you didn't write, it's nice to be able to see all the member variables that a class has listed separate from method code. That information is usually in the `__init__()` method and the class docstring. I think static typing helps in trying to deduce what code is doing, particularly when you are looking at function definitions. You don't have to work to find out what type of variables it takes. This should either be obvious or in the docstring. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman a écrit : Well I'm with Bruce Eckel - there shouldn't be any argument for the object in the class method parameter list. def fun(obj, *args, **kw): # generic code here that do something with obj import some_module some_module.SomeClass.fun = fun This is why uniformity is important. But anyway, I think it's quite clear that Python won't drop the explicit self, so it looks like you have to live with it or choose another language. Bruce said that no other mainstream OO language is explicitly passing the object as a parameter to class methods. to methods. class methods gets the class as first parameter. Anyway, there are a lot of things that Python doesn't do like other mainstream OO languages, and that's a GoodThing. What I would like to have seen added to class definitions was the forced declaration of all object variables in the class outside of methods. I don't like the fact that they have to be, and can be created in any method on the fly. I definitively think you'd be happier with some other language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
(Can you tell I'm currently forced to developing in Java? ;) (Which I'm currently avoiding to do, by wasting my time on usenet.)) Maybe you can sneak Jython into the mix. Just describe it as this Java scripting language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman wrote: Here's a FAQ item where they refer to it as I think Python should have done it - a special predefined variable: Maybe. Personally, I like it the way it is in Python. Why don't you make a preprocessor which accepts method declarations without self and fixes them? Regards, Björn -- BOFH excuse #135: You put the disk in upside down. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman wrote: (Can you tell I'm currently forced to developing in Java? ;) (Which I'm currently avoiding to do, by wasting my time on usenet.)) Maybe you can sneak Jython into the mix. Just describe it as this Java scripting language. Hehe, devious idea. I might just try that. :) /W -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bjoern Schliessmann a écrit : TheFlyingDutchman wrote: Here's a FAQ item where they refer to it as I think Python should have done it - a special predefined variable: Maybe. Personally, I like it the way it is in Python. Why don't you make a preprocessor which accepts method declarations without self and fixes them? The problem being that there's no such thing as a method declaration in Python - only functions being attributes of a class... (ok, I know, you meant functions declared within a class statement). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Here's a FAQ item where they refer to it as I think Python should have | done it - a special predefined variable: | | http://www.faqs.org/docs/javap/c5/s5.html | | Java provides a special, predefined variable named this that you | can use for such purposes. The variable, this, is used in the source | code of an instance method to refer to the object that contains the | method. This intent of the name, this, is to refer to this object, | the one right here that this very method is in. If x is an instance | variable in the same object, then this.x can be used as a full name | for that variable. If otherMethod() is an instance method in the same | object, then this.otherMethod() could be used to call that method. | Whenever the computer executes an instance method, it automatically | sets the variable, this, to refer to the object that contains the | method. In Python, methods are (functions) contained in (are attributes of) classes. Hence, by the above, 'this' or 'self' would be set to the class and not the instance. So the above would require some rewording for Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bruno Desthuilliers wrote: Bjoern Schliessmann a écrit : Why don't you make a preprocessor which accepts method declarations without self and fixes them? The problem being that there's no such thing as a method declaration in Python Yep, there are only definitions. I'm sorry. - only functions being attributes of a class... What, IYHO, is the difference between a method and a function? (ok, I know, you meant functions declared within a class statement). I think that those functions _are_ special ones since the compiler is able to make method(instance, a, b) out of instance.method(a, b). So IMHO, method definition makes sense. Regards, Björn -- BOFH excuse #144: Too few computrons available. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Thu, 13 Sep 2007 20:59:06 +0200, Bjoern Schliessmann wrote: TheFlyingDutchman wrote: Here's a FAQ item where they refer to it as I think Python should have done it - a special predefined variable: Maybe. Personally, I like it the way it is in Python. Why don't you make a preprocessor which accepts method declarations without self and fixes them? If you look at the thread parameter list notation from ten days or so ago, TheFlyingDutchman has forked Python and is working on a very special new language, PIEthun 3.01B. I for one am looking forward to seeing all the very special features of PIEthun. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
In article [EMAIL PROTECTED], Ben Finney [EMAIL PROTECTED] wrote: Specifically an easier way of doing it provided by the language syntax (hence syntactic sugar). As in, the form 'foo += 1' is syntactic sugar for 'foo = foo + 1'. Except, of course, that it isn't, quite. ;-) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Many customs in this life persist because they ease friction and promote productivity as a result of universal agreement, and whether they are precisely the optimal choices is much less important. --Henry Spencer http://www.lysator.liu.se/c/ten-commandments.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
In article [EMAIL PROTECTED], Alex Martelli [EMAIL PROTECTED] wrote: Chris Mellon [EMAIL PROTECTED] wrote: and I'll punch a kitten before I accept having to read Python code guessing if something is a global, a local, or part of self like I do in C++. Exactly: the technical objections that are being raised are bogus, and the REAL objections from the Python community boil down to: we like it better the way it is now. Bringing technical objections that are easily debunked doesn't _strengthen_ our real case: in fact, it _weakens_ it. So, I'd rather see discussants focus on how things SHOULD be, rather than argue they must stay that way because of technical difficulties that do not really apply. The real advantage of making 'self' explicit is that it IS explicit, and we like it that way, just as much as its critics detest it. Just like, say, significant indentation, it's a deep part of Python's culture, tradition, preferences, and mindset, and neither is going to go away (I suspect, in fact, that, even if Guido somehow suddenly changed his mind, these are issues on which even he couldn't impose a change at this point without causing a fork in the community). Making up weak technical objections (ones that ignore the possibilities of __get__ or focus on something so absolutely central to everyday programming practice as inspect.getargspec [!!!], for example;-) is just not the right way to communicate this state of affairs. While you have a point, I do think that there is no solution that allows the following code to work with no marker distinguishing the local bar from the instance's bar; the only question is how you want to mark up your code: class C: def foo(self, bar): print bar, self.bar x = C() x.bar = 'abc' x.foo() From that standpoint, there is a technical objection involved. Of course, the solution can be any of a number of different marker systems (or even choosing to have no marker and not permit a method to access both object attributes and locals of the same name), and Python has chosen to force the use of a marker for all object attributes, while also choosing to have disjoint namespaces WRT globals and locals for any one name. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Many customs in this life persist because they ease friction and promote productivity as a result of universal agreement, and whether they are precisely the optimal choices is much less important. --Henry Spencer http://www.lysator.liu.se/c/ten-commandments.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
If you look at the thread parameter list notation from ten days or so ago, TheFlyingDutchman has forked Python and is working on a very special new language, PIEthun 3.01B. I for one am looking forward to seeing all the very special features of PIEthun. It will be named PIEthun 3000 as it comes out of Beta. But you're not alone. From the emails I have been receiving there is anticipation and excitement from Mumbai to Dusseldorf to Caracas. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman a écrit : Python user and advocate Bruce Eckel is disappointed with the additions (or lack of additions) in Python 3: http://www.artima.com/weblogs/viewpost.jsp?thread=214112 I'd say Mr Eckel fails to graps some of the great points about Python's object model - the rant about the use of 'self' is a sure clue. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bruno Desthuilliers wrote: TheFlyingDutchman a écrit : Python user and advocate Bruce Eckel is disappointed with the additions (or lack of additions) in Python 3: http://www.artima.com/weblogs/viewpost.jsp?thread=214112 I'd say Mr Eckel fails to graps some of the great points about Python's object model - the rant about the use of 'self' is a sure clue. What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Ivan Voras wrote: What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. If this was needless, why do C++ and Java have the this pointer? Regards, Björn -- BOFH excuse #390: Increased sunspot activity. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Bjoern Schliessmann wrote: What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. If this was needless, why do C++ and Java have the this pointer? Be careful when you use the word needless in the context of Java. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Ivan Voras [EMAIL PROTECTED] wrote: I'd say Mr Eckel fails to graps some of the great points about Python's object model - the rant about the use of 'self' is a sure clue. What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. You could add some syntax to Python such that '.x' was equivalent to 'first argument of current function.x' (either completely implicitly or with some surrounding block that lets you specify the assumed variable. That wouldn't break anything in the syntax but the general feeling of the Python community is that such a change would be undesirable as it is better to write the variable name out explicitly. As for omitting 'self' from method definitions, at first site you might think the compiler could just decide that any 'def' directly inside a class could silently insert 'self' as an additional argument. This doesn't work though because not everything defined in a class has to be an instance method: static methods don't have a self parameter at all, class methods traditionally use 'cls' instead of 'self' as the name of the first parameter and it is also possible to define a function inside a class block and use it as a function. e.g. class Weird: def factory(arg): Returns a function based on its argument foo = factory(foo) bar = factory(bar) del factory When factory is called, it is a simple function not a method. If it had gained an extra parameter then either you would have to explicitly pass it an instance of a not yet defined class when calling it, or the compiler would have to somehow know that it had been defined with the extra parameter and add it. Basically it all boils down to having a consistent set of rules. Ruby has one set of rules, but Python has a different set. Python's rules mean you can interchange functions and methods more easily [at a cost of having to write self out explicitly/with the advantage that you can easily see references to self](delete as preferred). There is no difference between: class C: def method(self): pass and def foo(self): pass class C: pass C.method = foo both of these result in effectively the same class (although the second one has a different name for the method in tracebacks). That consistency really is important. Whenever I see a 'def' I know exactly what parameters the resulting function will take regardless of the context. Another area to consider is what happens when I do: foo = FooClass() foo.bar(x) # versus f = foo.bar f(x) Both of these work in exactly the same way in Python: the self parameter is bound to the method when you access 'foo.bar', not when you make the call. That isn't the case in some other scripting languages. e.g. in Javascript the first one would call bar with the magic 'this' parameter set to foo, but in the second case it calls bar with 'this' set to the global object. My point here is that in Python the magic is clearly defined and overridable (so we can have static or class methods that act differently). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Duncan Booth [EMAIL PROTECTED] wrote: ... As for omitting 'self' from method definitions, at first site you might think the compiler could just decide that any 'def' directly inside a class could silently insert 'self' as an additional argument. This doesn't work though because not everything defined in a class has to be an instance method: static methods don't have a self parameter at all, class methods traditionally use 'cls' instead of 'self' as the name of the first parameter and it is also possible to define a function inside a class block and use it as a function. e.g. Actually you could do the magic first-parameter insertion just when returning a bound or unbound method object in the function's __get__ special method, and that would cover all of the technical issues you raise. E.g.: class Weird: def factory(arg): Returns a function based on its argument foo = factory(foo) bar = factory(bar) del factory When factory is called, it is a simple function not a method. If it had Sure, that's because the function object itself is called, not a bound or unbound method object -- indeed. factory.__get__ never gets called here. class C: def method(self): pass and def foo(self): pass class C: pass C.method = foo both of these result in effectively the same class (although the second one has a different name for the method in tracebacks). And exactly the same would occur if the self argument was omitted from the signature and magically inserted when __get__ does its job. That consistency really is important. Whenever I see a 'def' I know exactly what parameters the resulting function will take regardless of the context. And this non-strictly-technical issue is the only true one. Another area to consider is what happens when I do: foo = FooClass() foo.bar(x) # versus f = foo.bar f(x) Both of these work in exactly the same way in Python: the self parameter And so they would with the __get__ does magic rule, NP. My point here is that in Python the magic is clearly defined and overridable (so we can have static or class methods that act differently). And so it would be with that rule, since staticmethod c create different descriptor objects. Really, the one and only true issue is that the Python community doesn't like magic. It would be perfectly feasible, we just don't wanna:-). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On 9/12/07, Alex Martelli [EMAIL PROTECTED] wrote: Duncan Booth [EMAIL PROTECTED] wrote: ... As for omitting 'self' from method definitions, at first site you might think the compiler could just decide that any 'def' directly inside a class could silently insert 'self' as an additional argument. This doesn't work though because not everything defined in a class has to be an instance method: static methods don't have a self parameter at all, class methods traditionally use 'cls' instead of 'self' as the name of the first parameter and it is also possible to define a function inside a class block and use it as a function. e.g. Actually you could do the magic first-parameter insertion just when returning a bound or unbound method object in the function's __get__ special method, and that would cover all of the technical issues you raise. E.g.: class Weird: def factory(arg): Returns a function based on its argument foo = factory(foo) bar = factory(bar) del factory When factory is called, it is a simple function not a method. If it had Sure, that's because the function object itself is called, not a bound or unbound method object -- indeed. factory.__get__ never gets called here. class C: def method(self): pass and def foo(self): pass class C: pass C.method = foo both of these result in effectively the same class (although the second one has a different name for the method in tracebacks). And exactly the same would occur if the self argument was omitted from the signature and magically inserted when __get__ does its job. This would mean that mixing functions and methods would have to be done like you do it in C++, with lots of careful knowledge and inspection of what you're working with. What would happen to stuff like inspect.getargspec? Besides, if self isn't in the argument spec, you know that the very next thing people will complain about is that it's not implicitly used for locals, and I'll punch a kitten before I accept having to read Python code guessing if something is a global, a local, or part of self like I do in C++. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Chris Mellon [EMAIL PROTECTED] wrote: ... Actually you could do the magic first-parameter insertion just when returning a bound or unbound method object in the function's __get__ special method, and that would cover all of the technical issues you ... This would mean that mixing functions and methods would have to be done like you do it in C++, with lots of careful knowledge and inspection of what you're working with. Not particularly -- it would not require anything special that's not required today. What would happen to stuff like inspect.getargspec? It would return the signature of the function, if asked to analyze a function, and the signature of the method, if asked to analyze a method. Not exactly rocket science, as it happens. Besides, if self isn't in the argument spec, you know that the very next thing people will complain about is that it's not implicitly used for locals, Whether 'self' needs to be explicit as a function's first argument, and whether it needs to be explicit (as a self. ``prefix'') to access instance variables (which is what I guess you mean here by locals, since reading it as written makes zero sense), are of course separate issues. and I'll punch a kitten before I accept having to read Python code guessing if something is a global, a local, or part of self like I do in C++. Exactly: the technical objections that are being raised are bogus, and the REAL objections from the Python community boil down to: we like it better the way it is now. Bringing technical objections that are easily debunked doesn't _strengthen_ our real case: in fact, it _weakens_ it. So, I'd rather see discussants focus on how things SHOULD be, rather than argue they must stay that way because of technical difficulties that do not really apply. The real advantage of making 'self' explicit is that it IS explicit, and we like it that way, just as much as its critics detest it. Just like, say, significant indentation, it's a deep part of Python's culture, tradition, preferences, and mindset, and neither is going to go away (I suspect, in fact, that, even if Guido somehow suddenly changed his mind, these are issues on which even he couldn't impose a change at this point without causing a fork in the community). Making up weak technical objections (ones that ignore the possibilities of __get__ or focus on something so absolutely central to everyday programming practice as inspect.getargspec [!!!], for example;-) is just not the right way to communicate this state of affairs. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Sep 12, 4:40 am, Bjoern Schliessmann usenet- [EMAIL PROTECTED] wrote: Ivan Voras wrote: What does self have to do with an object model? It's an function/method argument that might as well be hidden in the compiler without ever touching the role it has (if not, why?). I agree that it's needless noise in a language. If this was needless, why do C++ and Java have the this pointer? this in C++ and Java is not shown in the parameter list, which was what he was complaining about. He wants class MyClass: def SomeFunction(someParameter): self.someParameter = someParameter not class MyClass: def SomeFunction(self, someParameter): self.someParameter = someParameter The confusing way about the current Python method when you first encounter it is why is self being passed in when you write the function but not when you call it. If the compiler is smart enough to know that a = MyClass() a.SomeFunction(12) SomeFunction() has a self implicitly added to the parameter list, it seems that it should be smart enough to know that a function defined in a class has a self implicitly added to the parameter list. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
this in C++ and Java is not shown in the parameter list, which was what he was complaining about. He wants class MyClass: def SomeFunction(someParameter): self.someParameter = someParameter not class MyClass: def SomeFunction(self, someParameter): self.someParameter = someParameter The confusing way about the current Python method when you first encounter it is why is self being passed in when you write the function but not when you call it. If the compiler is smart enough to know that a = MyClass() a.SomeFunction(12) SomeFunction() has a self implicitly added to the parameter list, it seems that it should be smart enough to know that a function defined in a class has a self implicitly added to the parameter list. In C++ and Java I don't believe this is ever referred to as an implicit function parameter. It is a (sometimes necessary) way to reference the object inside one if it's methods. If it is in fact a real parameter in the underlying compiled-code implementation, that knowledge hurts more than it helps. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman wrote: In C++ and Java I don't believe this is ever referred to as an implicit function parameter. Oh yes, it is. All methods use it as a base address into instances. Implicitly though. It is a (sometimes necessary) way to reference the object inside one if it's methods. Also, I always like to use it explicitly. There's nothing worse than to read others' source and not know if it's a global they access or not. If it is in fact a real parameter in the underlying compiled-code implementation, that knowledge hurts more than it helps. To which language are you referring here, Python or C++? No matter what, I still don't really understand why it hurted. Regards, Björn -- BOFH excuse #296: The hardware bus needs a new token. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Stefan Behnel wrote: Bjoern Schliessmann wrote: If this was needless, why do C++ and Java have the this pointer? Be careful when you use the word needless in the context of Java. Umm, why? I didn't introduce it. Regards, Björn -- BOFH excuse #8: static buildup -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Sep 12, 3:53 pm, Bjoern Schliessmann usenet- [EMAIL PROTECTED] wrote: TheFlyingDutchman wrote: In C++ and Java I don't believe this is ever referred to as an implicit function parameter. Oh yes, it is. All methods use it as a base address into instances. Implicitly though. I am not talking about how the implementation of a C++ or Java compiler uses the this pointer/this reference internally. I am talking about how an author describes in English the this pointer/reference in their book on programming C++ or Java. I don't think you will find them saying that under the covers this was passed to the method (if in fact it is). They just say that it refers to the current object inside that object's method. Here is a link to a tutorial where Sun is talking about the this reference: http://java.sun.com/docs/books/tutorial/java/javaOO/thiskey.html If it is in fact a real parameter in the underlying compiled-code implementation, that knowledge hurts more than it helps. To which language are you referring here, Python or C++? No matter what, I still don't really understand why it hurted. I am referring to C++. If someone is trying to learn the language, knowledge of the internal implemenation is counter-productive in my opinion because it distracts from the details they need to learn. If they are experienced and want to learn about the internals to potentially help them code in the most blazingingly fast manner they ideally would just be reminded they are using C++ and not some slower byte-code executed language where it could possibly matter. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman [EMAIL PROTECTED] writes: I am talking about how an author describes in English the this pointer/reference in their book on programming C++ or Java. I don't think you will find them saying that under the covers this was passed to the method (if in fact it is). They just say that it refers to the current object inside that object's method. In other words, it's magic, and the behaviour has to be explained so the reader knows where the undeclared 'this' comes from. How is that preferable to the magic of instance is passed as the first argument to a method? -- \ If nothing changes, everything will remain the same. -- | `\ Barne's Law | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Sep 12, 5:47 pm, Ben Finney [EMAIL PROTECTED] wrote: TheFlyingDutchman [EMAIL PROTECTED] writes: I am talking about how an author describes in English the this pointer/reference in their book on programming C++ or Java. I don't think you will find them saying that under the covers this was passed to the method (if in fact it is). They just say that it refers to the current object inside that object's method. In other words, it's magic, and the behaviour has to be explained so the reader knows where the undeclared 'this' comes from. I would disagree that it _has_ to be explained where it came from. I think knowing that the compiler is providing it is sufficient. Any further knowledge of what the compiler is doing under the covers to provide it is unnecessary. Sun made no mention of where this comes from in that link I provided. How is that preferable to the magic of instance is passed as the first argument to a method? I would mention that an instance is passed as the first parameter argument of a method if the methods were declared with the extra argument and called with the extra argument: a = MyClass() my_method(a,someParameter) Then it makes sense to me to talk about it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On 9/12/07, Ben Finney [EMAIL PROTECTED] wrote: TheFlyingDutchman [EMAIL PROTECTED] writes: I am talking about how an author describes in English the this pointer/reference in their book on programming C++ or Java. I don't think you will find them saying that under the covers this was passed to the method (if in fact it is). They just say that it refers to the current object inside that object's method. In other words, it's magic, and the behaviour has to be explained so the reader knows where the undeclared 'this' comes from. How is that preferable to the magic of instance is passed as the first argument to a method? So everything that isn't passed explicitly is magic? I suppose __builtin__ counts as magic, too? Define 'self' as a keyword, and its usage becomes no more magical than 'def' or 'break'. -- # p.d. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman [EMAIL PROTECTED] writes: I would mention that an instance is passed as the first parameter argument of a method if the methods were declared with the extra argument and called with the extra argument: a = MyClass() my_method(a,someParameter) Are you unaware that this is the way it works already? class Foo(object): ... def bar(self, baz): ... print baz ... foo = Foo() Foo.bar(spam) Traceback (most recent call last): File stdin, line 1, in ? TypeError: unbound method bar() must be called with Foo instance as first argument (got str instance instead) Foo.bar(foo, spam) spam foo.bar(spam) spam The latter two statements are equivalent. The 'instance.method(args)' syntax is just sugar for 'Class.method(instance, args)'. -- \Choose mnemonic identifiers. If you can't remember what | `\ mnemonic means, you've got a problem. -- Larry Wall | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Peter Decker [EMAIL PROTECTED] writes: On 9/12/07, Ben Finney [EMAIL PROTECTED] wrote: How is that preferable to the magic of instance is passed as the first argument to a method? So everything that isn't passed explicitly is magic? No. Everything that's not explicit is magic, in that it potentially needs to be explained to a newcomer the first time they encounter it. -- \ Pinky, are you pondering what I'm pondering? I think so, | `\Brain, but if the plural of mouse is mice, wouldn't the plural | _o__) of spouse be spice? -- _Pinky and The Brain_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Foo.bar(foo, spam) foo.bar(spam) That looks like a case of There's more than one way to do it. ;) The first form is definitely consistent with the method declaration, so there's a lot to be said for using that style when teaching people to make classes - send self, receive self. The latter two statements are equivalent. The 'instance.method(args)' syntax is just sugar for 'Class.method(instance, args)'. I think I saw where Guido Van Rossum had referred to something as syntactic sugar in some python.org page. I am not familiar with sugar as related to syntax. Is it being used as a synonym for easier way of doing it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Wed, 12 Sep 2007 19:40:04 -0700, TheFlyingDutchman wrote: Foo.bar(foo, spam) foo.bar(spam) That looks like a case of There's more than one way to do it. ;) The first form is definitely consistent with the method declaration, so there's a lot to be said for using that style when teaching people to make classes - send self, receive self. I think it is a horrible thing to teach beginners. Would you teach them to write 1.__add__(1) instead of 1+1? I think that beginners should be taught to write instance.method(arguments) and then only introduced to class.method(instance, arguments) when they progress to needing to know what happens under the hood. The latter two statements are equivalent. The 'instance.method(args)' syntax is just sugar for 'Class.method(instance, args)'. I think I saw where Guido Van Rossum had referred to something as syntactic sugar in some python.org page. I am not familiar with sugar as related to syntax. Is it being used as a synonym for easier way of doing it? Syntactic sugar is not really well defined, it's a fuzzy concept, but in a nutshell it is special syntax made to sweeten the language by giving an easier way to write common tasks. It's hard to find examples of syntactic sugar that everybody agrees are syntactic sugar, but I consider the following to be good (in the sense of useful, obvious and well-thought-out) examples: alist[-1] for alist[len(alist)-1] list comprehensions and generator expressions Perhaps less attractive, but still very(?) useful, examples of syntactic sugar are decorators and the X if C else Y ternary operator. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman [EMAIL PROTECTED] writes: (Please, preserve attribution lines so it's clear who wrote what in your quoted material.) Foo.bar(foo, spam) foo.bar(spam) That looks like a case of There's more than one way to do it. ;) Indeed, but there's only one *obvious* way to do it. (The latter, in this case.) The first form is definitely consistent with the method declaration, so there's a lot to be said for using that style when teaching people to make classes - send self, receive self. Sure, go ahead and teach that way if you like; it'll work fine. I think I saw where Guido Van Rossum had referred to something as syntactic sugar in some python.org page. I am not familiar with sugar as related to syntax. Is it being used as a synonym for easier way of doing it? Specifically an easier way of doing it provided by the language syntax (hence syntactic sugar). As in, the form 'foo += 1' is syntactic sugar for 'foo = foo + 1'. -- \ I don't know half of you half as well as I should like, and I | `\ like less than half of you half as well as you deserve. -- | _o__)Bilbo Baggins | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
TheFlyingDutchman [EMAIL PROTECTED] writes: Python user and advocate Bruce Eckel is disappointed with the additions (or lack of additions) in Python 3: http://www.artima.com/weblogs/viewpost.jsp?thread=214112 That article is pretty weak. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
Paul Rubin http://[EMAIL PROTECTED] writes: TheFlyingDutchman [EMAIL PROTECTED] writes: Python user and advocate Bruce Eckel is disappointed with the additions (or lack of additions) in Python 3: http://www.artima.com/weblogs/viewpost.jsp?thread=214112 That article is pretty weak. It is responded to by Guido here: A Response to Bruce Eckel URL:http://www.artima.com/weblogs/viewpost.jsp?thread=214325 -- \ The trouble with eating Italian food is that five or six days | `\ later you're hungry again. -- George Miller | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3K or Python 2.9?
On Sep 12, 2:14 pm, Ben Finney [EMAIL PROTECTED] wrote: Paul Rubin http://[EMAIL PROTECTED] writes: TheFlyingDutchman [EMAIL PROTECTED] writes: Python user and advocate Bruce Eckel is disappointed with the additions (or lack of additions) in Python 3: http://www.artima.com/weblogs/viewpost.jsp?thread=214112 That article is pretty weak. It is responded to by Guido here: A Response to Bruce Eckel URL:http://www.artima.com/weblogs/viewpost.jsp?thread=214325 In that blog, Guido says: Concurrency: It seems we're now happily out exploring here. I'm looking forward to benchmarks showing that PP or similar (or dissimilar!) solutions actually provide a performance gain. Another route I'd like to see explored is integrating one such solution into an existing web framework (or perhaps as WSGI middleware) so that web applications have an easy way out without redesigning their architecture. Maybe I don't fully understand where Guido is coming from, but solutions for spreading web applications across multiple processes have been available for a long time in solutions such as mod_python and mod_fastcgi. With a view to improving further on these solutions mod_wsgi has also been created. All these solutions either use the multi process nature of the web server, or themselves use multiple daemon processes to which requests are distributed by Apache. End result is that one can make better use of multi processor or multi core machines. Also, when using multi threaded Apache worker MPM, because a lot of stuff is not even done in Python code, such as static file serving, multiple cores can even be used within the same process. Thus, in the larger context of how Apache is implemented and what web applications provide, the GIL isn't as big a problem as some like to believe it is as far as preventing proper utilisation of the machines resources. FWIW, I have blogged my own response to Guido's comment above at: http://blog.dscpl.com.au/2007/09/parallel-python-discussion-and-modwsgi.html Now over the years I have seen a lot of Python developers showing quite a dislike for using Python integrated with Apache. As a result the last thing people seem to want to do is fix such solutions up and make them work better. Reality is though that unless a very good solution for hosting Python with Apache comes up, you will probably never see good cheap commodity web hosting for Python. Older solutions simply aren't safe to use or are hard to set up and manage. Creating lots of distinct Python processes and proxying to them, like the purists would like to see, simply isn't going to happen as such setups are too hard to manage and use up too much resources on a large scale. Web hosting companies want something simple which they can integrate into their existing PHP focused Apache installations and which don't chew up huge amounts of additional resources, thereby forcing a reduction in their site densities. To that end, we still have a way to go. An older blog entry of mine where I have covered these problems is: http://blog.dscpl.com.au/2007/07/commodity-shared-hosting-and-modwsgi.html Graham -- http://mail.python.org/mailman/listinfo/python-list
