Posts Tagged ‘import’

PyPy 2.5-features – Starting to port the standard lib

Wednesday, August 6th, 2008

A little late I know.

This week I finished to fix all the failing tests and to implement PEP 328 (Absolute/Relative import).

Now it’s the final step for supporting Python2.5 on PyPy, to port the standard library.

I’m starting with it today and I really hope I can finish it all (including tests and everything else) until the end of next week.

Well, one more time, if anyone want to help me, test your python programs (specially the ones that use python2.5 specific features, like with statement, conditional expressions and new generator stuff) in PyPy-2.5-features (svn co http://codespeak.net/svn/pypy/2.5-features pypy-2.5-features).

How to test? Simple:


$ cd pypy-2.5-features
$ ./bin/py.py your_python_program.py

Be careful and patient, it may take a little bit to things start happening :-)

Of course you can translate PyPy using the translator if you want. Take a look at PyPy’s website for more information.

PyPy 2.5-features – Yet another status update

Friday, July 18th, 2008

Here comes another GSoC status update :-)

Some finished tasks:

  • throw() method on generators
  • close() method…
  • faking 2.5 behavior for IMPORT_NAME and IMPORT_FROM opcodes
  • changing the default value for magic attribute of PyCode objects
  • changing the magic number that goes in .pyc files compiled by PyPy
  • fixing tests and more tests…

From those changes the only one I would like to comment is the change of both magic numbers.

First, they have different values and meanings in PyPy. The magic number for .pyc files (defined in pypy/modules/__builtin__/importing.py) is the number that identifies the bytecode “version”. It’s used to know if the interpreter should use the .pyc file or should recompile the .py. PyPy’s value is different from CPython’s one. As we are changing some opcodes (as IMPORT_NAME, mentioned before) this number had to be changed. The old value in PyPy was 1024 (or 1024 + 2 or 1024 + 4 or 1024 + 2 + 4, depending on some command line options), the new value is 1034 (or ….). We are just using the same policy CPython uses to change the value, add 10 to the old value.

Now the PyCode magic attribute. This value is the CPython magic number (the one explained above)., the old default value was the value from CPython 2.4 (62021). Some checks against this value are made through the code to decide if the bytecode should be interpreted one way or another. One example is the IMPORT_NAME opcode. In Python 2.4 IMPORT_NAME did not have the level parameter, this parameter is new in 2.5 because of the absolute import feature. So if the bytecode represented by a PyCode object is 2.4, when we visit a import statement we should not try to pop the level value from the stack (because it’s not there), but if it is 2.5 we should! So we check the magic value. The problem is, the default value was 2.4 but we changed the opcodes to behave like 2.5, so those checks were not working. The solution was to change the magic default value to 63231 (2.5c2 value I think), so now our bytecode interpreter is (almost?) compatible with 2.5 bytecode. And our compiler is generating 2.5 compatible bytecode as well.