[Cython] Any way to embed C/C++ in a single source compilation of a pyx file?
I just added inline_module's and submitted a PR today here: https://github.com/cython/cython/pull/555 My intent was something like OpenCL's JIT/AOC compilation (PyCUDA/PyOpenCL also work this way) which is simple and high performance, and I saw cython had this capability and just needed a little bit of a wrapper to expose it better. But after trying to put it into use for my own problems, where I would regularly want to use Eigen or other integration problems I realized I'd still have to write and save [many] code fragments to other files which cythonize-ing would read in through includes, when you need to work with something that doesn't have a cython cimport module. This is pretty ugly and doesn't achieve the easier flow that I had wanted. However if there was a way to embed C/C++ inside a pyx file (that is inline to strings), there would be no such issue. I submitted an issue here https://github.com/cython/cython/issues/556 but I was hoping to get the ball rolling if the ML is where the development conversations happen - it's not clear to me right now the best place for the Cython project to request this from, so sorry to cross post. Regards, -Jason ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
Accidentally posted to an already-opened tab for the cython-users ML yesterday, moving to here. Following up from a github opened issue here: https://github.com/cython/cython/issues/1440 I was hoping we could give a way to drop straight into C/C++ inside of Cython pyx files. Why? -It [helps] avoid needing to declare every class/function in cython, a somewhat daunting/impossible task that I think everyone hates. Have you libraries like Eigen or others that use complex template based techniques? How about those with tons of [member] functions to boot or getting C++ inheritance involved. -It works around having the Cython compiler know about all of C++'s nuances - as an advanced C++ developer these are painful and it is a 2nd class citizen to Cython's simpler C-support - that's no good. Just right now I was bitten by yet another template argument bug and it's clear C++ template arguments have been kind of dicy since support appeared. -It would allow single source files - I think this is important for runtime compiled quasi-JIT/AOC fragments, like OpenCL/PyOpenCL/PyCUDA provide The idea is that Cython glue makes the playing field for extracting data easy, but that once it's extracted to a cdef variable for instance, cython doesn't need to know what happens. Maybe in a way sort of like the GCC asm extension. Hopefully simpler variable passing though. The alternative to not having this construct is a concrete wall. I'll have to segment up files for C++ for the rest of time until I get function forms that Cython can handle. At that point I just say screw it and use boost python. Of course cython does the definitions, data extraction, and compilation so much easier than boost.python. It would be a shame to not consider this plight C++ developers have been cornered into and you can't say the C++ libraries are broken, it is the strategy Cython is taking that cannot work. I did some examination of how this could be implemented - my idea was to base on the print/exec statements handling and simply emit their arguments from the Nodes to the code generator. Proposing inline_c or inline_ as the statement. Such a statement could be used to do macros, pull in includes, and modify/declare c-variables. -Jason ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
On Fri, Aug 19, 2016 at 5:36 AM, Robert Bradshaw wrote: > On Thu, Aug 18, 2016 at 12:05 PM, Jason Newton wrote: > > Accidentally posted to an already-opened tab for the cython-users ML > > yesterday, moving to here. Following up from a github opened issue here: > > > > https://github.com/cython/cython/issues/1440 > > > > I was hoping we could give a way to drop straight into C/C++ inside of > > Cython pyx files. > > > > Why? > > > > -It [helps] avoid needing to declare every class/function in cython, a > > somewhat daunting/impossible task that I think everyone hates. Have you > > libraries like Eigen or others that use complex template based > techniques? > > How about those with tons of [member] functions to boot or getting C++ > > inheritance involved. > > I agree that this is a pain, and better tooling should be developed to > (mostly?) eliminate this (e.g. see the recent thread at > https://groups.google.com/forum/#!topic/cython-users/c8ChI6jERzY ). > > Of course having symbols magically appear (e.g. due some #Include, who > knows which) has its downsides too, which is why import * is often > discouraged in Python too. > > > -It works around having the Cython compiler know about all of C++'s > nuances > > - as an advanced C++ developer these are painful and it is a 2nd class > > citizen to Cython's simpler C-support - that's no good. Just right now I > > was bitten by yet another template argument bug and it's clear C++ > template > > arguments have been kind of dicy since support appeared. > > Yes, C++ is an extraordinarily complicated language, and exposing all > of that would add significant amounts of complexity to Cython itself, > and perhaps more importantly increase the barrier of entry to reading > Cython code. One of the guiding principles is that we try to stay as > close to Python as possible (if you know Python, you can probably read > Cython, and with a minimal amount of C knowledge start writing it) and > much of C++ simply isn't Pythonic. > Maybe it's off topic but I debate the guiding principle of Cython - I was not able to comprehend Cython before reading tutorials and this is not my first time looking at it, I had a couple runins over the last 5 years with it on projects such as h5py easily got lost on what was going on between all the wrapper-wrappers (pure py code wrapping py-invokable code) and re-declarations. These projects complied with Cython's current philosophy to the degradation of clarity, context, and overall idea of how code was hooked up. Perhaps Cython should take the lessons learned from it's inception, time, and the results of the state of the c-python userbase to guide us into a new philosophy. > > Though, as you discovered, there are some basic things like non-type > template arguments that we would like to have. If there are other > specific C++ constructs that are commonly used but impossible to > express in Cython it'd be useful to know. > I haven't had the capability to use Cython sufficiently to learn more of them because it currently can't solve my problems. From prior SWIG et al experiences, my outlook is that it is treacherous path to walk and unless you brought in llvm/clang into the project for parsing/AST, I'd hold onto that outlook. > > > -It would allow single source files - I think this is important for > runtime > > compiled quasi-JIT/AOC fragments, like OpenCL/PyOpenCL/PyCUDA provide > > Not quite following what you're saying here. > Maybe PyInline was a better example off the bat for you, but something a little more flexible but also with less work is needed. Compare with PyOpenCL: https://documen.tician.de/pyopencl/ - check out some examples. There is a c runtime api between the contexts hooking things up (this is the OpenCL runtime part) - it's a pretty similar story to PyCuda (and by the same author, execpt for that project has to jump out to nvcc and cache kernel compilation like the inline function implementation does). There's no limit to the number of functions you can declare though and the OpenCL side is kept simple - things are generally pretty typesafe/do what you would expect on dispatch. PyInline for comparison looks like it might lean on the Python c-api for it's work more and maybe limited in the number of functions per snippet it can declare. I don't expect to be able to work with Numpy ndarray data easily with it. > > > The idea is that Cython glue makes the playing field for extracting data > > easy, but that once it's extracted to a cdef variable for instance, > cython > > doesn't need to know what happens. Maybe in a way sort of like the GCC > asm >
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
On Fri, Aug 19, 2016 at 3:19 PM, William Stein wrote: > On Fri, Aug 19, 2016 at 8:19 AM, Jason Newton wrote: > > You must realize that almost any other python driven way to compile > c-code > > in the spirit these projects do is deprecated/dead. Cython has absorbed > all > > the reputation and users that didn't go to pure-c/boost.python - > pybind11 is > > the new kid on the block there so I'm not including it (I'm of the > opinion > > that SWIG users stayed unchanged). Community belief/QA/designers/google > all > > think of Cython first. Weave has effectively closed up it's doors [...] > > May I ask why "any other python driven way to compile c-code in the > spirit these projects do is deprecated/dead?"I'm curious since > when I started Sage (and Cython based on forking Pyrex), it was > because none of the other approaches seemed like they would work for > the developer base I envisioned growing for Sage. That was a long > time ago, and I'm always pleasantly surprised that Cython has become > very popular. However, I didn't realize the other approaches were > deprecated/dead. > PyInline's last news update was in 2004 where the author gives a "Hats of[f] to PyRex", prior to that only a few blog entries in 2001/2002, I've not come across any project using it but maybe that is not sufficient to call it deprecated/dead? Does it work with Python 3? http://pyinline.sourceforge.net/ Pyrex no longer has a userbase. Last ML post was 2014. Weave only supports python2, got ripped out of Scipy and also directs to check out Cython and strongly implies the project is all but dead/maintenance mode: https://github.com/scipy/weave Did I miss any of the python driven ways? -Jason ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
On Sat, Aug 20, 2016 at 1:19 AM, Stefan Behnel wrote: > > Especially with respect to C++, we've always tried to make things safe and > helpful that Cython can support directly, and to make things possible that > are too complex to handle safely. But I agree with Robert that allowing > arbitrary C++ code snippets inside of Cython code is not a good idea. Why is allowing arbitrary code inside not a good idea? We're not talking something necessarily like eval here and the reputation it got, we're talking C/C++ glue and for the scale of Cython's development effort, proper C++ support is insurmountable simply because the language is that hard to work with on the compiler side. You can't just go and take something that is readily in the process of evolving (as newer standards actively come out), that very slowly achieves full compiler support in it's own domain, and pretend/aspire you can work like that though high level constructs in your language - this project and none before it have not accomplished anywhere near that and simply don't have the man-years/decades to contribute. I truly think it is irresponsible to think a) we should do nothing or b) delude ourselfs that we can make high level language level features to get around this. > > If there are code constructs that we can add to improve the C++ integration > then we should do that, even if it means that Cython would (initially?) not > be able to validate that code. But we should otherwise keep the language > such that it allows us to get back to a state where Cython can validate and > understand what it sees. > I'm not going to argue against you making C++ developer life easier but I have no idea how you could wrangle the beast in another way than letting the C++ compiler handle things. I don't think it's important that Cython compiler can validate / understand everything it sees - I'm not saying that by default, but just like the various flags you can use with cpdef, strategic sacrifices are acceptable for consenting adults. Otherwise you are still saying you will limit capability, which many can't agree with and avoid like the plague. Remember - cython is "the way" that comes up for how to glue C/C++ into python these days, not just the program in cish python frontend for speed. > > Stefan > > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
ctypes/cffi aren't in the same class for comparison. Just at the start of the list is basically a restriction from C++ name mangling fouling things up. Pybindgen uses a programmable model to generate bindings for existing functions/classes only. It's a fair bit different from anything I had in mind for the python side and even in the C++ binding side (boost.python class) or pyinline class - no additional code of any kind allowed. Last activity 2014 - I don't really have a handle on how alive it is, but I think it's inactive. On Sun, Aug 21, 2016 at 5:38 AM, Stefan Behnel wrote: > Robert Bradshaw schrieb am 21.08.2016 um 11:11: > > On Fri, Aug 19, 2016 at 12:32 PM, Jason Newton wrote: > >> PyInline's last news update was in 2004 where the author gives a "Hats > of[f] > >> to PyRex", prior to that only a few blog entries in 2001/2002, I've not > come > >> across any project using it but maybe that is not sufficient to call it > >> deprecated/dead? Does it work with Python 3? > >> http://pyinline.sourceforge.net/ > >> > >> Pyrex no longer has a userbase. Last ML post was 2014. > >> > >> Weave only supports python2, got ripped out of Scipy and also directs to > >> check out Cython and strongly implies the project is all but > >> dead/maintenance mode: https://github.com/scipy/weave > >> > >> Did I miss any of the python driven ways? > > > > Pybindgen? And of course there's ctypes/cffi. I could have sworn I saw > > another project pop up several years ago that was a lot like what > > you're suggesting, e.g. a listing of > > > > def foo(a, b): > >[c code using a and b] > > > > I don't recall how the types for a and b were declared/converted, and > > I don't think it did much non-trivial stuff yet, but I can't find a > > trace of it now (but it's hard to search for laking a name). > > This page lists some, although I can't see any real candidates for what you > describe: > > https://wiki.python.org/moin/IntegratingPythonWithOtherLanguages > > And most of those are dead links and/or projects. > > Stefan > > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
On Sun, Aug 21, 2016 at 1:36 AM, Ian Henriksen < insertinterestingnameh...@gmail.com> wrote: > >> Remember - cython is "the way" that comes up for how to glue C/C++ into >> python these days, not just the program in cish python frontend for speed. >> >> > There's some truth to the issues you raise, but there are a lot of nasty > details > behind the scenes. Do you have some more concrete details for what you're > proposing? In particular, Cython mangles all of its variable and function > names. > How do you want to work around that? How should exception forwarding and > throwing work? > Recall I'm not one of the Cython devs :-) I think it is reasonable without knowing detail to the internals of Cython that if mangling must be done, there can be an opt-out specifier to the mangling done on cdef'd functions and variables. Variables are where the meat is at for me but there could be some benefit to functions as well if there's no reason they couldn't come along for the ride if they don't add significant complication. I think for exception forwarding and throwing, the responsibility would lay to the wrapped code to guarantee either no thrown exceptions (you see this in multithreaded software all the time) or they must code the exception support in themselves. However easier user-handled translations patterns apply to make this a bit easier - set a cdef'd flag and a message and check that flag after the eval'd portion - then decode and possibly raise an exception. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
On Sun, Aug 21, 2016 at 5:30 AM, Robert Bradshaw wrote: > > In my experience Cython has generally been fairly easy to pick up for > people who already know Python. And Python often easy to pick up for > people who already know C/C++. Of course for many wrappings it often > takes non-trivial knowledge of the wrapped library itself too, but > typically at the same level as would be required to grok code written > against that same library directly from C/C++. > Is your experience drawn from binding moderately complex libraries or play code (of complexity like from a tutorial). Bottom up or top down? Sorry if this sounds asinine to you. To clarify, I'm coming from the case where I didn't read the whole tutorial/docs before being faced with pyx in the projects I previously mentioned, while on tight turn around time - I was not able to grok in that context. For myself and any other ML user who comes across this thread - can you list a few libraries that do things the right way? > > Yes, there's bad code out there in any language (no offense meant > towards h5py--I haven't looked at that project myself). Much of it due > to cargo-cult perpetuations or archaic (or simply flat-out-wrong) > contortions due to historical limitations (e.g. creating a Python > module to wrap an _extension module, avoiding all C++ features with > extensive C wrappers, ...). (You're familiar with C++, so likely no > stranger to this effect.) > > > These projects complied with Cython's current philosophy > > to the degradation of clarity, context, and overall idea of how code was > > hooked up. Perhaps Cython should take the lessons learned from it's > > inception, time, and the results of the state of the c-python userbase to > > guide us into a new philosophy. > > I fail to see how "staying close to Python" caused "degradation of > clarity, context, etc." If anything, the lessons learned over time > have validated this philosophy. More on this later. > My point was that multifile multi-level wrapper that I mentioned earlier - if you're saying that those projects did Cython extensions wrong, then I'm incorrect at faulting Cython and should fault the libraries using it. I didn't say staying close to python caused $blurb. I don't know in a situation as confusing as to all the binding projects if this should be taken as validation of philosophy either - I think it is reasonable to consider the attrition of these projects as a function of manpower, number of early on project supporters/authors, and if a project (like sage) indirectly, through dependency, kept the project alive. And good old fashioned luck. I noted most of them don't use distutils and something custom but less capable instead which maybe plays a roll in how mature/usable/smalltime they where/are. > I agree that any efforts to trying to parsing C++ without building on > an actual compiler are fraught with danger. That's not the case with > generating C++ code, which is the direction we're going. In > particular, our goal is to understand C++ enough to invoke it, which > allows us to be much less pedantic. > I understand and agree with the logic in stating it's a less complicated goal but what comparable success stories exist? I strongly think "devils in the details" in correctly making that work and that they will be tough solvable problems. And then you're going and promising on unfamiliar territory. But what the ultimate takeaway for me is that you won't have it ready in any near term. Do you have the skills and resources to implement this in under 2 years? And then the other question is are you and the team reasonably confident you will have it working and usable by then. Otherwise you are not being pragmatic. On the other hand, if it was reasonably simple as many of your other points in future emails point out, I'd really like to know why you hadn't addressed them earlier. > > A that automatically extract definitions (or even wrappings, even > partially) from C++ headers is another topic, and should almost > certainly lean on an existing compiler. > > >> > -It would allow single source files - I think this is important for > >> > runtime > >> > compiled quasi-JIT/AOC fragments, like OpenCL/PyOpenCL/PyCUDA provide > >> > >> Not quite following what you're saying here. > > > > Maybe PyInline was a better example off the bat for you, but something a > > little more flexible but also with less work is needed. Compare with > > PyOpenCL: > > https://documen.tician.de/pyopencl/ - check out some examples. There > is a > > c runtime api between the contexts hooking things up (this is the OpenCL > > runtime part) - it's a pretty similar story to PyCuda (and by the same > > author, execpt for that project has to jump out to nvcc and cache kernel > > compilation like the inline function implementation does). There's no > limit > > to the number of functions you can declare though and the OpenCL side is > > kept simple - things are generally pretty types
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
On Mon, Aug 22, 2016 at 3:26 PM, Robert Bradshaw wrote: > > To clarify, I'm coming from the case where I > > didn't read the whole tutorial/docs before being faced with pyx in the > > projects I previously mentioned, while on tight turn around time - I was > not > > able to grok in that context. > > Understood--I am short on time too. Though your self-admitted lack of > familiarity doesn't bolster your argument that Cython's doing it > wrong, we need this new feature. > Bare in mind that was then, and while I'm not Cython developer level I do have a better idea of how Cython works now, possibly better than your average user. I've thought about this problem and the state of the overall C++ python binding capability alot as I've had to reevaluate it possibly more than most, and I've used them more deeply than playcode. > > For myself and any other ML user who comes across this thread - can you > list > > a few libraries that do things the right way? > > > > My point was that multifile multi-level wrapper that I mentioned earlier > - > > if you're saying that those projects did Cython extensions wrong, then > I'm > > incorrect at faulting Cython and should fault the libraries using it. I > > didn't say staying close to python caused $blurb. > > > > I don't know in a situation as confusing as to all the binding projects > if > > this should be taken as validation of philosophy either - I think it is > > reasonable to consider the attrition of these projects as a function of > > manpower, number of early on project supporters/authors, and if a project > > (like sage) indirectly, through dependency, kept the project alive. And > > good old fashioned luck. I noted most of them don't use distutils and > > something custom but less capable instead which maybe plays a roll in how > > mature/usable/smalltime they where/are. > > Certainly the success of a project depends on many external factors, > and even raw luck plays a part. But the approach and philosophy taken > to attack a problem and guard its API (and the users/contributors that > such decisions attract or repel) can't be discounted either, > especially when taken over a long timeframe. > > But if anyone wants to believe that Cython's become popular because of > pure luck despite wrongheaded guiding principles or philosophies, > it'll be difficult to persuade them otherwise. > You snidely play with extremes, I never said pure luck was the main factor - I listed several factors of very high significance. Further, Cython branched off of pyrex - why do you think that project failed (you might actually know)? Did your philosophy carry separate the two or was it because you needed things to work (for sage), had a larger set of smart developers and improve it faster than pyrex would allow? I think it's the bustling of life that got Cython where it is, I don't believe it's philosophy in this case - I think it was lack of feature competitiveness and Cython probably worked better (more bugs/cases fixed). > > >> I agree that any efforts to trying to parsing C++ without building on > >> an actual compiler are fraught with danger. That's not the case with > >> generating C++ code, which is the direction we're going. In > >> particular, our goal is to understand C++ enough to invoke it, which > >> allows us to be much less pedantic. > > > > I understand and agree with the logic in stating it's a less complicated > > goal but what comparable success stories exist? I strongly think > "devils in > > the details" in correctly making that work and that they will be tough > > solvable problems. And then you're going and promising on unfamiliar > > territory. But what the ultimate takeaway for me is that you won't have > it > > ready in any near term. Do you have the skills and resources to > implement > > this in under 2 years? And then the other question is are you and the > team > > reasonably confident you will have it working and usable by then. > Otherwise > > you are not being pragmatic. > > > > On the other hand, if it was reasonably simple as many of your other > points > > in future emails point out, I'd really like to know why you hadn't > addressed > > them earlier. > > Other higher priority items for limited resources. And non-type > template args are not necessarily that simple given the way things are > structured now. There's always limited resources and priorities but hen it sounds like it's going to be a very (ever)? long time until everything is working great unless the need is becoming a clear driver or this email thread has reassigned priorities. Do you think you can sketch out a time table for the known issues? Maybe not in this thread but I'd appreciate a back of the envelope calculation - realistic time of usefulness is part of being pragmatic. > > You're missing the point of (3). The fact that we're generating C > code, and not fortran or directly assembly, should mostly be an > implementation detail. It's not realistic to
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
> > > I have another idea/iteration to run by you then. One of your chief > > quibbles, although I don't think it's your underlying one, is Cython must > > understand what's going on. So how about we support a block of C/C++ > code > > as a proper construct. Same name but now, I guess braces maybe get > involved > > (since semicolons do too). Then to transform (mangle) the nested > > identifiers in accordance with scoping/shadowing rules we pull in the > python > > bindings to llvm/Clang to parse that complicated code, work with the AST > (or > > further down the rabbit-hole) appropriately and spit it back out. > Obviously > > you could detect and analyze embedded statements to your hearts content > to > > decide to do something smart about that (you mentioned exception handling > > and return statement as concerning items). > > > > The potential hazards here are that LLVM/Clang is brought in (LLVM is > > already on ~ everybody's linux boxes as a graphics shader dependency) and > > it's [python] api changes somewhat often. I've used it before with > success > > for python driven C++ POD boiler plate (IO, size checks, visitors methods > > etc) autocoding. > > > > If you can understand the underlying C/C++ and get over that Cython will > > always run on a C/C++ compiler in our universe, and make that a feature > to > > embrace, not a detail to hide (who actually benefits in the later case?) > - > > are you still against the significant convenience - and potentially only > way > > to make things work when Cython is not supporting a C++ way of doing > things > > (say things aren't finished/working yet)? > > That would help solve the analysis, though enormous cost in complexity > (one now has two ASTs one must understand and reconcile, and a huge > amount of C++ knowledge must be baked in to understand the AST (or > even lower levels) and it'd be neigh impossible to do "partial > analysis" for features we don't yet understand, probably harder than > putting them into Cython itself modulo parsing) and making LLVM/Clang > a dependency for Cython is probably a non-starter as well. > Well, one thing occurred to me is that leaning on Clang may be the only way you'll be able to remove/improve the DRY violating Cython side declaration of C/C++ land stuff. -Jason ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
Just trying and improve the state of the art. Yea maybe we have to add some tricks to separate the two grammar wise, so they can play together. Besides, I didn't start with that complexity, it evolved into seeing if that was a viable path forward. On Tue, Aug 23, 2016 at 5:15 AM, Alex S. wrote: > Watching this thread for a long time now, and I must say I absolutely love > how someone just barges in «oh just add parsing of C++ AST». > C++ is a language with an extremely complex context-dependent grammar, > much more so than C. Not to mention they took to updating the standard with > new awesome features every 3 or 4 years, which all seem to absolutely need > their own syntactic support. > > 23 авг. 2016 г., в 8:03, Robert Bradshaw > написал(а): > > > > On Mon, Aug 22, 2016 at 9:44 PM, Robert Bradshaw > wrote: > > > >> And it would be a step back > >> for the nice auto-conversion facilities you care about, e.g. > >> > >>py_func(c_func(py_value)) > >> > >> would become > >> > >>c_value = py_value > >>cdef some_type c_ret > >>inline_cpp "c_ret = c_func(c_value)" > >>py_func(c_ret) > >> > >> It's just choosing a smaller unit (line vs. file) to swap between > languages. > > > > And on this note it would also encourage use of the Python/C API (over > > swapping "back" to Python) which is often a dangerous step backwards. > > ___ > > cython-devel mailing list > > cython-devel@python.org > > https://mail.python.org/mailman/listinfo/cython-devel > > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
