> > There is, of course, a definite downside to Inline. Your code will get > > harder to read and maintain because you and whoever else has to maintain > > your code has to be familiar with all the languages you are inlining. > > > > Skip > This is more an argument against mixed language programming > than against Inline. > Inline makes it easier (a no-brainer) to locate the code which > has to be changed, to determine what has to be recompiled, > where (and how) it has to be installed, and so on. > > I've played a little bit with the idea and I certainly > like it. > > Thomas If the alternative is writing an extension module, the inline approach sounds viable to me. I could also imagine auto-wrapping existing C functions based on parseable function signatures. I believe VB supports this. Dangerous, but powerful, and very useful in the right hands. It seems to me that the important idea here is to break away from building and distributing a separate extension module, which gets you in the edit-compile-link-test-run loop that Python tries to avoid. Rather than requiring an expert who knows how to download, build, install and use SWIG or how to write Python extensions, all the expertise is automated. Getting this to work on Windows for the average Windows user would be a big hassle, limiting the portability and therefore the usefulness. Of course, Jython already has all this, thanks to Java's introspection capabilities. I wonder if the new C++ standard makes enough run-time type information able to be able to pull of the same trick? --Guido van Rossum (home page: http://www.python.org/~guido/)
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