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




