[Python-Dev] Re: GadflyDA in core? Or as add-on-product? (original) (raw)
Brett Cannon bac@OCF.Berkeley.EDU
Tue, 21 Jan 2003 16:21:46 -0800 (PST)
- Previous message: [Python-Dev] Re: GadflyDA in core? Or as add-on-product?
- Next message: [Python-Dev] Re: GadflyDA in core? Or as add-on-product?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Stuart Bishop]
> Sorry for not responding before. I'm open for doing this, but you > should probably probe python-dev next before you start a big coding > project. How much C code is involved in Gadfly? If it's a lot, I'm a > lot more reluctant, because C code usually requires much more > maintenance (rare is the C source file that doesn't have some hidden > platform dependency).
Gadfly comes with kjbuckets, which is written in C. The rest is Python. Gadfly uses the included kjbuckets for storage if it is available, but happily runs without it with a performance hit. So Jython gets a RDBMS implementation too.
So my first question is what is the license on Gadfly? I assume it is compatible with going into Python, but I thought I would ask.
Next, how much of a performance hit is there without kjbuckets? I am with Guido with wanting to minimize the amount of C code put into the libraries where there is no requirement for it. And if there is a decent hit what would it take to code up something in Python to replace it? We could leave it as an option to use kjbuckets if we want.
And if taking out kjbuckets is unreasonble, what license is it under?
I personally would love to have an actual DB in the stdlib so if these questions get positive answers I am +1.
-Brett
- Previous message: [Python-Dev] Re: GadflyDA in core? Or as add-on-product?
- Next message: [Python-Dev] Re: GadflyDA in core? Or as add-on-product?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]