[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] making gnuradio blocks entirely in python

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] making gnuradio blocks entirely in python
Date: Tue, 27 Sep 2011 10:18:45 -0400

On Mon, Sep 26, 2011 at 12:17 PM, Ben Hilburn <address@hidden> wrote:

On the other hand, part of me doesn't want it in GNU Radio because I don't want people to start using it as the default way of doing things, specifically, that they don't start with a pyblock and never move it into a proper C++ block. In my experience with numpy (and scipy), they are great interfaces and they are faster than using Python, but they are still much slower than they could/should be. So we shouldn't be relying on Python-level stuff for real implementations.

"Devil's avocado, here, Dave" -  For what it's worth, I think you could put it into GNURadio proper, and not have it become the de-facto standard for block development.  If people want to use the tool to rapidly-prototype block functionality, this seems ideal.  Filter design in GNURadio could suddenly become much easier - especially for people unfamiliar with the C++ / Python barrier.  Once someone gets a block working, it would be easy to simply refuse to merge it into the proper codebase until it is written in C++.

Part of this comes from the fact that I think there is a serious difference between the production/release code that is in GNURadio proper, and the prototype code that people all over the world are writing from desks covered in textbooks, research papers, and mad scientist drawings of new radio designs.

If we can make it easier for the mad scientists to prototype stuff in Python, I'm all for it - because that means the good stuff can get translated into C++ production code, and merged in.

Anyway, this is certainly an interesting point and discussion - I just wanted to throw my opinion in.


Yes, it's just my concern that people will use it for development but just get comfortable in that mode and not move it into c++ for production.

As always, the way we intend for things to be used is not always the way they are used.

That's just a concern, though, and not a show-stopper. If that's how people want to work and they aren't having performance issues, then why not let them work away?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]