But in general I try to prioritize my Python time since I only have so much time. As of right now, here is the prioritzed list:
- Move the tracker over to Roundup. [bumped priority; 2007-04-16] While I won't personally do the transition, I am involved and need to make sure it happens.
- Write PEP on fixing ``if __name__ == '__main__':..`` idiom. [added 2007-04-16] You can't execute a module in a package that uses relative imports thanks to the module's __name__ value being set to '__main__' (can't resolve the package depth for the imports). I want to write a PEP to propose a way to fix this.
- Write PEP on security changes. [added 2007-04-16] I need to try to get my security changes in PEP form and proposed by April 30 to be considered for Py3K.
- Edit PEP 352 to deprecate BaseException.message. Guido thinks this might be a record turn-around of releasing a feature (2.5) and then deprecating it (2.6). Glad I could be a part of it. =) Basically what has happened is making BaseException take only a single argument will break a ton of code and is a pain to get to work right at the C level. So BaseException.args is going to stay and 'message' goes. Need to make the PEP reflect this and make sure python-dev doesn't throw a fit.
- Backport various patches to the 2.5 branch. I got some patches in the trunk that should be backported to 2.5, but the branch is frozen while Anthony cuts 2.5.1 so I have to wait.
- Deprecate/remove BaseException.message. [added 2007-04-09] Since I changed PEP 352 I really should make it be true. =)
- Finish my security work. I need to get the bloody thing done! I am this close to being finished.
- Get key parts of my security work into the core. I want to remove the constructor for 'file' and 'code'. Everything else can easily be done by a user outside of the core code.
- Close all of my open issues. Have a handful that I should just deal with, the key ones being the Py3K ones if Guido does decide to stick to his goal of an alpha in June.
- Deprecate old platforms for 2.6. I want to get rid of AtheOS and Solaris 2.6 (and older). AtheOS is no longer a maintained OS, let alone the Python port. And the Solaris stuff is just plain old.
- Auto-generate PEP 0. The PEP index is maintained by hand. That has led to inconsistencies between what the PEP says and what the index claims. I have started work in the sandbox at creating PEP 0 from a Python script. Stalled on the work at the moment, though.
- Update PEP 302. While doing my import rewrite I discovered a couple of places where key information was just not stated. I need to go in an add the documentation.
- Graph control flow of import semantics. Another side-effect of rewriting import in pure Python was I became intimately familiar with how the whole thing works. I also realized how spread out the documentation is and under-specified it is. =) Because it has complex semantics I have decided to do a control flow graph that explains how import works (details in another blog post as I have already started this).
- Document importlib. The code is done. The bloody thing works (which still continues to amaze me =). But now I need to document it so people can use it. I just don't want to since the thing is highly modular and explaining the interactions is unintuitive without explaining the thought behind the design. And I just don't want to write a doc on how I view import should be considered as that seems a little pretentious. Plus I don't want to have to fight with people who don't like the design. But this needs to get done for a key reason ...
- Get importlib into the stdlib. The reason I have not packaged up importlib and put it up on the Cheeseshop is because I keep planning on getting importlib into the stdlib. But I can't do that until I get step 8 done. But once this one it is done, I get to do my next big project ...
- Make importlib the default (and only) import mechanism for Python. Yes, I want to ditch the C implemenation of import and use my pure Python version instead. I have to solve some bootstrapping issues. Hopefully I can also come up with a way to allow people to specify an alternative importer at startup before any other importing has begun (e.g., specify an NFS-friendly version before starting to import even site.py so as to minimize stat call costs), but this is a bonus thing that can come later.
- Cleanup import semantics. I hope that when people see the control flow graph for import they will be willing to listen to me on how I want to simplify things by making the semantics more explicit (e.g., no more value of None in sys.path_importer_cache meaning that the default import should be used as that would just be another importer on sys.path_hooks). PEP 328 (absolute imports) helps a lot (doing absolute name resolution the classic way is a mess), but that is just one step in the overall process.
4 comments:
My community mind says the Tracker is the #1 issue, and before any other core work is done, we need a fully functional roundup tracker for dealing with the management of all the other changes.
Roundup is the foundation for managing other core python work and getting that system in place and the process perfected is step 1.
That is my 'community' mind. My selfish side says get the import stuff working and get people to help you. I am working on my list as well and your import work is on it (though admittedly lower than I would like).
More and more python is becoming the defacto standard for grid computation. The power of emerging python technology stacks (stackless+twisted+pypy+GenC) and scientific packages (SciPy, etc) apear to be limitless at first. One limitation which is becomming all too apparent is the python import/compile side of things. Sony ImageWorks and CCP Games have already publicly stated that they have had to create custom python or crazy compile/import hacks in the name of efficiency. The current importhook system is too fragile and inflexible (bootstrap issues).
The existing import system is not scalable in a grid environment, even with iBriX and other exotic network storage solutions. Importlib seems to provide the framework needed to deal with these issues, the only missing pieces are those in your list (replace C importer, allow for custom system before sites.py).
My professional side is down right giddy.
That is a mighty list Brett. Best of luck in pinning it all down. Reading your list prompted me to update my own Python TODOs.
douglas: One thing to realize about the list order is that some have dependencies that will let me move forward. The other is some will take under an hour to do (e.g., backporting stuff).
As for getting help with stuff, that is usually pretty tough to do. This impacted by the fact that the bootstrapping thing is a "bonus" feature as it is not needed for Python to function. Plus bootstrapping requires intimate knowledge of how Python starts up and how imports work, which not a lot people know (or want to know). Maybe I can prod Neal Norwitz into helping since he keeps saying he wants this.
And I do hope importlib is flexible enough for your and the grid computing community's needs. I put a good amount of effort into making it easy to reuse the code so that if you only had a different back-end store you just needed to change that and not the logic for the source/bytecode dance (and vice-versa).
Anyway, hopefully it can help people get what they want.
Jack: Glad it helped light a fire underneath your ass. =) Congrats and quitting your job.
Have you seen TaskCoach? Coincidentally it is written with wxPython :)
http://taskcoach.sourceforge.net/
Post a Comment