95 lines
3.3 KiB
Plaintext
95 lines
3.3 KiB
Plaintext
From: aa8vb at vislab.epa.gov (Randall Hopper)
|
|
Date: Fri, 30 Apr 1999 17:08:07 GMT
|
|
Subject: Python IS slow ! [was] Re: Python too slow for real world
|
|
In-Reply-To: <3729CD92.43477316@appliedbiometrics.com>; from Christian Tismer on Fri, Apr 30, 1999 at 05:34:42PM +0200
|
|
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>
|
|
Message-ID: <19990430130807.A812795@vislab.epa.gov>
|
|
Content-Length: 2525
|
|
X-UID: 1565
|
|
|
|
Christian Tismer:
|
|
|[tismer().chris about locking]
|
|
|
|
|
|> A command-line option (-w), or something like Perl's "use strict"
|
|
|> declaration would be a reasonable way to enable this behavior.
|
|
|
|
|
|Now, well, but Perl is quite different here. As I remember,
|
|
|it doesn't have all the dynamic features of Python.
|
|
|
|
My point was not to imply "what" would be done by the switch, only "how" it
|
|
could be flipped ;-)
|
|
|
|
|> |Then, what would you do with classes which depend on each
|
|
|> |other? You cannot lock them immediately, this would fail.
|
|
|>
|
|
|> Could you give an example?
|
|
|
|
|
|class abstractparser:
|
|
| magic = 42
|
|
| pass # numerous default and stub methods
|
|
|
|
|
|class parserops:
|
|
| "mixin class"
|
|
| def general_method1(self, *args):
|
|
| self.parser_method(self.scanner, args)
|
|
| def funky_method(self, *args):
|
|
| #some code there
|
|
| return self.magic
|
|
|
|
|
|class someparser(abstractparser, parserops):
|
|
| def parser_method(self, scanner, *args):
|
|
| # do something, and then use the mixin
|
|
| self.funky_method(2, 3, 5)
|
|
|
|
|
|Sorry about my lack of spirit today, this example is bad.
|
|
|But, if you lock class parserops after it is created,
|
|
|it will barf, since parser_method cannot be resolved yet.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|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.
|
|
|
|
Randall
|
|
|
|
|
|
|
|
|