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