Necoro’s Blog

Blog? Blog? There is no blog…

Posts Tagged ‘Python

Portato’s new C-Modules

leave a comment »

As I’ve written yesterday I created an eix cache parser. But … it was overengineered: It took like ages and was way slower than the normal portage way:

$ python -m timeit "import test; test.eix()"
10 loops, best of 3: 3.18 sec per loop
$ python -m timeit "import test; test.portage()"
10 loops, best of 3: 280 msec per loop

Thus I had to improve it: The first thing was to re-implement it using Cython. And step after step I ripped out features (in the original approach, the parser was lazy, i.e. only reading data if he needed to do so) and trimmed it down to what I really needed (opposed to being complete). Oh – and some C-level improvements :) (like using | instead of +).

Well: This is where I ended:

$ python -m timeit "import test; test.eix()"
10 loops, best of 3: 56 msec per loop

Now it is usable :)

Well — and while testing the new eix parser, I noticed, that Portato segfaults sometimes during shutdown. I thought the shm module the culprit and thus replaced the external dependency by a self-written module (again in Cython). And this also now uses message queues instead of shared memory — which is more intuitive and easier (no stupid locks and stuff). Seems to work up to now :)

Result: In the future, portato ships with C-Modules :) (hence the title

Written by Necoro

August 15, 2009 at 13:38

Posted in Portato, Python

Tagged with , , , , ,

Cobra — An alternative?

leave a comment »

As probably widely known, my preferred programming language is Python. But … well … I like to try out new things. Thus I sometimes look through the interwebs to find an interesting new alternative (Note: I still want to learn (and use) Haskell…). And recently I found Cobra: In short: It has a pythonic syntax, but knows natively about unit-tests and design by contract. The latter point is the interesting one: I also wanted to try D for the same purpose, but it a) has no real open source compiler (I know of), and b) pythonic look and feel is better then C-like. Only drawback(?): It is .NET based. But well … we’ll see how this works out. Cobra itself is also designed in a way, that it can use different backends later on. (I like exchangable backends :P)

The features of Cobra:

Lets put some code here (taken from the HowTo directory :))

class Utils


def compute(x as float, y as float) as float
x > 0
y > 0
result > 0
return x.sqrt + y.sqrt

def normalizeName(name as String) as String
# If a contract has only one condition, you can write it
# on one line and skip ‘body’.
require name.trim.length
ensure result.length <= name.length return Utils.capped(name.trim) def capped(s as String) as String """ Returns the string with the first character capitalized. Returns a blank string for a blank string. """ ensure result.length == s.length result.length implies result[0] == result[0].toUpper test # Unit tests can enhance contracts by showing example # invocations and verifying behavior. assert Utils.capped('chuck')=='Chuck' assert Utils.capped('Chuck')=='Chuck' assert Utils.capped('')=='' assert Utils.capped(' foo')==' foo' assert Utils.capped('f')=='F' assert Utils.capped('1aoeu')=='1aoeu' body if s.length return s[0:1].toUpper + s[1:] else return s [/sourcecode] So ... let's see where this is going to lead :). I plan to make an ebuild for the next release (the current ones do not include sourcecode) ... and then the fun can start.

Written by Necoro

April 8, 2009 at 22:59

Posted in Cobra

Tagged with , ,