David Beazley <beazley@cs.uchicago.edu>: > I've looked briefly at Inline and agree that it's a pretty nifty > approach. However, usability aside, it's got a number of pretty major > limitations once you start getting into structure wrapping, C++ > classes, and other advanced types of extension wrapping. Indeed, you've put your finger on what seems like the biggest problem with the current crop of semi-automatic extension generators. I don't think there is ever going to be a completely automatic solution to this, because, once you get beyond the basic types like ints, floats and strings, there is no unique mapping between Python types and C types. While the tool could provide some sort of default translation for arbitrary types, it's unlikely to be what you need to interface directly with some existing C library you're trying to wrap. So you're faced with writing a lot of tedious and error-prone code for messing with PyObjects and reference counts. I've had some ideas floating around in my head for a while concerning what to do about this. The key observation is that such code usually spends a lot more lines manipulating Python data than it does C data, which leads me to the conclusion that C is the wrong language to write it in. What's the right language? One that's good at manipulating Python objects. Which language is the best at doing that? Why, Python, of course. But not just Python, because we need to be able to manipulate C data structures as well. So we need a language that looks like Python at one end and C at the other... Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4