importlib version of zipimport is finished

I finally got around to bothering to tweak test_zipimport to run using my importlib implementation of zipimport. My implementation is not fully backwards-compatible, but the tests that fail are because the current version was written in C. I mean who cares if the 'prefix' attribute on a zipimport instance doesn't end with a path separator? You should be using os.path functions anyway which handles that. And there is nothing wrong if someone names a zip file 'None', and thus makes None itself a legitimate path argument.

So I consider it done at this point. Only took 228 lines of Python code to pull off. Compare that to 1197 lines of C and I think that's an improvement. =) My implementation could even be improved to allow for writing back out bytecode when it is missing.

As for importlib, I have PyCon stuff and coding stuff. For PyCon, I have submitted for a 30 minute talk on the algorithm of import. I am also working on a tutorial proposal on imports. That is looking to have:
  • A longer version of my PyCon talk with 2.x details included (my PyCon talk is 3.0 only as it keeps the details simpler).
  • How importing source, bytecode, extension modules, and frozen modules work.
  • PEP 302 optional extensions and why you should care.
  • How to make extension modules reload safely (that one is for Doug, and for 2.x the answer is you don't =).
  • How to make your package load a custom importer/loader automatically.
  • Importlib so that you don't have to re-implement the basics.
  • Shutting down bytcode generation using importlib.
  • Creation of an HTTP-based importer/loader.
  • Going over a real-life example using the zipimport re-implementation.
That will probably take up three hours, but I am not sure. Still thinking about how much time some things will take.

As for coding, with this out of the way I am now working on getting a C implementation of the core parts of the 'warnings' module done. That will let me do actual testing under Py3K to look for backwards-compatibility problems. And then I begin ripping out C code and re-implementing C APIs.

So much to do. But I also have demo and paper submission deadlines for my Ph.D. research that take precedence so I have no idea when I am going to any of this.