Python 3K or Python 2.9?
zzbbaadd at aol.com
Mon Sep 17 20:29:17 CEST 2007
On Sep 17, 4:02 am, Steve Holden <st... at holdenweb.com> 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".
More information about the Python-list