PyPy GSoC Application: Supporting Python 2.5 features in PyPy

Hi, I'm a under-grad student (3th year) from "Centro Universitário SENAC" from São Palo, Brazil. I'm very interested in the PyPy project and since last year I have been planning to get involved. Well, this plans has transformed into my graduation project that I'll start working next semester. My graduation project idea is to study two different implementations (CPython (C/Static/lower-level) and Pypy (Python/Dynamic/higher-level)) of a programming language (Python) and compare the difficult to hack both. I intend to study both and suggest optimizations to the implementations and show that it is easier to modify the higher-level implementation. Well, I told you this because my GSoC application is all about the Pypy interpreter (or the Pypy implementation of Python ) ;). I wrote some ideas to the project, so I ask if anyone could review it. PROPOSAL: Support new features of Python 2.5 in PyPy ========================================== * Motivation and goal Pypy's interpreter currently supports some of the "new" Python features introduced in Python 2.5. Also, the Python 2.5 changes to standard library have not been ported yet. This proposal goal is to bring 2.5 features and changes to Pypy interpreter. * Features Some features are already supported (for example __index__). I'm proposing to make Pypy support all the remaining features from 2.5. There are changes made to the python standard library[1] that haven't been ported yet because of the lack of 2.5 features, so I'm proposing to port this changes (some major modules added are sqlite3, ctypes and ElementTree) too. So, what I'm proposing: * Support all Python 2.5 features * "Sync" PyPy's standard library with CPython [1] http://docs.python.org/whatsnew/modules.html * Coding I started looking into the list of what is new in Python 2.5 to see if any new feature would need a special attention. My plans are to start coding the changes to the language (not to the stdlib) because I think it doesn't make much sense to implement the stdlib without full language support and it seems that porting the stdlib will not be much trouble (not as much as supporting some features :-)). I intend to start coding some simple feature (like PEP-342 that seems easy to support) so I can study the PyPy interpreter better. Then I'll code the other features (PEPs 314[is this really needed in Pypy?]], 328, 342, 343[or what is missing] and 352). [am I missing any other feature?]. With all features supported (and tested :-)) I'll code the stdlib changes. At this point I think I'll be familiar with the interpreter code so I pretend to port first the sqlite3 module. I like follow TDD (Test-driven development) so tests will not be a problem (I mean, it will be part of the final code, of course :)). PROPOSAL END. Thanks, -- Bruno Fialho Marques Gola <brunogola@gmail.com> bgola` @ irc.freenode.org http://www.brunogola.com.br Cel: (11) 9294-5883

ta ai On Sat, Mar 29, 2008 at 12:30 AM, Bruno Gola <brunogola@gmail.com> wrote:
-- Bruno Fialho Marques Gola <brunogola@gmail.com> http://www.brunogola.com.br Cel: (11) 9294-5883

Bruno Gola wrote:
There is a complete list of missing things here (see Catch up with CPython 2.5/2.6"): http://codespeak.net/pypy/extradoc/planning/roadmap/goal_cpython_replacement... I guess it would be wise to refer to the tasks in your application. Kind regards, Alexander

ta ai On Sat, Mar 29, 2008 at 12:30 AM, Bruno Gola <brunogola@gmail.com> wrote:
-- Bruno Fialho Marques Gola <brunogola@gmail.com> http://www.brunogola.com.br Cel: (11) 9294-5883

Bruno Gola wrote:
There is a complete list of missing things here (see Catch up with CPython 2.5/2.6"): http://codespeak.net/pypy/extradoc/planning/roadmap/goal_cpython_replacement... I guess it would be wise to refer to the tasks in your application. Kind regards, Alexander
participants (2)
-
Alexander Schremmer
-
Bruno Gola