We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Cython and the Limited API

00:00

Formal Metadata

Title
Cython and the Limited API
Title of Series
Number of Parts
131
Author
Contributors
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Cython's Limited API support is finally approaching a usable state. As an example, it is possible to produce a working version of Cython by compiling it in Limited API mode. For users the main advantage is to be able to reduce the number of wheels/binaries they have to build in order to be compatible across a range of versions of Python. For Cython itself there is also an advantage in future-proofing: being able to produce simpler code that should continue to work even as the Python interpreter evolves and which is more likely to work with alternative Python implementations, as well as hopefully placating the unease some of the core Python developers have at Cython's use of Python internals (in non-limited API mode). This talk will start off by looking at the subject from the users' perspective: * Why you might want to use the Limited API (from Cython). * What kind of projects are likely to benefit from it (as far as it's ever possible to predict how people will use a tool...). * What you actually need to do to build a Cython module with the Limited API. * What the limitations and disadvantages are: there are some features that don't work, some features that only work in recent versions of Python, some speed costs, and complete forward-compatibility might not be all you hope it would be. When that "general interest" section is done, I plan to talk about some of the gory implementation details - what "creative" solutions have been employed to work around missing features or things the Limited API was never intended to do.
Receiver operating characteristicComputer fontHand fanFreewarePersonal digital assistantCodeModule (mathematics)Extension (kinesiology)Fluid staticsOperations researchModul <Datentyp>SubsetFunction (mathematics)Data structureSource codeProof theoryPauli exclusion principleComputer fileAttribute grammarRAIDSocial classInheritance (object-oriented programming)Regulärer Ausdruck <Textverarbeitung>Revision controlComputer fontType theoryCircleKeyboard shortcutLibrary (computing)Normal (geometry)Greatest elementOperator (mathematics)QuicksortMeta elementFacebookInformationLimit (category theory)Web pageExtension (kinesiology)Context awarenessInteractive televisionProjective planeCASE <Informatik>View (database)DiagramNumeral (linguistics)Interpreter (computing)CompilerGoodness of fitModule (mathematics)Module (mathematics)Set (mathematics)Point (geometry)Suite (music)Functional (mathematics)CodeSoftware developerBitCovering spaceMereologySoftware testingComputer programmingSlide ruleMultiplication signReal numberPosition operatorLine (geometry)Moment of inertiaState of matterSheaf (mathematics)Formal languageElectronic mailing listCore dumpChannel capacityBranch (computer science)Open sourceLevel (video gaming)Data compressionCommunications protocolBuffer solutionArray data structureProgrammschleifeFluid staticsPauli exclusion principleComputer animationLecture/Conference
Fluid staticsInheritance (object-oriented programming)Social classRegulärer Ausdruck <Textverarbeitung>Revision controlState diagramDistribution (mathematics)Computing platformExtension (kinesiology)Modul <Datentyp>Binary fileCodeData conversionAxiom of choiceStatisticsReduction of orderSoftware testingSoftware developerAsynchronous Transfer ModeChainCoroutineElectric generatorKeyboard shortcutModule (mathematics)Object-oriented programmingStrutRead-only memoryView (database)Type theoryPauli exclusion principleObject (grammar)OvalFunction (mathematics)Complex (psychology)Real numberCategory of beingMagneto-optical driveSoftware developerAsynchronous Transfer ModeOrder (biology)Social classLimit (category theory)Object (grammar)Line (geometry)Type theoryInteractive televisionQuicksortFluid staticsMultiplication signSoftware bugMathematicsSemiconductor memoryElectronic mailing listPoint (geometry)String (computer science)Revision controlExtension (kinesiology)Software testingElectric generatorNormal (geometry)CoroutineMathematical optimizationBitCodeDifferent (Kate Ryan album)Regular graphTraffic reportingMemory managementProjective planeFrictionTerm (mathematics)BuildingComputer clusterModule (mathematics)Computer programmingCASE <Informatik>Module (mathematics)Wrapper (data mining)Inheritance (object-oriented programming)Distribution (mathematics)Combinational logicInterpreter (computing)Parameter (computer programming)Online helpRight angleNeuroinformatikExistential quantificationExpressionFrame problemView (database)Numbering schemeComputing platformComplex (psychology)ChainFunctional (mathematics)Slide ruleLevel (video gaming)Goodness of fitSpherical capMessage passingComputer animation
PiComplex (psychology)Category of beingFunction (mathematics)OvalType theoryReal numberMeasurementOrdinary differential equationRegular graphNumbering schemeInstallation artTotal S.A.Normal (geometry)Run time (program lifecycle phase)Revision controlLatent heatMacro (computer science)CodeConstructor (object-oriented programming)CompilerRead-only memoryView (database)Vector spaceExtension (kinesiology)BuildingLibrary (computing)IBM Systems Application ArchitectureModule (mathematics)Web pageHand fanCompilation albumLevel (video gaming)Fundamental theorem of algebraException handlingDemo (music)Computer fileSuccessive over-relaxationModule (mathematics)Cache (computing)ExplosionDefault (computer science)Software testingPoint (geometry)Standard deviationCodeSoftware developerRevision controlComputer fileInteractive televisionLimit (category theory)BitCASE <Informatik>Maxima and minimaSystem callBranch (computer science)Slide ruleSoftware bugView (database)2 (number)Frame problemQuicksortObject (grammar)Module (mathematics)Poisson-KlammerArithmetic progressionMessage passingDifferent (Kate Ryan album)Multiplication signMacro (computer science)Run time (program lifecycle phase)Semiconductor memoryRight angleLine (geometry)Tracing (software)Functional (mathematics)State observerArithmetic meanTable (information)Regular graphLibrary (computing)Parameter (computer programming)Exponential functionArray data structureCategory of beingGraph (mathematics)Overhead (computing)Mathematical optimizationBuildingSpherical capSoftware testingCartesian coordinate systemNumbering schemeDimensional analysisException handlingDefault (computer science)Traffic reportingSuite (music)Type theoryMathematicsVector spaceNormal (geometry)CuboidSet (mathematics)MeasurementWrapper (data mining)Electronic mailing listComputer animation
Object-oriented programmingOrdinary differential equationCodeModule (mathematics)Extension (kinesiology)Computer virusNumbering schemeLimit (category theory)HexagonPlanningCASE <Informatik>Revision controlLecture/ConferenceComputer animation
Different (Kate Ryan album)Limit (category theory)Projective planeReal numberMathematicsVapor barrierImplementationTangentLecture/Conference
Graphics tabletFunctional (mathematics)Keyboard shortcutSocial classBitMultiplication signRight angleReal numberLecture/Conference
Module (mathematics)Keyboard shortcutFibonacci numberFunctional (mathematics)Real numberMultiplication signCodeLecture/ConferenceComputer animation
Lecture/ConferenceComputer animation
Transcript: English(auto-generated)
Hello, and thanks all for coming. I guess I'll start with an outline of what I'm going to tell you. I'm going to, I guess, tell you what Cython is and what the limited API is. So I guess we're all on the same page. I'm going to give you a bit of a background of, I guess,
how we ended up at the position we are now. And I'll tell you what are the benefits of using Cython with the limited API, but also what are the sort of limitations and what's the performance. Then, I guess, there's about three or four slides of actually useful information that you can practically use about how you use it. And then at the end, I've kind of just
got an unlimited amount of obscure technical details. And this is the stuff that interests me but doesn't interest, I guess, the rest of you because you guys don't come to a Python conference to hear about sort of C and low-level C code. So I'll cover as much of that as I can and try to leave time for questions. But we may not get through all the technical details.
So the first thing is, what is Cython? And I guess we start with it's in sort of open source project, and it's one that I've been involved with for about sort of five years now. So I'm talking in that capacity. It generates C code, and that can be compiled into an extension module.
So you write Python-like code. So it should all feel very familiar with you, and you end up with fairly optimized C code. And there's a whole list of use cases. You can use it to wrap sort of external C or C++ library, so as a language binding. You can speed up your Python code either just by compiling it or by adding static typing,
so specifying the types of things to either be a fixed Python type or a fixed C type. And you can really speed up operations on things that have the buffer protocol. So NumPy arrays are a classic example. You can iterate across them very, very quickly, and that lets you do things like loops
over arrays, which are really quite slow in pure Python. And so the little sort of line drawing up there is what I consider the sort of the main nice feature about it, that your sort of normal language binding, the interpreter and the sort of the non-interpreter layer are kind of fixed, whereas in Cython,
you can have the interpreter sort of the compiled, non-compiled layer actually quite high level above your sort of Python-like code and your C-like code, so you can write quick Python-like code. And even if you don't use it yourself, it's used in a lot of low-level numeric libraries, so you use it accidentally, most likely.
So yeah, it's kind of important in the ecosystem even if you choose not to use it yourself. So what is the limited API is the sort of next question. And the limited API is for writing extension modules. So this is compiled modules that interact with Python
and you can call from Python. And so in this context, I'm talking about you're not using the limited API, Cython's using the limited API, and you're getting the benefits of it. And I've drawn this kind of blobby diagram here that Python has a sort of fairly extended C API.
So the limited API is this little red circle sort of at the bottom left, which contains a few functions. And then you've got the public API, which is quite large, quite extensive, some of it sort of historical. You've got a sort of new feature, the PyUnstable API,
which is sat just on the edge of the public API, that it is documented, but they warn you they're going to change it at a rapid pace. And you've got the underscore PyAPI. So anything that starts with an underscore, the Python core developers get slightly upset when you use, but all the good stuff's hidden there.
So there's a kind of trade-off. And I guess it then relates to the stable ABI. So ABI isn't something that, as a Python developer, you usually have to think about. But the API, so P is, I think, programming,
is kind of the text you write. So in this case, the C code you write is what defines the API, whereas the ABI is the interaction with the compiled program. So the way I like to think about it is the limited API is kind of a restriction. So you're saying you have to only use this small set of functions and ignore all the good stuff.
But the benefit you get is from the stable ABI. And what the stable ABI says is that your extension modules will keep working into the future without recompilation. So you can compile an extension module on Python 3.7, and it will keep working on 3.15,
and that's kind of the promise behind it. So it kind of can only be expanded, whereas the limited API can be evolved and deprecated slowly. I don't think a lot's been removed from it, but the binary side of it will stay. And so from the limited API point of view, your source code is likely to continue
working into the future. But it's not absolutely guaranteed. Historically, it was introduced in PEP 384. I think it made it into Python 3.2. I guess in my personal opinion, it became usable about Python 3.7. But that's opinionated.
You can agree or disagree. So I guess the history of the limited API in Cython. The first commit, which I only found out about when I kind of actually started preparing this talk, was back in 2012 by Bradley Froehler. And I'm going to mispronounce a few people's names
in this section. So if these people ever end up watching it, I apologize. And he was just interested in one very small feature. So he'd got a small handwritten module, and he wanted it to be limited API compatible. So it didn't cover a lot, but that was the first commit that kind of referenced it back in 2012.
So you can tell I'm giving you the latest up-to-date information here. The first real work was done in 2019, mostly by Eddie Elizondo at Facebook or Meta. And that's the kind of large commit, 700 lines or so. And that provides a lot of the infrastructure that we use.
It also adds static module state, which is tangential to this talk, but is another kind of ongoing project to complete. So they contributed a bunch of stuff from their internal work. I don't think they contributed all of it, probably just due
to, I guess, inertia and lack of time. But this did a good chunk of the proprietary work, but it wasn't actually in a position where you could compile against the limited API. And that is basically what made it into the Cython 3.0 release. So we released Cython 3.0 in July last year,
so about a year ago. And I guess sooner or later, people tried to use this limited API work and found it didn't work and predictably kind of complained about it, which we kind of knew it didn't work. So in August that year, I did a bit more work.
So I fixed it so there was one minimal module that worked. You could compile one thing. This Fibonacci program would work in the limited API, nothing else but this one thing. And so I added this one test, which is part of our test
suite, has been expanded a bit and kind of enforces that it does actually now work. And I guess the situation today, so almost all of the improvements are going into the upcoming Cython 3.1 release. So if you want to use the stuff I'm telling you here, for now you've got to use the development branch rather
than a release branch. Hopefully that release isn't too far off, but I don't control the button to release it, so I can't kind of promise you anything. And I guess as an example of it, it's basically working. It can compile a working version of itself. So Cython doesn't need to be compiled, but we choose to compile it for speed mainly.
And I guess it's fairly basic, and I'm listing the features here just because they kind of tell you what kind of Python code should compile successfully in the Cython limited API. So you've got things like static methods, class methods. You've got one generator expression. So we're not the most modern thing ever.
List comprehensions, super classes. It's not particularly strongly typed, and it isn't particularly modern. It was targeting Python 2 until kind of last year-ish. And I guess it can also, the other project that's been kind of driving adoption of it and sort of nagging you to fix things is this NVIDIA's RAPIDS AI.
So Vyas there has been, I guess, doing a lot of helpful bug reports and reporting back. And I think at least the Cython bit of theirs has basically let them switch to it. So that's kind of the history. Why might you want to use it? So I guess in this slide, I'm going to talk about SciPy, and I'm just going to put the disclaimer in now.
I'm using it as an example because it's an easy example of a module you'll all know. I have no reason to believe they plan to switch to the limited API. It's just an example. So the main reason that, as a user, you care about it is because it reduces the size you have to distribute and the size you have to compile. So they've got 73 Cython extension modules,
at least at the point I wrote this talk. And that takes up 33 megabytes, and that's per platform, per Python version. And what the limited API lets you do is remove the per Python version. So they could, in principle, compile sort of one thing
for Python 3.8 upwards. And that, I guess, reduces their build time and reduces a number of other things. I mean, they've noticed this problem. I found that in their roadmap. So they complain that the binary size is built from Cython code are large, and compile times are long,
and this makes them unhappy. And so they want to combine extension modules and limit the use of Cython, which we don't want them to feel they have to limit the use of Cython. So the main argument for why you want to do this is that mainly reducing binary size to distribute and time spent building modules and that kind of thing.
And that's the benefit that you're getting from the limited API. The things I don't buy so much are reduced testing time. So you could say, because it's one extension module that works, and all future versions of Python, I'm going to test it once. And I think that would be a mistake. So don't take that away as a message. And then future compatibility, we'll see.
I'll talk a bit more about that later. That's a bit more up in the air, but it helps. So why do Cython developers want to do this? And one of the reasons is obviously that users want this. People come to us and ask us to do it. So that's a fairly good reason. One of them is this idea of future compatibility.
And so if Cython's fairly low down in the dependency chain, so what tends to happen as a new Python release gets prepared, Cython will break because something's got changed. And that's fine. But what that means is that until we fix it, NumPy doesn't work, and SciPy doesn't work, and all these other fairly low-level things
that people want to get on and test. And so this causes a certain amount of friction because the C Python developers do want to remove their private APIs. They want to be able to change things to improve things and make everything work better. And so if Cython gets broken, they don't enjoy this.
But the other side is we actually want to use the low-level private APIs for speed. We kind of want to hack with the internals and try to do things fast. So what we're viewing limited API as is a kind of compatibility fallback mode. So some people will want to use it
because it gives them benefits, but it also kind of gives the benefit that Cython has a mode that will keep working into the future, even if it stops being maintained or tricky changes are made or that kind of thing. So that's kind of the way that I'm looking at it,
that having this fallback mode also reduces, I guess, some of the friction there. So in terms of what doesn't work, I mean, there's lots of little bits, like generators and coroutines and async stuff is hard. There's this obscure thing with class method that you really don't need to care about. Module cleanup is hard.
So one of the differences in normal API versus limited API is that classes are now heap types, and that means they get kind of cleaned up as the module gets destructed. And actually doing that all in the right order turns out to be pretty hard because you can end up with situations where your destructors are calling something
that's already been destructed and it all ends up a bit crashy. So that's a potential issue at the end of the program. And the other thing is we're gradually working our way through all the optimizations. So the pure Python stuff works pretty well. But what you typically find is that when you start typing things a bit more,
so things like the string ends with function, just as an example, we've got an optimized version of it, and we've only sort of recently looked at it in the limited API. So where Cython knows it's a string and knows it's called ends with, it tries to do something clever. And that kind of thing, we're just going through gradually and it may catch you out. And the lesson is report a bug when it catches you out.
Types memory views, they do work, but they don't before Python 3.11. And that's just a restriction of what's in the limited API. So that's the main feature that suddenly starts working. But there's a few of these things where we can only do this from certain points.
Inheritance from built-in types, there's a way to fix it, but it's quite a big code change. And that's essentially what we're saying is that the C code that we generate here on your right, we need to know the size of the list object and that's invisible in the limited API. And there are ways around it,
but it's gonna be work they haven't been done yet. So that's a fairly big feature that won't necessarily work. Things like profiling and line tracing, things that kind of interact with the interpreter on a sort of fairly low level, that involves creating code objects and frames. And my view is that this will probably
actually never work in the limited API. And actually that's kind of fine. You know, the people that want to do this distributing something to be built with profiling, they're doing it locally on their computer and they can use the sort of regular build mode.
And then the other thing that doesn't work right now is we've got this C import C Python thing, which gives you access to the Python C API yourself. This requires some changes. I mean, the code I've shown on here on the right is how we wrap complex. So the complex object,
and that gives you fast access to real and imaginary. But it gives you fast access in a way that requires the type not to be opaque. So it requires detailed information that isn't exposed in the limited API. That's not necessarily a big restriction. I mean, you clearly can't use our wrappers
to use bits of the limited API, bits that don't feature in the limited API. And so, yeah, this is mostly gonna be a case that we're just gonna have to disable some of this stuff on the limited API. But the one thing I want to say here is that these wrappers aren't actually special. We don't use any tricks that you can't do yourself.
So if they don't work right now, copy and paste from our files, take the stuff that does work, and it's fine. It's not magic. And I guess the final point here is that we've got some very low-level hacky interaction with the array array module, and that, again, people use it, but it's not gonna work in the limited API.
Sorry, it just isn't. So performance, what's the performance like? So to measure this, I've used Python 3.12. I've built Cython itself with the limited API, and I'm measuring it, and I'm compiling this big exprnodes.py,
and that file's like 15,000 lines or something, so it's ridiculous. So it takes a while to compile. And the first thing to note is that if we look at the size of the compiled Cython, it's actually slightly smaller in the limited API. You know, it's maybe like a quarter smaller or something like that.
That wasn't intentional. It was just in a kind of interesting observation while I did it. And so the bottom line of the table's more interesting, so the time to process this Cython file. So in pure Python, it takes about 10 seconds. If you build Cython normally, it takes six seconds, so we get a decent speed up. If you build it in the 3.7 limited API,
it takes 11.3 seconds, so it's actually a pessimization. You're better off just not compiling Cython. And if you build it in the limited API 3.12 version, then it's a bit quicker, so it's 10.4 seconds. And the difference there is that it can use vector call,
which is a sort of C method of calling Python functions quickly. Again, it's fairly transparent to you as a user, but it makes a genuine speed improvement. And then in brackets below, I've got a work-in-progress fix. So the slide's obviously a bit up in the air. I was preparing this slide. I saw that it was a pessimization,
and I went and there was, I guess, a mistake, an optimization that we always missed. So in principle, we can just about bring it into being an optimization again. But I guess the lesson here is that if you're using Cython just to compile some sort of regular Python code,
it may not give you a lot of speed up. So maybe don't do that. On the other hand, things like memory views. So memory views are your sort of faster access. What you find is that there's a bit of the overhead for the function calls.
So this graph is array size versus time per call per array element. And you find that they're basically the same for large arrays. So if you're doing things like your main work is calling an external C library, or your main work is working with memory views, the limited API doesn't make that much difference.
So use it. You know, it won't cost you a lot. It will cost you a tiny bit per function call. So I guess I'm gonna sort of skip over this a little bit, but there's various things that subtle runtime changes.
So this pytype get slot does different things in 310 and above versus 310 below. So what this means is that I guess the idea that you compile once and it works anywhere, I guess is a bit risky. And a lot of the time we're replacing private C API with private Python API, specifically for code objects.
So again, you know, it's not necessarily future-proofed into the future. And I guess the key takeaway from this slide is this thing on the, this table on the right, this idea that you've got a whole new dimension. So we only test the green line to down the middle, the idea that you compile it on API 310
and run it on API 310, but we don't test compile it on API 310, run it on API 311. And then you've got a third axis of what you build it on. So there's actually quite a bit of unknowns here that it may not quite live up to its promise. How do you use it? This is the important bit that I actually wanna get through.
Cython to C as normal. So you don't do anything different there. The Cython doesn't need to be told it's using the limited API. It generates the same code. And then you set a couple of macros and the two macros you need to set are Cython limited API. You just need to define that to one to tell it it's using the limited API and a PI limited API version.
So in this case, the interesting versions are 3.7, the kind of minimum, 3.11 where memory views get used, introduced and 3.12, which is vector call, which isn't a new feature, but makes everything faster. And the final thing is you name your compiled file this. So the old setup tools way of doing it,
I've just highlighted the difference here. So you're defining the, this may not be the recommended way to build things, but it's kind of the way our documentation uses. I've highlighted the difference. You're defining these two macros and you've got PI limited API equals two, and that's all you need to do. And hopefully it magically works. So the PI limited API does the renaming of the file.
If you wanna use scikit build, which is a bit more modern, then the work is done in CMake. And I get paid to be a C++ developer and I hate CMake. Thank you. And so, but here you've got a target compile definitions and then you've got the set target properties and that the set target properties changes the file name.
So again, the box in blue is the only deviation you make from your regular build. And the final example I wanted was Maison. And again, you've got, you can hear the, you've got the limited API, which actually covers both the PI limited API macro
and the renaming the file. And so you only need to just add this extra argument to do this extra definition. So I'm just gonna do, I think I've got the time really for one, maybe two of these gory detail slides. So the main, the difference is only at C compile time. So we've got a bunch of these feature macros.
So we've got like assume safe macros, assume safe size, and these mean that we can use these PI list set item macros. And it's really just a bunch of these fairly tedious defines which we replace. And I guess the other thing, I'll just talk about this before I finish, is exceptions and tracebacks.
And these are, I guess, pretty fundamental that we wanna show nice tracebacks, but they involve adding frame objects. And so what we do is this horrendous hack, and I was quite pleased when I came up with this hack, so I do wanna show you it. We call the Python function sys get frame. We call code replace to put the line numbers and names on.
And then we evaluate this code. And that essentially gives us the frame object which we can add to a traceback. So that is, I guess, a hacky way of, I'll stop very soon, thank you. That's a hacky way of kind of adding the traceback. I'll skip over the rest of the gory details. The slides are online. So the message is, start using it in Cython
if it suits you. Use the master branch for now. Report bugs, please. It probably won't be the default. The next step in Cython is to start slowly enabling tests. And I guess my view is the limited API should stay limited, mainly so that people aren't tempted to break the promise of the stable API, which is ABI, which is what you want.
I'll finish there and try to take questions. So we now have five minutes for questions. And you can find microphones in the center of the two hallways in the main hall if anyone wants to come up and ask something.
Hello. Hi. So can you scroll to maybe the mason example or some of the others if it's easy for you? The mason one. Yeah, yeah. So it seems that mason has a support for the limited API because this doesn't have the hexa number and stuff like that.
Is there a reason we need an extra Cython limited API define? Or could we just look if that limited API hex version is defined, we'll assume this one? Yeah, I think that's the plan. It was a case of kind of introducing it gradually and trying to test things when it doesn't quite work.
But yeah, I agree. It's pretty unnecessary. Yeah, hi. Real nice work. I wanted to ask, I saw some projects like HPIE, I think. So basically, target broader API for different implementations of Python.
Like PyPy and maybe some others. Does this bring it any closer? Or is it just still strictly C Python thing? It's tangential. So PyPy, Cython actually supports PyPy pretty well. As does Graal Python. I had a quick chat with a guy doing a talk about it
yesterday. So we do support these things because they support the C Python API. I believe some work's been done on HPIE, like preparatory work. But it's largely only visible to the HPIE people. I was kind of hoping to run into some of them here and then to tell me about it. But that hasn't happened yet.
But yeah, I mean, we have a broad ambition to support HPIE. But we've got literally nothing merged. OK, so this is just tangentially related. Not really, not exactly the same thing. Yeah, yeah. I mean, the limited API stuff should be more compatible. It should be easier for PyPy and other things to support.
But it's not strictly necessary for PyPy support. I see. Thanks. Thank you. Thank you. I think I have spoken to you. But I'll try to talk about HPIE. Thank you. Thank you for your talk. And thank you for all your work on the limited C API.
I would like to know if you consider funding to finish the work on the limited C API, because it seems like there are still a few things to do. I mean, the things to do are kind of increasingly small. The barrier is mainly just a lot of small changes
that have to be reviewed. So it doesn't feel to me like there's that much work. It's just slowly getting it all merged, I think, if you see your take. OK. Thank you.
Do we have any more questions? OK. I have a question for you, since we still have a little bit more time. I was wondering about these function decorators I saw in your examples. Sorry. Where should I go? So when you were writing the Cython.
Yes, so for example, Cython.binding, false. What are these function decorators, and why should I use them? Right. So Cython now generates this scifunction class, which is a kind of better-compiled function. It provides you with extra introspection. So it looks a lot more like a real Python function.
At the time I wrote this, that didn't work. So at this very early commit, you had to turn it off. Mostly, now it works. So mostly, you shouldn't use this decorator. It's making your code worse for users. But at the time, it was a way to get something small to work.
Awesome, thank you. So if there's no more questions, we will be ending here. And we have five minutes to change rooms. And we will be continuing at 11.20 with Victor Steiner's talk about moving the ecosystem to a stable API. Thank you, David. Thank you. Thank you.