Robert Bradshaw schrieb am 21.08.2016 um 11:30: > You ask at the beginning of the email whether time has vindicated our > philosophy. I think, based on the mindshare vs. these other attempts > at integrating with C, in large part it has. It has served us and our > users well; we will strive to stay close to Python. > > Tight interleaving of multiple languages in is cute for making a > polyglot script, but I do not think it leads to legible code. An > "eval_cpp" operator would be a lot like the builtin eval--it'd be > really tempting to do the "quick and easy" hack of dropping in some > executable string instead of thinking how to structure things such > that that could be avoided, but putting in this effort leads to more > comprehensible code.
+1 > It's hard to say "no" to features, but I think such an introduction > would fundamentally change Cython and how it's written for the worse. ... and restrict the further development of Cython to anything that doesn't break what users have relied on in their interwoven code. I agree with all of your arguments. But I'd like to note that it should still be quite possible for the OP to write a preprocessor for pyx-ish files that extracts any contained C/C++ code snippets (e.g. from specially marked Python strings with a bit of a metadata DSL), drops them into an external C/C++ header file as functions etc., and then replaces them with external function calls in the original file, before passing it through Cython. That's essentially how the described feature would work anyway, but it would keep Cython itself free from any eval-my-string special handling and user code integration overhead, while allowing users to play around with the possibilities of keeping everything in one source file. If that turns out to become the Next Great Thing, we will at least have learned something from real usage by the time we get there, rather than building something now that eventually everyone (but a few) will hate and not use. I've seen some people turn their back on Cython because they didn't understand it and instead started their own projects their own way. It's obviously everyone's good right to do with their free time whatever they want, but most of those attempts have visibly failed by now. They usually didn't even survive the first couple of months or weeks. It often seems so much easier (and certainly more fun, right?) to start something out in the open countryside that never gets anywhere, than to build on something existing which not quite but almost does what you need. I'd be happy to help making it easier for people to integrate their own tooling with Cython. Not everything needs to be an integrated part of the compiler itself, and certainly not everything should be maintained or developed by us. Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
