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