Large part of development effort in Python 3 went into making the language definition and standard library cleaner and more consistent. However, the module importing functionality was originally implemented in C, which made extending it from the level of Python nearly impossible. This functionality has since been made more flexible and the situation was improved by introduction of import hooks as well as an implementation of __import__() in Python.
A modularised, self-contained import functionality would make Python more consistent and powerful, e. g. isolating import state would open avenues into implementing better sandbox environments (through module white/blacklisting).
Start of Program (May 24)
So far I have read most of available documentation about importing, i. e. the PEP 302 and the "Modules and Applications" draft linked on project idea site. Before starting to code, I would like to design an interface for ImportEngine class and make sure it will match current import functionality. Following that, I will try and identify implications for loaders and importers, and in what way PEP 302 will have to be modified.
To prepare for the project, I have been working on a patch for an issue related to module imports (http://bugs.python.org/issue9325), as recommended by Nick. However, I have been at a conference with limited Internet access over the past few days so I will need a couple more days to finalise and submit it.
I will also set up VCS (Mercurial hosted on Bitbucket), and write descriptions of the design in a designated wiki page (link) during the community bonding period.
Midterm Evaluation (July 12)
Final Evaluation (Aug 16)
- Initial setup and import-related state moved to ImportEngine class (week 1)
- Implementation of __import__() and helper functions, taking advantage of the isolated state (weeks 2-4)
- Support for import hooks (this part will need more specific design during the Community Bonding period) (weeks 5-6)
- Making sure unittests for importing 'ordinary' modules, packages, zipped modules and modules with loaders pass, filling the gaps (week 7)
Unless implementing core functionality takes more time than expected, I could move to implementing the 'extra' features:
- Controlling which modules can be loaded by white- and blacklisting (weeks 8-9)
- It would also be a useful extension to be able to conveniently migrate state from global import functionality and vice versa (week 10)
- Ensure the ImportEngine class can be conveniently subclassed to extend/modify its behaviour (week 11)
- Final testing and documenting (weeks 12-13)
My name is Greg Slodkowicz and I'm currently pursuing an MSc in Systems Biology at the Technical University of Denmark. My undergraduate studies were in Computer Science at the Technical University of Lodz, Poland.
Last year I completed a Google Summer of Code project under the auspices of Python Software foundation with Laurent Gautier as my mentor. I worked on porting RPy2 (library which exposes R libraries to Python, project repository located at http://bitbucket.org/jergosh/rpy2.1.x_python3_gsoc/) to Python 3 which involved mainly rewriting the C code connecting the two environments. That project taught me a lot about designing and implementing libraries, as opposed to standalone applications. I also got to know more about Python's internals.
I've been working part time as a scientific programmer at the Center for Biological Sequence analysis since late 2008. I specialise in graph-theoretic methods (network biology) and my work there consists of data analysis in Python and R as well as C++/Boost for performance critical applications. My other programming experience includes a set of Python scripts for managing online orders for a network of restaurants and an application for managing simulations and analysing and displaying results in real-time (written for Dublin Institute of Technology in C++ using Qt4 libraries).
I also have 5 years of experience with Linux (mainly Debian and later Ubuntu) which I used as my main platform before switching to Mac 2.5 years ago. I also have experience with Mercurial (including patch queues plugin) from last year's GSoC and other projects.
Spring semester at my university ends in early May, and that's when I would be able to focus on planning the project in detail. I don't have any holiday travel plans, apart from July 17-20 (which luckily is right after the mid-term evaluation).
Name: Grzegorz Slodkowicz
Phone: +45 22 87 23 77
Postal Address: Nordre Fasanvej 169.5
City, State, Zip, Country: Frederiksberg, Hovedstaden, 2000, Denmark