You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

94 lines
3.5 KiB

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