Python IS slow ! [was] Re: Python too slow for real world
Randall Hopper
aa8vb at vislab.epa.gov
Fri Apr 30 13:08:07 EDT 1999
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
More information about the Python-list
mailing list