[Python-Dev] Open CPython VM for type information

[Kay Schluehr]

Brett Cannon schrieb:

>
>
> On 12/12/06, *Kay Schluehr* <kay.schluehr at gmx.net 
> <mailto:kay.schluehr at gmx.net>> wrote:
>
>     Dear Python developers,
>
>     while the JVM is opened to support dynamically typed languages [1] I
>     wonder if the CPyVM could not show more openness to statically typed
>     languages? Hereby I don't think that much about arbitrary
>     languages for
>     the CPyVM but sublanguages like RPython which are "static enough"
>     to be
>     compilable into extension modules [2].
>
>     However creating C extension modules from Python code is not
>     really the
>     standard way I do think Python source should be handled. Instead I
>     think
>     about a more direct VM support like the JVM does, that provides
>     opcodes
>     like iload, fstore etc. Besides this I don't expect one canonical
>     approach for these type information to be feeded into the CPyVM. There
>     are type inferencer like rtyper for PyPy, Psycos continous bytecode
>     monitoring and also other approaches are possible that use type
>     feedback. Finally optional type declarations are also an issue;
>     however
>     I would like to see language design discussions being separated ( ->
>     Python 3000 ) and focus on general APIs for compiler extensions /
>     plugs
>     that deal with type information ( the architecture ) and VM
>     implementation issues.
>
>     Thanks, Kay
>
>     [1] http://jcp.org/en/jsr/detail?id=292
>     [2] http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html
>
>
> The Python VM is not designed to be general-purpose, period.  Nor does 
> anyone on python-dev, to my knowledge, have any interest in putting 
> the time and energy into making it general.  I am quite happy with 
> letting the Parrot folk handle this goal.  This means that the 
> maintenance cost of adding more opcodes is not worth it.
>
> But a bigger issue with me is the performance hit.  Every opcode will 
> make the eval loop larger.  And it is known that the eval loop is 
> rather finicky in terms of size and performance.  While no hard 
> testing has been done, it has been assumed we have accidentally hit 
> the sweet spot in terms of CPU cache size.
>
> An important thing to keep in mind when comparing Python's VM to 
> Java's is that Java works (somewhat) for dynamic languages because 
> people are motivated enough to shoehorn languages into it by just 
> assuming everything is just an object and tossing out the type 
> checking inherent to Java.  But Java has not, to my knowledge, grown 
> any great features yet to make dynamic languages work better.  I know 
> about JSR 292, but that is not in yet and adding just one opcode is 
> not that expensive to the JVM.  But compare the cost of adding a slew 
> of typed opcodes to Python compared to the JVM adding just one is not 
> really equal.
>
> In other words, I wouldn't count on this ever happening.  =)  The best 
> you could do is try to propose some direct mechanism for adding 
> support to the eval loop to dispatch to some function for unrecognized 
> opcodes, but I wouldn't count on that being accepted either.
>
> -Brett

Brett, thanks for the short answer. Although it is negative regarding my 
attempt, it is also important to know which ideas are outlawed and where 
one steps into a no-go area concerning the evolving language standard 
and its main implementation.

Regards