Python IS slow ! [was] Re: Python too slow for real world

[Christian Tismer]

Randall Hopper wrote:

[tismer().chris about locking]

>  |Well, I wouldn't do that by default. By default, everything could stay as
>  |it is.  First of all, this would not break any existing code.
> 
> Right.  I wasn't too clear.  By default, I mean I don't want to have to
> insert some commands/declarations for every namespace (every class, every
> method, every module, etc.) to lock them.  I want this to happen
> automagically based on a switch.
> 
> 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.
In Python, you can reference any identifier in a function
or class definition without the need that the object exists.
That's the reason why I'm talking of an optional feature,
since it has reasonable semantic side effects.

>  |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.
It will also not resolve self.magic, since it doesn't
inherit from abstractparser.

But if I lock someparser, it will get all of its methods
right though the inheritance mechanism once.

>  |Depending on how exactly will be implemented, a single line
>  |at the end of a module should suffice to accomplish this stuff
>  |for the standard cases.
> 
> This would prevent namespace binding and locking from occuring while the
> module is being parsed, wouldn't it?  With a lock declaration at the
> beginning, Python could do this as it goes.  Seems like that would be
> easier (Python sees end of function -> module.symbol referenced in the
> function was not defined -> flag error and abort parse).

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

(again not good :)

This would need to be locked after both are defined,
otherwise we had to invent declarations which is bad.

>  |As a side effect, locking a module would also find all
>  |referenced but undefined symbols.
> 
> That's the goal I'm rooting for. ;-)

If it is just that, download Aaron Watter's kwParsing module
and use its pylint module to see lots of complaints about 
your source :-)

>  |Anyway, this is still no cakewalk and quite a lot of code
>  |is involved. Needs much more thinking...
> 
> Definitely.  No doubt Guido and the other language experts have a better
> feel for this than I do.  But I felt compelled to chime-in on this topic
> since it's important to me (and the squeaky wheel gets the grease.  :-)

Sure that they will also not like my idea, but this
cannot stop me from trying :-)

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