[Python-Dev] proto-pep: How to change Python's bytecode (original) (raw)

Brett C. bac at ocf.berkeley.edu
Fri Dec 24 21:43:19 CET 2004

After implementing over 10 new opcodes for my thesis I figured I should write down the basic steps in an info PEP so that there is enough guidelines with this PEP and PEP 306 to cover the bases on changes to the language itself.

To go along with this I also plan to write some benchmarks for individual opcodes that could possibly lead to a testing suite for the opcodes themselves (will probably do this piece-meal and put it up on SF initially since there are a lot of opcodes).

Anyway, let me know if I seem to be missing anything or have something to add. After a reasonable time of non-response to this I will request a PEP number (assuming people don't think this PEP is stupid).

PEP: XXX Title: How to change Python's bytecode Version: Revision:1.4Revision: 1.4 Revision:1.4 Last-Modified: Date:2003/09/2204:51:50Date: 2003/09/22 04:51:50 Date:2003/09/2204:51:50 Author: Brett Cannoon <brett at python.org> Status: Draft Type: Informational Content-Type: text/x-rst Created: XX-XXX-XXXX Post-History: XX-XXX-XXXX

Abstract

Python source code is compiled down to something called bytecode. This bytecode (which can be viewed as sequences of opcodes) defines what Python is capable of. As such, knowing how to add, remove, or change the bytecode is important to do properly when changing the abilities of the Python language.

Rationale

While changing Python's bytecode is not a frequent occurence, it still happens. Having the required steps documented in a single location should make experimentation with the bytecode easier since it is not necessarily obvious what the steps are to change the bytecode.

This PEP, paired with PEP 306 [#PEP-306]_, should provide enough basic guidelines for handling any changes performed to the Python language itself in terms of syntactic changes that introduce new semantics.

Checklist

This is a rough checklist of what files need to change and how they are involved with the bytecode. All paths are given from the viewpoint of /cvsroot/python/dist/src from CVS). This list should not be considered exhaustive nor to cover all possible situations.

Suggestions for bytecode development

A few things can be done to make sure that development goes smoothly when experimenting with Python's bytecode. One is to delete all .py(c|o|w) files after each semantic change to Python/compile.c . That way all files will use any bytecode changes.

Make sure to run the entire testing suite [#test-suite]_. Since the regrtest.py driver recompiles all source code before a test is run it acts a good test to make sure that no existing semantics are broken.

Running parrotbench [#parrotbench]_ is also a good way to make sure existing semantics are not broken; this benchmark is practically a compliance test.

References

.. [#PEP-306] PEP 306, How to Change Python's Grammar, Hudson (http://www.python.org/peps/pep-0306.html)

.. [#dis] XXX

.. [#test-suite] XXX

.. [#parrotbench] XXX

.. [#dis-docs] XXX

Copyright

This document has been placed in the public domain.

.. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:

More information about the Python-Dev mailing list