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

Extending Python, what is the best option for me?

00:00

Formal Metadata

Title
Extending Python, what is the best option for me?
Title of Series
Part Number
60
Number of Parts
119
Author
License
CC Attribution 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 purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language
Production PlaceBerlin

Content Metadata

Subject Area
Genre
Abstract
Francisco Fernández Castaño - Extending Python, what is the best option for me? Python is a great language, but there are occasions where we need access to low level operations or connect with some database driver written in C. With the FFI(Foreign function interface) we can connect Python with other languages like C, C++ and even the new Rust. There are some alternatives to achieve this goal, Native Extensions, Ctypes and CFFI. I'll compare this three ways of extending Python. ----- In this talk we will explore all the alternatives in cpython ecosystem to load external libraries. In first place we'll study the principles and how shared libraries work. After that we will look into the internals of CPython to understand how extensions work and how modules are loaded. Then we will study the main three alternatives to extend CPython: Native Extensions, Ctypes and CFFI and how to automate the process. Furthermore we will take a look to other python implementations and how we can extend it.
Keywords
80
Thumbnail
25:14
107
Thumbnail
24:35
CodeGoogolComputer configurationBerlin (carriage)Different (Kate Ryan album)Computer animation
Group actionSoftware engineeringData managementMaxima and minimaStandard deviationSocial classProcess (computing)Endliche ModelltheorieLecture/Conference
Extension (kinesiology)Metropolitan area networkBitPlanningFormal languageRepresentation (politics)Computer fileLibrary (computing)Extension (kinesiology)Computer animation
Metropolitan area networkSample (statistics)SummierbarkeitMultiplication signQuicksortPhysical systemLibrary (computing)Gastropod shellImplementationFamilyMechanism designWindowMiniDiscLecture/ConferenceComputer animation
Metropolitan area networkSemiconductor memoryFormal languagePointer (computer programming)Point (geometry)Computer animationLecture/Conference
CodeCalculationLibrary (computing)Physical systemProduct (business)Computer programmingMultiplication signMereologyDecision theoryWritingMechanism designCodeGoodness of fitComputer animation
Ocean currentDigital electronicsMechanism designLevel (video gaming)WritingInterpreter (computing)Computer programmingExtension (kinesiology)Library (computing)INTEGRALLecture/Conference
Single-precision floating-point formatRead-only memoryCodeBinary codeLibrary (computing)Sound effectDifferent (Kate Ryan album)Fluid staticsDeclarative programmingWage labourObject (grammar)Variable (mathematics)Computer fileStructural loadLink (knot theory)Semiconductor memoryContext awarenessInformationComputer programmingMechanism designExtension (kinesiology)Type theoryPhysical systemOperating systemLinker (computing)Interpreter (computing)Multiplication signComputer animationLecture/Conference
Extension (kinesiology)Wage labourSimilarity (geometry)Semiconductor memoryMultiplication signRun time (program lifecycle phase)Mechanism designLibrary (computing)Set (mathematics)Electronic mailing listFunctional (mathematics)Macro (computer science)Extension (kinesiology)Lecture/ConferenceComputer animation
Extension (kinesiology)Metropolitan area networkRun time (program lifecycle phase)FluxExtension (kinesiology)NumberAdditionCodeLecture/ConferenceComputer animation
Extension (kinesiology)Module (mathematics)Function (mathematics)StatisticsModulo (jargon)Meta elementFunctional (mathematics)Suspension (chemistry)Endliche ModelltheorieMultiplication signExtension (kinesiology)Module (mathematics)Fluid staticsComputer animation
Module (mathematics)Modulo (jargon)StatisticsMeta elementSuite (music)Table (information)Ring (mathematics)Function (mathematics)Core dumpExt functorExtension (kinesiology)Point (geometry)Functional (mathematics)CodeComputer fileInstance (computer science)Variable (mathematics)Parameter (computer programming)Multiplication signNumberArithmetic meanHypermediaPhysical systemEndliche ModelltheorieLibrary (computing)Event horizonChemical equationNoise (electronics)Software developerIndependence (probability theory)WordForcing (mathematics)Right angleImplementationComputing platformResultantModule (mathematics)Pointer (computer programming)Macro (computer science)Social classAdditionExtension (kinesiology)Object (grammar)Compilation albumString (computer science)Electronic signatureElectronic mailing listLecture/ConferenceComputer animation
Structural loadAsynchronous Transfer ModeLink (knot theory)Set (mathematics)Function (mathematics)Module (mathematics)Total S.A.Memory managementLevel (video gaming)BitSystem callModule (mathematics)Physical systemMultiplication signCellular automatonWindowFunctional (mathematics)Symbol tableCASE <Informatik>Extension (kinesiology)Computer fileSemiconductor memoryLibrary (computing)NumberData dictionaryStructural loadVideo gameEndliche ModelltheorieForm (programming)Volume (thermodynamics)Personal digital assistantIncidence algebraSampling (statistics)Buffer solutionTerm (mathematics)Lecture/ConferenceComputer animation
Memory managementRight angleObject (grammar)Macro (computer science)Cycle (graph theory)Semiconductor memoryAlgorithmSpeicherbereinigungLeakLecture/ConferenceComputer animation
Metropolitan area networkPointer (computer programming)Data managementTotal S.A.Ring (mathematics)Set (mathematics)Module (mathematics)SummierbarkeitSystem callType theoryLogical constantCycle (graph theory)Cellular automatonDirection (geometry)Arithmetic meanSpeicherbereinigungType theorySemantics (computer science)Functional (mathematics)Point (geometry)Independence (probability theory)Endliche ModelltheorieInformationBuildingDifferent (Kate Ryan album)Interface (computing)MultiplicationData structureInterpreter (computing)Parameter (computer programming)Population densityException handlingSpacetimeSystem callExtension (kinesiology)Pointer (computer programming)Library (computing)CodeModule (mathematics)Error messageLecture/ConferenceComputer animation
Data Encryption StandardMetropolitan area networkType theoryBinary fileElectronic mailing listType theoryMechanism designTheory of relativityFlagData typeObject (grammar)Data structureIntegerLecture/ConferenceComputer animation
Social classPoint (geometry)Type theoryCodeLevel (video gaming)Function (mathematics)Type theoryData structureSystem callAlgorithmDifferent (Kate Ryan album)Field (computer science)Library (computing)ImplementationRecursionCodeComputer animation
Gamma functionType theoryImplementationAlgorithmFunctional (mathematics)Fibonacci numberLibrary (computing)Open setWrapper (data mining)Semiconductor memorySatelliteLevel (video gaming)Figurate numberField (computer science)Type theoryPoint (geometry)Lecture/ConferenceComputer animation
Data Encryption StandardProgrammschleifeType theoryLoop (music)Metropolitan area networkImplementationIntegerType theoryCasting (performing arts)Multiplication signParameter (computer programming)Right angleTask (computing)Point (geometry)Different (Kate Ryan album)CodeMechanism designLecture/ConferenceComputer animation
CodeMathematical singularityType theoryFamilySampling (statistics)Instance (computer science)CodeLecture/ConferenceComputer animation
Metropolitan area networkFunction (mathematics)Real numberType theoryData Encryption StandardUniform boundedness principleMagneto-optical driveBinary fileDiscrete element methodMedianPointer (computer programming)StatisticsCurvatureAsynchronous Transfer ModeSystem callMathematicsFunctional (mathematics)Type theoryInterface (computing)Dimensional analysisResultantMechanism designCellular automatonPointer (computer programming)Real numberDampingLibrary (computing)Arithmetic meanSymbol tableElectronic mailing listParameter (computer programming)Extension (kinesiology)Content (media)System callLevel (video gaming)Different (Kate Ryan album)CASE <Informatik>Multiplication signDivisorReal-time operating systemQuantumInferenceDataflowLocal ringNumberStructural loadPoint (geometry)Set (mathematics)SpacetimeElement (mathematics)Right angleSound effectSatelliteForm (programming)Lecture/ConferenceComputer animation
Type theoryFile formatData typeCompilerLetterpress printingCASE <Informatik>Multiplication signMaxima and minimaSequelFunctional (mathematics)Formal languageEllipseDifferent (Kate Ryan album)Software developerExtension (kinesiology)Parameter (computer programming)Point (geometry)Pointer (computer programming)Open setFrictionAuthorizationLibrary (computing)File formatElectronic signatureType theoryLecture/ConferenceComputer animation
Different (Kate Ryan album)Water vaporEndliche ModelltheorieType theoryVariable (mathematics)CodeCASE <Informatik>Integrated development environmentLevel (video gaming)Lecture/Conference
Level (video gaming)IntegerComputer fileLine (geometry)System callBoom (sailing)Point (geometry)CurvatureSocial classPointer (computer programming)Type theoryCodePoint (geometry)Functional (mathematics)Semiconductor memoryTypprüfungLibrary (computing)Mixed realityCompilation albumBitCellular automatonData structureSource codeRegular graphIntegerAlgorithmCASE <Informatik>Structural loadFormal verificationFibonacci numberElectronic signatureMultiplicationBasis <Mathematik>Similarity (geometry)AreaCausalityLevel (video gaming)Field (computer science)Computer fileSoftware developerRight angleControl flowRecursionSequenceMetropolitan area networkComputer animation
Hausdorff spaceStructural loadData typePortable communications deviceFrame problemCodeMultiplication signMechanism designSemiconductor memorySpherical capLibrary (computing)CASE <Informatik>Extension (kinesiology)Object (grammar)Data storage deviceGastropod shellLecture/ConferenceComputer animation
Metropolitan area networkCASE <Informatik>Different (Kate Ryan album)Library (computing)Category of beingPortable communications deviceContext awarenessCausalityMoment (mathematics)Type theoryPhysical systemExtension (kinesiology)Sound effectCodeBitSystem callRevision controlLecture/Conference
Metropolitan area networkInclusion mapData typeLibrary (computing)Extension (kinesiology)CodeMultiplication signStandard deviationContext awarenessComputer configurationData conversionWhiteboardPhysical systemProjective planeLine (geometry)Open setMedical imagingSet (mathematics)Computer animationLecture/Conference
Googol
Transcript: English(auto-generated)
Hello everybody, let's welcome Francesco, who came the long way from Madrid to present
this talk about different approaches of extending Python. Thank you. Hello, can you hear me? I'm Francesco Fernandez, I'm from Madrid, I work as a software engineer in vCode,
it's a startup, we are working in creating a dependency manager for C++, I also run the C++ user group in Madrid, and also Neo4j user group there, I'm very glad to be here, thank you for coming, and today I'm going to talk about extending Python, the different approaches that we have to extend Python.
Here's the roadmap, in the first place I will talk about the motivation, why we have to write in other languages, then I'll explain some basic concepts that we have to know to understand how this extension works, then I'll explain a bit about native extension that C Python gives us, then I'll explain a bit about C types, then about
CFFI, that is an external library, and finally I'll explain to you my personal thoughts about the different approaches. I would like to warn you that there is a huge topic, there is a lot of things to explain, there is a lot of things to study, there is a lot of tiny details, every system,
operating system treats shell libraries in one way or another, so time is what it is, so this talk is intended to be an introduction to this topic, so I'll try to explain the basic concepts. Probably the examples that I will give you there will be useless, but I want to
explain to you the basic concept, if you have to apply these mechanisms in the future, you will have the tools, so this is my intention here, and I also am a new user, so I don't have the chance to test my examples in Windows, so I don't know if they work or not,
and I've used mainly the C Python implementation to test all my disk code, so okay. What is the motivation, why should we care about writing C or even other languages like Fortran, why should we want to call these languages from Python, in C we have to deal
with memory, we have to treat with some things like pointers that could be hard to treat with, why should we care about writing in C? Well I think that there are mainly three reasons, in first place we have the speed,
probably we have some Python program that has a bottleneck in some parts, let's say that it has some part that has a very intensive calculation that takes a lot of time, probably we want to write this chunk of code into C, so we will improve our performance.
Other reason could be using legacy code, let's say that I have a very good writing library in C or C++ or Fortran, and I want to integrate with my new system writing in Python, this is another of the reasons that we can use these mechanisms. And finally, integration, there are other libraries like for example I'm seeing a sticker
of libgit, we can integrate libgit using extensions to use this library through Python. And another reason could be that this is on the other hand, probably we want to integrate Python interpreter in an existing program writing in C or C++, but this is out of the scope
of this talk, but this could be other use of using Python C API. Okay, now I'll explain to you some concepts that we have to know about artifacts in
binary libraries, we have in one way static libraries, and on the other hand we have shared libraries. I'll explain to you the difference between these two kind of libraries. Okay, a static library is just a bunch of object files, as we can see here we have a static library and it's just two object files, a.o and b.o, some met information,
and every time that a linker links this library with a binary, this new binary has a copy of this object, so it seems that in this scope, in this context, we don't want to compile a new Python interpreter with this extension, so it seems that the static
library doesn't work well with these mechanisms. On the other hand we have shared libraries, shared libraries work in another way. Operating systems load a shared library once in memory, and every program that uses
that library uses the same chunk of memory. Every program has its own copy of variables, but they use the same copy in memory. And we can load dynamically during runtime these kind of libraries, so it seems that
shared libraries is the good way to extend Python. Okay, let's start with the three mechanisms. In first place we have native extensions. C Python gave us access to the C API, and C API is a Python API that defines a set
of functions, macros and variables, that provide us access to most of the aspects that we have to access to Python runtime. So we can extend how Python works using C code. Okay, well, let's do a hello world. I thought that making a hello world using native extensions couldn't be very useful,
so I've been thinking hard, hard into a problem, and I want to translate this very, very hard code that does an addition of two numbers to a native extension. Okay, we have a module with a function that takes two arguments, A and B,
and retrieves the addition, very simple. You can imagine another hard function here, another static dysfunction, or something that takes too much time, we can translate into C. And a native extension looks like this. Can you see it? Well, I'll go into detail in the next slide,
but the aspect is that we have our function, and then we define our module in C code. Okay, so in first place, we include our Python API, our Python header, so we can have access to all of the things of the functions, macros,
and variables that Python API gave us. So notice that if we want to use some system includes, we have to include after Python.h, because Python API already finds some system stuff. So if we want to use system includes, we have to include after including Python API.
Here we have our function. The signature is it returns a pointer to a pi object. A pi object, as you know, is the main object of C Python implementation. And then it takes two arguments.
In first place, by convention, it takes a pointer to self. Every function in native extensions takes a pointer to self as first argument, and then a pointer to a tuple of arguments. Okay, then we declare three pointers, a, b, and result.
Then we get these two arguments. As I told you, args is a tuple, so I use this macro defined by Python API, and I get the first argument and then the second one. And then I use another function given by Python API to add a and b.
And I get the result, and I return the result. Very simple. Just notice that this is a toy example. If I pass only one argument, it will probably break, because I don't check if it has two arguments or whatever.
Then we define the public method that my module will have. This is a list with the name of my method, a pointer to my function, some flags, and my doc string. And finally I define the first method that will be called, the first function for it that will be called the first time that I import this module.
And it just needs my module. It gives a name, my public functions, and a doc string for this module. Also Python gave us some tools to deal with compilation of my native extension.
We have extension class that if we give a name, an initial file, it will take care about compiling my code depending on the platform. We don't have to take care about, OK, I have to compile with positive independent code because it has a library. It will take care about it. So I compile it, and we can try my fancy module.
I import it, and I call my function. OK. Take the addition of my two numbers. But I like to go deeper and think about how this works at C-level. OK, so I did a bit of research, and I finally ended in this man-page.
The man-page of dlopen. This is a system called, defined in Linux and VSD. I don't know if Windows is available. And this function, what it does is, given a path and some flags, it loads a cell library into memory.
And the number of references for this cell library. So I grab the Python code, and I ended up in this file. We can see here that we have a call to dlopen with a path name to my module that I'm loading,
in case that is a native extension. And if everything is OK, it will store a new reference to my handle. And this is another system called dlsim that looks for a symbol in my cell library. With this call, he's looking for the first function
that is called the first time that a module is imported. Do you remember this function? OK. It calls this function that registers my module into my dictionary of important modules.
As far as you know, we have to deal with memory in C. We have to, if we allocate some memory, we have to free after using it. If we don't do it, we'll have memory leaks. But we are lucky. In Python, we have an automatic garbage collector. It uses the reference counting algorithm.
So we can have access to this algorithm using these two macros, pyinc ref and pydec ref. So if we are dealing with Python objects, we can use it and it will take care of memory. It also gives us a cycle detector
because if you know how reference counting works, basically it takes account of how many external references have an object and when this counter comes to zero, it frees the object. Basically, it's a very, very basic introduction. But we can have cycles.
It means that we can have reference to the object itself. So Python garbage collectors have also a cycle detector. But what happens when we have to deal with errors? In C, we don't have exceptions, as far as you know. So by convention, we have to return null pointers convention and register my error into a variable that Python interpreter has.
In code, it looks like that. We register our exception with some type. In this case, it's a base exception with some message. And we return null. Also, there are differences between all of these codes from Python 2.
If we want to work with Python 3, there are a lot of differences between the API but also there are differences between how we can define the modules. In Python 2, as you have seen, we have to call a method with some arguments.
Depending on position, it has some semantics. In Python 3, we have to define this struct with a lot more information. We can define more things. But basically, we give a name to our module, a docstring, and a reference to our public functions.
And we create our module with this structure. This is all about native extension. OK, now we will study C types. C type is an advanced foreign function interface for Python. It allows us to call functions from certain libraries
and also allows us to create, access, and manipulate C data types. OK, here we have a list from the official documentation, and here we have a relation between all the types. But basically, what Python does in the underlying is Python has a mechanism for something like flags
and you translate from these flags to C data types. Let's say, for example, an integer is flagged as i, so with some mechanism, I translate my pi object to an integer. Basically, what this C type does.
Then we can define also a structure. We have to inherit from a structure that is defined in C types, and we have to declare the fields of the structure with our C types data types. We can use previously defined structures as fields. OK, so I'll give you an example.
I have a Fibonacci recursive algorithm implemented in C, as a shared library, and I want to map as Python code. So I can call this algorithm using Python. And I will also implement the same algorithm using Python, and I will measure the differences between these two implementations.
OK, here we have our algorithm. Nothing new to see here. Here is the thing. First of all, I import C types. Then I load my shared library into memory, underlying his opening using dllopen,
and I have a handle to my library that is storing my variable libfib. And then I define a function, ctypefib, that takes an argument. OK, and basically what this function does, it is a wrapper that calls my Fibonacci function, implemented in C. So I have a reference to my shared library,
loaded in memory, libfib, and I call my function implemented in C, fib. And as an argument, it takes an integer type of C. So I do the cast to an integer. And below we have the Python implementation.
So I measure the times using ePython. It is not a very, very good benchmark, but we can show the differences using this implementation. We have 63.8 microseconds per loop,
while when we are using Python implementation, we get 3.62 milliseconds. OK, well as expected, there is in C. But as I told you at the beginning, one of the reasons for using this kind of mechanism could be using legacy code.
So I thought, OK, could we use Fortran as an example, and we can take some code, randomly get into the internet, and try to wrap using Python.
So I went to GitHub, I went to trending repositories, to Fortran, there are a lot of Fortran code nowadays. Just a joke. And get this Fortran lib, that is just a bunch of mathematical stuff. And I want to wrap using C types. Here we have our Fortran function,
that returns a real that is mapped to a float. You can see if I am not wrong. It takes a list of reals, and it returns the mean of this list. So I compiled it as a library using gFortran,
and I listed the ABI, the symbols that are public and are exported. I cannot be able to get nicer symbols. If someone here knows how to get nicer symbols using gFortran, I'll urge you.
So we are interested in this symbol. So OK, let's see how this works. We load our shared library, that is called libstatistics. This is a shared library that is compiled with gFortran. Then I get the reference to the function that I want to wrap,
that in this case is this thing, this long thing. And with C types, I can configure the argument types that a function will take. In that case, as I told you, my Fortran function will take a list of reals. In C will be a list of an array of floats.
So I'm telling here two C types. OK, this function will take a pointer of an array. I give the dimension of the array in that case, and also I configure the result type of this function.
And this function will return a float. Then I create an array of two elements, of floats, and I pass my array to my function, and it returns the mean of these two numbers. Pretty straightforward. So OK, let's look into C types code.
I went to the C types code, and I looked for dlopen again. So here we have our dlopen. So the mechanism is mostly the same, that is followed using native extensions. We get a reference to our cell library, and if everything is OK,
we return a reference to our cell library. The contents are the same. OK, now we will study CFFI. CFFI is also an advanced Fortran function interface for Python.
In fact, both C types and CFFI use CFFI as library, but C Python has its own copy into the distribution, because it seems that it is very difficult to install.
It is a bit messy, but if we are using CFFI, we have to install it manually. It also allows us to call functions from cell libraries. Also, we can create access, manipulate C data types, but the difference between C types and CFFI is that we can work also in API level and in ABI level.
As we can see, it is mostly the same as C types, but the authors of CFFI want to get less friction when we are working with Python and C, because if we are working with native extensions, we have to learn a lot of stuff about Python API,
and it is a lot of things to learn. If we are working with C types, we have to learn the API. For example, we have to learn how to translate our types from Python, how they translate to C code, and we have to learn how we can create a structure.
As I showed you, we have to inherit from a class, so we have to learn a lot of things. Also, if we want to use Cython, we have to learn a new language, so they are trying to minimize the things that you have to learn to use their API. Their API is a very minimum amount of functions.
It is also the recommended way to extend PyPy. OK, I will show you some examples. Here we have an example from the documentation of CFFI.
Here we will get a reference to printf, that is in Libc, so we are telling CFFI, OK, I will use this symbol, I will use the function printf with this signature, I don't have to tell the whole signature of the function,
I could get the compiler to infer some things. In that case, I only know that printf takes a pointer to char with the format of the things that I want to print. Then I open Azure library by convention
when we don't pass any argument, it opens Libc. We create an array of char with the word, in that case. You can notice the difference between CFFI and C types. Here we are writing mostly directly C code.
We only have to learn that new, create new variables in C code. And then, in variable C, we have the reference to Libc, so we can call printf directly with my arse.
OK, but it is mostly the same as we have seen with C types. Here comes the interesting thing with CFFI, that we can work at API level. What I mean working at API level?
OK, we can use C code directly written into Python. In that case, it works in the next way. OK, in the first place we define the things that we will use. In that case, I am defining the signature of my Fibonacci function.
OK, it will return an integer, it takes an integer with name n, and then I call the function verify with my C code. Here we have my recursive algorithm written in C, and CFFI will take care about writing this into a C code,
in C source file, compile it, and load it as a cell library into my code. So I don't have to take care, as I have to do with C types, to compile my code separately, and then open it. CFFI does it automatically for me,
and then I call my function, lib.fib with a 10. OK, in some scenarios it will be easier than doing it with C types in two different phases.
What happens if we pass, for example, a string? We have defined that fib will take an integer. OK, so it should break. Yeah, we get a type error when we try to call Fibonacci with a string.
We get type safety in that case. Do you remember the example of a struct that C types? We have to learn the API, we have to inherit from a structure that is defined in C types. It looks like a class in Python, but we have to define some fields.
It's not like our regular classes in Python. It's a bit a mix between two worlds. In CFFI we can define, in that case, an struct and also a type, and we can access directly from our Python code.
We can write into C and then we can access as Python code. We don't have to have this mix between the two worlds. OK, so here I'm defining a struct with two fields, x and y, that are floats. Then I can create a pointer to this new type.
Notice that CFFI, when we are dealing with arrays, structure and pointer, it allocates the memory for the type that we are creating the pointer and filled with zeros. So in that case, point.x and point.y will have zero values.
And they will assign as Python code the values. And we can use over the R code without taking care. So if we go deeper into CFFI code, we will find again our DLLopen frame.
We are using the same mechanism again. We are loading a shell library into memory, and if everything is OK, in that case, I create a new object. This is how we can create Python objects using CFFI.
And I'll store it, and I return my reference to my shell library. OK, so as far as we can see, the mechanisms are mostly the same.
So, OK, my conclusions. We have three different ways. Two of them are very very similar. If we want to extend how Python works, we will use Python API with native extensions.
If we want to call external code, it depends on you. You have to think that ctypes is distributed with a standard library, so you don't have to have external library, external dependencies. CFFI is an external module, but it's more portable because you can use CFFI, for example, with PyPy.
So it depends on the context. We have seen that three of the approaches apply the same principles. They are based on DLOpen and DLSims, operating system calls.
And we have differences in portability. We have seen that there are also differences in implementing native extensions in Python 2 and 3. OK, so we are a bit tied to some version if we write a native extension.
And if we use, for example, CFFI, it will be more portable. And in my opinion, native extensions could be harder because we have to learn how Python works internally. It could be great because it's nice to learn how things work internally.
And if we use ctypes, we have to know very bit about how things work. And if we use CFFI also, we can have extensions with, I don't know, 15 lines of code. And that's it. Do you have some questions?
There's a microphone over there next to the camera, if you have questions.
I don't have a question as much as a comment. In the beginning you showed how to create those native extensions with the CPython API. When you use the Boost Python project, this becomes a lot easier. I mean, it's like you just write your standard C or C++ code and then you write two lines like that.
So you don't have to learn about the internals. Well, but you have to depend on Boost. That is a huge, huge library, so it depends on your context. Probably if you have to integrate a lot of C++ code, you will have to include Boost too.
But compiling and integrating Boost will be a bit difficult. It's not too difficult, but of course you would also depend on Boost. But in the end you also get a shared library and then you just open it in Python. And stuff like data type conversion is automatically handled for you without any other code visible in Python.
So this might be a viable option. It could be an option, but I don't have enough time to explore the whole ecosystem. This is the mainstream waste, but this could be a way too.
OK, thanks a lot. Any more questions? Thank you very much. There will be another talk.