95 lines
3.5 KiB
Plaintext
95 lines
3.5 KiB
Plaintext
|
From: tismer at appliedbiometrics.com (Christian Tismer)
|
||
|
Date: Fri, 30 Apr 1999 17:20:07 GMT
|
||
|
Subject: Python IS slow ! [was] Re: Python too slow for real world
|
||
|
References: <613145F79272D211914B0020AFF6401914DAD8@gandalf.digicool.com> <p5g15lmb35.fsf@bidra241.bbn.hp.com> <slrn7ieipq.8uk.wtanksle@dolphin.openprojects.net> <7g9qmo$luf$1@news.udel.edu> <372965CA.2B3FD2FE@appliedbiometrics.com> <19990430080805.B776752@vislab.epa.gov> <3729A9F3.75B2692B@appliedbiometrics.com> <19990430101215.A806665@vislab.epa.gov> <3729CD92.43477316@appliedbiometrics.com> <19990430130807.A812795@vislab.epa.gov>
|
||
|
Message-ID: <3729E647.B38DFE72@appliedbiometrics.com>
|
||
|
Content-Length: 2837
|
||
|
X-UID: 455
|
||
|
|
||
|
|
||
|
Randall Hopper wrote:
|
||
|
|
||
|
[me, trying to give an example of forward references]
|
||
|
|
||
|
> Well, I personally would call this "broken". :-)
|
||
|
> Base class A calling subclass B's method M without declaring a virtual
|
||
|
> method M itself is very perverse IMO.
|
||
|
|
||
|
Then please go and tell this to Jim Fulton (Bobo/Zope)
|
||
|
or look into the XML-sig's parsers.
|
||
|
|
||
|
A mixin class is a mixin, which is not supposed to produce
|
||
|
prototypes for everybody who uses it. This is a different
|
||
|
idea which is implied by multiple inheritance, IMHO.
|
||
|
|
||
|
> If we have:
|
||
|
> class parserops:
|
||
|
> "mixin class"
|
||
|
> def general_method1(self, *args):
|
||
|
> self.parser_method(self.scanner, args)
|
||
|
> def parser_method(self,...)
|
||
|
> """ Pure virtual method """
|
||
|
> pass
|
||
|
> ...
|
||
|
>
|
||
|
> Then there's no problem. self.parse_method will always resolve, possibly
|
||
|
> to a subclass method but at least to this pure virtual stub.
|
||
|
>
|
||
|
> |It will also not resolve self.magic, since it doesn't
|
||
|
> |inherit from abstractparser.
|
||
|
>
|
||
|
> I bet you 5 bucks you know what I'm going to say. :-)
|
||
|
> Accessing attributes of a sibling base class united by a future subclass?
|
||
|
> [Cringe!] Sheesh. I wouldn't want to try to follow _that_ code, much less
|
||
|
> debug it.
|
||
|
|
||
|
We were not talking style or how to do things, but
|
||
|
theory. Existing code would break. Some could be fixed,
|
||
|
some not, all-in-all I don't want to change the language,
|
||
|
but have my (at least:) programs run very fast.
|
||
|
|
||
|
>
|
||
|
> |Yes, but this would limit Python down to Pascal like name spaces.
|
||
|
> |You would need all kinds of tricks to write recoursions like
|
||
|
> |
|
||
|
> |def two(arg):
|
||
|
> | if arg % 2 == 0:
|
||
|
> | return three(arg-1)
|
||
|
> | return arg
|
||
|
> |
|
||
|
> |def three(arg):
|
||
|
> | if arg % 3 == 0:
|
||
|
> | return two(arg-1)
|
||
|
> | return arg
|
||
|
>
|
||
|
> Good point for deferring resolution until the end of the module.
|
||
|
> I'm sold. I'd prefer this to having to use forward declarations.
|
||
|
|
||
|
There'se also a lot more of possible flexibility which
|
||
|
we should keep. Some modules tend to produce code on-the-fly,
|
||
|
invent functions dynamically, whatever.
|
||
|
Also I often see initialization code like
|
||
|
|
||
|
import string
|
||
|
my_split = string.split
|
||
|
del string
|
||
|
|
||
|
and doing some more. During creation (execution) of the module
|
||
|
code, the name space is changing quite much. Some module
|
||
|
are stable afterwards, and they can be completely frozen, but,
|
||
|
of course, this would be about the last line of code.
|
||
|
|
||
|
ciao - chris
|
||
|
|
||
|
--
|
||
|
Christian Tismer :^) <mailto:tismer at appliedbiometrics.com>
|
||
|
Applied Biometrics GmbH : Have a break! Take a ride on Python's
|
||
|
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
|
||
|
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
|
||
|
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
|
||
|
we're tired of banana software - shipped green, ripens at home
|
||
|
|
||
|
|
||
|
|
||
|
|