John Arbash Meinel john at arbash-meinel.com
Thu Jun 15 14:35:19 BST 2006

Andrew Bennetts wrote:
> Robert Collins wrote:


> Why not do it this way: for some feature foo with an optional C implementation,
> have a foo.py that simply consists of:
>      try:
>           from _c_foo import *
>      except ImportError:
>           from _py_foo import *
> Where _c_foo would be the "foo" module in C, and _py_foo would be the pure
> python fallback.  Tests for "foo" can directly access both _c_foo and _py_foo
> modules to make sure they both pass.  Callers of foo get the C version if
> available, and automatically get the python version if not. 
> I don't think the plugin infrastructure helps solve this problem.
> -Andrew.

Actually, Robert does an even trickier method. And that is because dlls
are preferentially loaded before .py files (just like .pyc is loaded if
it is not out of date).

So he actually creates a 'foo.py' and a 'foo.so'.

The discussion here is what the best way of introducing extensions would
be. On one hand we could keep the core of bzr all python, and then have
extra modules that you could install (plugins already exist for this),
which would include the compiled extensions.

Robert is arguing that the code should be in the core, and only loaded
if the person could compile it.

At this point I'm on the fence. I've done all my work in plugins that
load themselves and monkeypatch the appropriate functions. I can turn
them on/off with 'bzr --no-plugins'. However, if we feel that these are
key performance improvements, then probably they shouldn't be disabled
by that flag.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060615/2fe352a1/attachment.pgp 

More information about the bazaar mailing list