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.
Cheers,
Ben