Brett Cannon schrieb: > > > On 12/12/06, *Kay Schluehr* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
