More seriously, it's not a software intended to be run by Tor users or even Tor relay operators, it's a framework intended to be used by Tor developers / hackers to play with implementations of the Tor protocol.
Gotcha. It might be worthwhile to clear this with tor-assistants@lists.torproject.org to ensure that this won't be a problem down the road if TorPylle grows. I can speak from experience when I say that renaming a project is a pain in the ass. Especially once its been established for a while. I'd loooove to rename arm (years back when I picked the name the processor didn't have much prominence) but doing so is now just too daunting.
On a side note the appearance of your project has kinda funny timing. Just last week I was thinking "Gah! Why does tor's reference implementation need to be C?". In my not-so-humble opinion that's dragging the application down in terms of maintainability and continued development...
* Tor has only three people (mostly just Nick) routinely touching the core codebase. This means effectively no code reviews and little collaboration. This is not likely to get better with time - universities have been shifting toward higher level languages for years as have industry.
* Mocking is a pain with C. Nick had some ideas six months back to get around this, but I'm not sure if they ever really took off or itself is maintainable.
* C is simply difficult to get right. Besides the risk of stack overflows and memory leaks, there's countless pitfalls that necessitate years of C development experience before touching a line of code.
* Tor really doesn't *need* to be in C. Descriptors, controller, consensus voting, and much of its other functionality would do better with a higher level language, with small C modules for networking and crypto parts that truly need Libevent and such. This would be fine with Java's JNI, Python, Ruby, or any of a handful of languages.
All this said Nick no doubt could list a dozen reasons why this is a terrible idea, not the least being the monumental amount of work and wanting a tor executable without the need for an interpretor. Oh well, I can still dream.
I just had a look at this project, and if I understand well, it speaks to a Tor's control port and gets its data from the Tor client. With TorPylle, I want to be able to fetch data from any Directory Server directly, and act more or less "as if" I was a Tor client.
As I said previously, "It's not just a client of tor's control port, but also a python implementation of its directory specification."
Take another look at the remote descriptor module I pointed out. It's exactly what you want - it pulls descriptor content from the tor directory authorities and mirrors.
Cheers! -Damian