I've started playing around with minor projects in my personal launchpad space, partially to try out bzr.

Most recently I wrote a hack, temporarily named "pyexport", which allows you to control the names which your library module namespaces export to application code.

So far, I've implemented a few features.

1. export.alias(), which registers an alias for a method in another module that will not be imported until that module is imported,
2. export.explicitly(), a convenience function which makes cooperating with __all__ easy
3. export.internal(), which marks a module as "internal", and warns any application code (code outside the package which defines the module) which tries to import it
4. export.restrict(), a method which prevents "leakage" of extraneous imported or private names - for example, if you have a module 'foo' which imports 'sys', you can normally do 'from foo import sys' in Python and get a result.
   
5. export.singleton(), which replaces the calling module with a proxy that shares a namespace between the given singleton and the module itself.
   

It'll be some work to turn this rough prototype into something really usable for a large system like Twisted; at the very least it will need to be rebuilt test-first and integrated with the pydoctor and pydoc documentation tools.  Let me know what you think, and if I should pursue it!

Tags: code, python, twisted

If you've ever tried to use __slots__, you might have noticed that it comes with a pleasant side-effect: it makes it impossible to assign extra, garbage attributes to your objects. While normally not a serious problem, objects with extra, unintentional crud stuck to them can make object databases hell to work with as you struggle to figure out where it came from or why it is in your database but not in memory. Therefore, this semantic feature is handy in addition to reducing the memory footprint of objects if you have large numbers of them lying around.

If you've noticed this, you've also probably noticed that it is damn near impossible to use __slots__ because you have no control over what slots are used from your base classes.

Here is a solution to this problem that I have been working on for a while: SlotMachine. While it breaks isinstance - you weren't using isinstance anyway, right? - it does do the sane thing that you would expect a cooperative __slots__ implementation to do; you can subclass from random other classes (provided that you properly specify all their attributes as slots on your object) and other SlotMachines, and even other objects that define __slots__, without giving up the explicit specification of attributes or the ability to inherit from things.

I'll add some more comments to that file later tomorrow, I think.

Tags: axiom, code, evil, python
Current Mood: weird
Current Music: Only (by Nine Inch Nails on "With Teeth")

We managed to release something yesterday - Pyflakes, a tool similar to PyChecker but about a zillion times faster and provides fewer useless warnings. The author is Phil Frost, one of our developers and the lead maintainer of the Unununium OS project. Pyflakes was previously available through his home page, but we've started hosting it on divmod.org in the hopes that it can get some wider exposure and use and raise the average index of Python code quality throughout the universe.

Tags: code, pyflakes, python, releases
Current Mood: stuponfucious
Current Music: Tutelary Genius (by Universal Hall Pass on "Mercury")