Data Engineering Podcast
Getting A Handle On Portable C Extensions With hpy - Episode 254
One of the driving factors of Python's success is the ability for developers to integrate with performant languages such as C and C++. The challenge is that the interface for those extensions is specific to the main implementation of the language. This contributes to difficulties in building alternative runtimes that can support important packages such as NumPy. To address this situation a team of developers are working to create the hpy project, a new interface for extension developers that is standardized and provides a uniform target for multiple runtimes. In this episode Antonio Cuni discusses the motivations for creating hpy, how it benefits the whole ecosystem, and ways to contribute to the effort. This is an exciting development that has the potential to unlock a new wave of innovation in the ways that you can run your Python code.
As a developer, maintaining a state of flow is key to your productivity. Don't let something as simple as the wrong function ruin your day. Kite is the smartest completions engine available for Python, and it's trained on thousands of open source projects that were highly starred by Github users. Kite boasts advanced features such as:
Ranked completions: Kite's completions are sorted by relevance instead of popularity or the alphabet
Line of Code Completions: complete up to full lines of code
Intelligent Snippets: advanced function call experience using machine learning to suggest placeholder values where you can fill in arguments and method-calls with variables defined earlier in a script.
Copilot: Automatically shows you relevant Python documentation while you type based on your cursor location. This saves you time from having to Google Search for docs.
Get Kite for free today at pythonpodcast.com/kite with integrations for top editors, including Atom, VS Code, PyCharm, Spyder, Vim, and Sublime.
Do you want to try out some of the tools and applications that you heard about on Podcast.__init__? Do you have a side project that you want to share with the world? With Linode's managed Kubernetes platform it's now even easier to get started with the latest in cloud technologies. With the combined power of the leading container orchestrator and the speed and reliability of Linode's object storage, node balancers, block storage, and dedicated CPU or GPU instances, you've got everything you need to scale up. Go to pythonpodcast.com/linode today and get a $100 credit to launch a new cluster, run a server, upload some data, or… And don't forget to thank them for being a long time supporter of Podcast.__init__!
Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it, so take a look at our friends over at Linode. With 200 Gbit/s private networking, node balancers, a 40 Gbit/s public network, fast object storage, and a brand new managed Kubernetes platform, all controlled by a convenient API you've got everything you need to scale up. And for your tasks that need fast computation, such as training machine learning models, they've got dedicated CPU and GPU instances. Go to pythonpodcast.com/linode to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show!
As a developer, maintaining a state of flow is key to your productivity. Don't let something as simple as the wrong function ruin your day. Kite is the smartest completions engine available for Python, featuring a machine learning model trained by the brightest stars of GitHub. Featuring ranked suggestions sorted by relevance, offering up to full lines of code, and a programming copilot that offers up the documentation you need right when you need it. Get Kite for free today at getkite.com with integrations for top editors, including Atom, VS Code, PyCharm, Spyder, Vim, and Sublime.
You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis. For even more opportunities to meet, listen, and learn from your peers you don't want to miss out on this year's conference season. We have partnered with organizations such as O'Reilly Media, Corinium Global Intelligence, ODSC, and Data Council. Upcoming events include the Software Architecture Conference in NYC, Strata Data in San Jose, and PyCon US in Pittsburgh. Go to pythonpodcast.com/conferences to learn more about these and other events, and take advantage of our partner discounts to save money when you register today.
Your host as usual is Tobias Macey and today I'm interviewing Antonio Cuni about hpy, a project aiming to reimagine the C API for Python
How did you get introduced to Python?
Can you start by describing what the hpy project is and how it got started?
What are the goals for the project?
Who else is involved?
How much engagement have you had with CPython core contributors or the steering council?
Who are the consumers of the current C API for the CPython implementation?
What are some of the pain points or shortcomings for those consumers?
What impact does that have for users of a given library that leverages C extensions?
Can you talk through the structure of the hpy project?
What are some of the design challenges that you are facing for determining the external API?
What is involved in integrating the hpy interface into alternate runtimes such as PyPy or RustPython?
What is the potential or observed performance impact for libraries that currently rely on the existing C API?
How has the vision and scope of this project been updated as you have gotten further along in the implementation?
What are the downstream impacts that you anticipate in projects such as PyPy and Cython?
What have you found to be the most challenging or contentious aspects of implementing hpy so far?
What are some of the most interesting/unexpected/useful lessons that you have learned while working on hpy?
What do you have planned for the near to medium term for hpy?
antocuni on GitHub
@antocuni on Twitter
Collapse: How Societies Choose To Fail Or Succeed by Jared Diamond
hpy
PyPy
Alex Martelli
Podcast Interview
Python C Extensions
EuroPython
Victor Stinner
Armin Rigo
ultrajson
GIL == Global Interpreter Lock
RustPython
GraalPython
hpy-rust
The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA
Click here to read the raw transcript...
Tobias Macey
Hello, and welcome to podcast ordinate, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at linode. The 200 gigabit and private networking node balancers, a 40 gigabit public network fast object storage and a brand new managed Kubernetes platform all controlled by a convenient API, you've got everything you need to scale up. And for your tasks that need fast computation such as training machine learning models or running your ci CD pipelines. They've got dedicated CPU and GPU instances. Go to Python podcast.com slash linode. That's Li n o d today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show. As a developer maintaining a stable flow is key to productivity. Don't let something as simple as the wrong function ruin your day. kite is the smartest completions engine available for Python featuring a machine learning model trained by the brightest stars of GitHub, featuring ranked suggestions sorted by relevance offering up to full lines of code in a program and co pilot that offers up the documentation you need right when you need it. Get it for FREE today at get kites calm with integrations for top editors, including atom VS code, pi, charm, spider, vim and sublime. And you listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis. For even more opportunities to meet listen and learn from your peers you don't want to miss out on this year's conference season. We have partnered with organizations such as O'Reilly Media chronium Global intelligence, od sc and data Council. Upcoming events include pi con us and Pittsburgh, go to Python podcast.com slash conferences to learn more about these and others events and take advantage of our partner discounts to save money when you register today. Your host, as usual is Tobias Macey. And today I'm interviewing Antonio Cooney about h py a project aiming to reimagine the C API for Python. So Antonio, can you start by introducing yourself?
Antonio Cuni
Yes. Hello, everyone. I am Antonia Cooney. I am mostly known in the Python community because of my work on pi pi. I have been a core developer of pi pi since 2006.
And do you remember how you first got introduced to Python?
Oh, yes, it was a long time ago. I think it was 2001. Just before I joined the university, I was lurking on the Italian c++ News group. And there was a guy Alex Martelli, who is very well known in the Python community as well, who kept writing about a wonderful list Python as a language. So I gave it a try and never looked back.
And so now you're working on this H pi project, which I understand is at least partially motivated by some of the pains that you felt as a maintainer of pi pi. So I'm wondering if you can just give a bit of an overview about what h pi is and how it got started.
Right? You gotta correct. So by. So one of the most painful point of pi pi is the C extensions. Most of the C extensions for the in the Python world are written targeting the C Python c API. And in the past years, we as pi pi developers have been trying to support all of these extensions in pi pi. But it's very painful and slow and cumbersome because the C API is way too tied to the C Python internals. And so after years and years of pain, we started to think about a better way of doing the job. And we started to feel that a newly designed API couldn't be better. The problem of designing a new API is that then You need to revise all the extension. So it was not clear that it was a good idea that that's basically how and when his idea became stuck in our minds.
And so as far as the goals for this project, I'm wondering what the overall scope is and sort of when you can state that it is done or successful.
Good question. The goal is is for it to be any incremental project, we can fix every problem at once. And so, in a way it will never be finished. The goal is to start having a foundation in which you can start to experiment with to have different backends for implementation. And, and to start writing. Some extension or part of some extensions is engaged by so that we can see what are the benefits hopefully If the benefits are as good as we owe, then people will become interested in supporting the extension to age by writing new backends, for example, for site on so that site on emits code, which is compatible with h bi, and maybe even to start experimenting with improving or evolving c Python, to try new things that are currently impossible because of the currency
API. And in terms of the people who are involved in this project, I understand that pi pi being one of the main intended consumers there obviously people working from it there. Are there any other projects or people within the C Python core contributors or the steering council who are either contributing to it or who you have had conversations with about determining and appropriate direction for it?
Yes, h bi is a project which started from the bite by developers at least in terms of thinking about the other people are involved, which include many projects, which are Important in the Python community, actually pi pi is started for real, almost eight months ago at Euro Python in basil. When I met Victor stinner, which is who is a core c Python developer and is now part of the Python steering committee talking to him, I realized that we both are concerned about the shortcomings of the currency API. And we started to talk about this new API, which could solve all the problems. And so we decided to sit down and start to do something more concrete at the Euro Python, we we involved also other people who are there, and in particular is different than winner, who is the main site on developer and Mark Shannon, who is another c Python developer. And on the Pi Pi side, there were me army regoing around me, and so if I started, not as a pure fighter By project but really as a
community driven project so that it can be useful for all the parties involved. And for the C Python maintainer is what are some of the pain points that they're dealing with with the current implementation that they are interested in working on h pi as a solution to that.
So there are many supplies on maintenance. So as far as I know, not, not everybody is concerned about the current problems of the C API. But for example, as I said, some of the C Python developers are worried about the fact that it is harder to improve and to innovate the internals of C Python, because for example, given the current state of affairs, it's very hard to remove the Gil the infamous game, or to use a different garbage collector, which is not a reference counting. In a sense Ah, bye Will will help support itself to try new things which might or might not be useful in the future.
And for other consumers of the C API, such as people who are writing performance critical extensions like NumPy or sci fi, what are some of the benefits that they might be able to gain by having this reimagined interface to the C Python implementation or something that's a little bit more portable between runtimes
what they The most obvious advantage is that you will be able to use these extensions also an alternative runtimes for example, by pi. As of now bye bye for certain code patterns is by far the fastest Python implementation. Who is which is around but you can't use it effectively with C extensions such as NumPy, which are needed for performance for other in other areas. So the most obvious use case is to use for example, NumPy, and sidebar Together with feifei and and his complete stack of software, which is fast and more in the long in the longer term, the best benefit of AI will be the fact that it will be possible to innovate, to try new things to develop a new Python implementation, which which we can think think of right now. But it will be much, much easier for them to try to write a new implementation without all the things that we had for pi pi.
And so for people who are currently consuming the C API will be the process for them to be able to take advantage of this new interface and from the maintainer side of the C Python runtime. What do you see as being the path forward for them to be able to deprecate this old c API, or at least migrate people primarily to h pi so that they can feel confident with changing what The internal API looks like without having to worry about breaking a number of extensions that are dependent on those implementation details.
So for for extension users, basically, they like a NumPy user, they will need to wait until NumPy is made compatible with h pi is not something that the user and consumers of these extensions can do. For the extension brighter, they will need to rewrite the extension using h pi instead of the C API, the currency API API, currency API functions. We are Designing API h by making sure that this transition will be as easy as possible and you know, not too hard. It must be say that currently, some extensions are written in memory in C for example, NumPy. So for for it, the only way of immigrating to h bi is to rewrite parts of it. But the most of other extensions are written for example using seitan. And so, it means that it will be enough for seitan to meet HP code and all these extension will be automatically taking advantage of H BI. It also must be said that the performance is not the only advantage of using gauge buy another selling point of it is that there will be a debug mode which will introduce many many check at runtime For example, to check that we are not leaking objects or that we are not using an object after it has been freed and and these kind of checks and if we may make debugging and development much more easy, easier and much more robust and this debug mode will be enabled, it will be possible to enable the debug mode at runtime. So, it will not be On the necessary to recompile, the extension to enable it, which is a pain point of this currency API.
And so for the HP project itself, can you talk through how it's structured and just the overall development process of being able to iterate on wrapping the existing c API and some of the design challenges that you're facing in terms of determining what the user facing interface is going to look like and something that will be clean and maintainable going forward?
Well, one of the goal of H bi is is to make make it possible to do an incremental porting. So a current extension will not be forced to do a report to rewrite all the code at once, it will be possible to start porting the porting things one function, one method or one class at a time. This is very important because it makes it make it possible to experiment
to try to see how it looks like
to check whether the performance is is good and and to become interested in trying more basically. And this is related to what is the biggest issue and the biggest difficult in developing AGI which is to find the right sweet spot in the trade off between writing a nice new modern API and to write an API, which makes it easy for people to migrate to migrate their existing extensions. And every day in developing that pie, we we see these trade offs and we are trying various, various things to make it easy to integrate, and to use the best practice and to design an API which is modern and safe.
And so in terms of the interface that is consumed by the runtime, so specifically the C Python or pi pi runtime What's involved in integrating h pi into those projects or any other alternative runtimes such as rust Python that might want to be able to provide this same outward facing interface to extension developers.
So every Python implementation, we need to implement their own age by interface. But usually, it should be easy because, for example, one, one function will be h pi r, which, which is does exactly the same semantics of the plus operator in, in Python. So if you have if you are, if you're implementing a Python implementation, you need to have this logic inside. And the HPI is just a way to call this logic from C. So ideally, HPI will be a three layer on top of the existing semantics, which makes it possible to call it from C. Currently, we are developing three different backends at the same time, and to have These backends are for C Python and one is four pi pi. Why? Why do we have the need for two different backends on C Python? Well, the point is that one of the goal of H pi is that extension should not be slower on C Python, we don't want the non pi people to support the extension to h bi, and then discovered that it is lower on C Python, because they'll say it's not going to be useful. So one of the back end that we have is for Python is is basically a set of C macros and start taking line functions, which translate the age by calls into all the C API calls at compile time. So from the point of view of sci fi don t, the extensions will be exactly as before and then another possibility is to compile an H by extension in what we call the universal mode. So it produce a DLL though so on Linux, which is universal and it's in theory loadable and executable by any compatible Python implementation without recompiling. And we also have universal back end for C, Python, and then universal back end for pi pi. And this is the only back end that we will know will ever be needed for pi pi. And D is another advantage of H by the possibility of distributing one binary, which works on every Python implementation if you don't care too much about that from us.
So for extension developers who want to start porting some of their code to use the H PI Interface, is it something where they would include the H pi library in their source code? And then during compilation, it would then translate to whichever back end they're targeting? Or is it something that would need to be compiled into the Python runtime to provide those interfaces that would then be consumed by the library developers.
So this is work in progress. Currently, you'll You need to manually include a specific set of headers file to compile an extension for H pi. But eventually, we want to provide a nice installable package, which you can use to develop and compile your h bi compatible extensions. So ideally and eventually people will just do something like from ah by Dr. Deval important extension, and use and use these extension class in their setup.py file. And this class will take care of all the logic needed to compile the extension. And users will be able to decide at compile time whether to target one specific implementation, for example, C Python, or to target the universal mode, so to produce a file, which will be compatible with everyone,
and you mentioned that there are two different backends for C Python because of some of these performance considerations. So I'm curious what you have seen as some of the observed or potential impacts on performance and runtime overhead for using h pi and that universal mode?
Yes, that's a very good question. First, let me explain why we expect the universal back end to be slower than the C Python specific back end. For example, in C, Python, you are using reference counting, which means that every time you pass an object around, you need to call in correct and then the craft on it. And in spite honor, the scores are user are usually macros and so the C compiler can optimize it very well. In the universal mode, there are no longer in graph and the graph we are using the concept of handles which are more opaque and since since the implementation is universal, it cannot be written as macros. It needs to be function calls, which are resolved at runtime when they are loaded into the proper interpreter. So for example, it means that every incorrect in the graph Inside the extension module, B will become a function call instead of a macro. That's why we expect it to be slower in the universal mode instead of the C Python specific mode. But actually, we we have a benchmark, which shows that it is about it is much lower than we thought. So the first benchmark that we tried is to port the OTR JSON library to h pi. And we measured that the C Python back end has no impact over at all. So it's on h pi is as fast as the normal user Jason on C Python. And on C Python using the universal back end is benchmark is a Java 2% lower or so which means that for most projects, it is might be good enough and the advantage of being able to distribute a single binary for all the implementation might be bigger than the divert potential of having a 2% drawdown of course, it must be saved. That is just a single benchmark. We need more benchmarks and more extensions and more measurement before knowing precisely what it will be the actual impact.
As you have gotten further along in this project, what are some of the ways that the initial vision and scope of the project has been updated or any assumptions that you had going into it that have been changed or modified in the process?
So far, I think that we are mostly on track in the sense that the project is going to more or less in the direction that we imagined. When we started, one of the things that we realized is that the C API is very broad. We were they knew it. But we knew from the point of view of people that wants to implement its semantics. Now we are also seeing it from the point of view of people who wants to use their API for doing stuff. So we are realizing there are very, there are many different use cases for which people needs to use the API and they exist. API. So we need to design a new API, which makes it possible to implement all these use cases.
So in terms of the timeline for this, what do you anticipate as being the amount of time that's required to get this to a point where library developers should start using it as the target for building their own work? And what do you see as the path forward for the C Python implementation as far as adopting this as at least an optional interface for the core runtime.
So for now, the project is still in its very early stages, we we are still busy implementing the very basic stuff. So for example, as of now it is not yet possible to write a custom type, we can you can just write functions. So it's clear that it's not immediately usable and usable for for writing real extensions, and they How much it would take to put it into a state which is useful? I don't know. It's mostly dependent on how much time we can spend on it, which also depends on how much money we have to work on it basically, I hope that in the The following year, in the next month, we should be able to arrive at a point in which we have a smaller NumPy like library, which shows all the interesting and hard parts and and then we can use these as a benchmark and as a starting point to go forward and for example, to start experimenting with the real NumPy with love the other question, sorry,
just curious about the timeline for the project. And any plans are projected timeline for H pi to be available in the core c Python runtime as at least an optional interface?
Yes, I don't think that is going to happen anytime soon. Imagine an ideal world in which all the current c extension will be written using h BI. And so C Python, we will be able to decide to use h pi as the official interface. But I don't think it's going to happen anytime soon, because it will involve rewriting many parts of the internal code, what could happen, and what I hope it will happen is that people could try it too for, say Python to experiment. So for example, I can imagine that once AGI is a stable and use it and and, and you know how it looks like, I can imagine two forks a button to remove many unnecessary Well, not the necessity but the note vital modules and start to re implement the internal c Python objects in terms of H via API. And then once You have these you can start to experiment with with improving the virtual machine of Python itself. For example, you can try to use a
garbage collector instead of reference counting
and and things like this. But as I say that I think this is more in the medium or long term than the shore.
And as you have been working on h pi, what have you found to be some of the most challenging or contentious aspects of the project or any long running design questions that you have had to go back and forth with the other members of the project,
they they say to be full of the biggest challenge is to find the sweet spot between make having a nice API and make it easy to support existing differentials. So many times we we sit down in front of the Blackboard or in front of the monitor and we tried to sketch How is the extension looks like how pote implement the type, how to pass pointers which can remove the memory by the GC and etc. And every time we spent hours really our real hours discussing the maybe two or three different possibilities and possibility our a is closer to the currency Python solution but maybe a bit more inefficient for byte by possibility me is maybe better for pi pi about harder for C users to write. And then there is a lot of trial around until we find something which which respected all of the requirements.
And when you're commenting to about the possible transition period of H pi, it starts to bring up echoes of the Python two to three transition. So I'm sure that there are a lot of concerns on that line as far as not wanting to fork the community because of this potential new interface, even though it will likely have significant benefits downstream.
Yes, you're completely right. We want to avoid any split in the community, any fork, and anything like that. That's why earlier I say that one of the goal of AGI is to be incremental,
you will be able to take,
for example, NumPy, and start rewriting just one metal three feet, using the H PI Interface, and keep using the old API for all day all day, all the rest of the extension. And these new method will be fast on pi pi, for example, and there will be no difference for C Python. So with the starting point, it means that you you can always improve and make it make things
better, for example, for pi pi
without making it worse for C Python. And and the more you do, the better things become and then hopefully at some point, he will get enough traction that people would want to use it to get to the benefits.
And what do you see as some of the potential risks to the success of H pi, or any blockers that might come up that will prevent any forward progress on it?
The biggest basically, is that the many projects don't want to change. So, for example, from the point of view of NumPy developers, why do they want to accept maybe our pull requests to migrate slowly? Which by when they are existing, the code is perfectly fine for the existing users? I can't answer to this question. I hope that the community as a world will, will see that AGI is needed to make it possible to innovate in the Python world. Maybe I didn't, I didn't make it clear earlier in the interview. But the biggest problem of the Korean to C API is that it makes it hard or impossible to innovate Python as a Python As language is doing a good job, because of its big ecosystem with all the libraries, and people expects all the libraries to be available when they when they use Python, but all these libraries are very tied to the current internals of C Python. For example, the fact that they have a reference counting and that at offset eight of, of an object, there is a field which is the reference count, and, and so on these low level details, which makes it impossible for new vitra machines to innovate and to try things to try other things. If If Python as a as an ecosystem, do not try doesn't does not try to evolve into you into innovate, it will be the risk is that it will be become less and less relevant in the future. The GI Bill is already a perfect example. There have been many attempts of killing The Gil removing the Gil. But reference counting is is a big issue to it. And it is not possible to rewrite the C Python without it because of all the issues that I mentioned before. So from site point of view h pi will be is good and needs to happen for the world buyten ecosystem not just for buy, buy, buy buy is just the the main benefit that immediately they mean immediate projects which can benefit from it. But generally speaking, the possibility of having more virtual machines and runtimes is a it's something that you really need as a language as an ecosystem.
And I can definitely see that as being a potential path forward as well for solving some of the issues that we have in being able to target mobile platforms or the web as well because as you said, the majority of Python is tied to this Python runtime where once we get to a point where we can innovate on the VMs, or have multiple different deployment targets for it, it will unlock some of the potential for being able to run on some of these platforms that we're currently unable to target.
Yes, I completely agree.
And so, in terms of the near to medium term for HP, what do you have planned, most immediate
target is to be able to support support custom c types in extensions. So we can experiment with NumPy like extensions and see how it looks like and what is the performance it is there is something which is going to happen in the next weeks basically, and then the the other big plan that we have in the short period is to write a site on backend for API, so that the people writing essential insight on will be will be able to immediately benefit of it without having to write anything manually
in terms of any help or contributions or support. weren't for the project, what are some of the most useful skill sets or ways that people can help to move the project forward?
that's a that's a very good question. Of course, and yet is, is welcome. And I think it would be very welcome to have someone who, who is a consumer of this API, someone who, who tried the extensions daily, or who has a lot of experience in writing it, because it could, it could very, could be very useful for us to be warned beforehand that the direction that we are taking is wrong or that direction is better and things like this. And, and then it's it's really nice to see that HPI is attracting the interest in from various projects and parts of the community. Because we started in a few, a few people, but immediately we go manifestation of interest from developers of rust Python. So today they couldn't load their h by extension on the runtime growl Python, which is another Python implementation based on Java development by Oracle. And recently the there is also a sub project to be able to use h pi with rust so that you can write the Python extension in rust and decide whether to target the C Python or H by so we have users and people involved or from both ends of the line from in one end, you have people writing extensions, and on the other end of fighting implementation, and any people who have experience in these two topics is very welcome to help.
And are there any other aspects of the work that you're doing on h pi or the goals that you have for it or some of the potential impacts and benefits that we didn't discuss that You'd like to cover before we close out the show. So we're just wondering if there's anything else that you think we should talk about in terms of the work you're doing on h pi, or any of the potential benefits or impacts that it might have or any of the related projects that will be a benefit from it?
No, not more than I just didn't they already saved.
Okay. Well, for anybody who wants to follow along with you, or get in touch or contribute to the H pi project, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the pics and this week, I'm going to choose the poetry tool. I've started using that more heavily in some of my projects. And I've been enjoying that as a way to get things set up quickly and managing dependencies. So definitely recommend taking a look at that for any new projects you're working with. And with that, I'll pass it to you, Antonio, do you have any pics this week?
Yes, I would like to suggest the book which I read recently, Jesus collapse by Jared Diamond and I think it's a book of Which is interesting and terrifying from some point of view. But I think it's good to read to have an understanding of what's going on in our world, keeping in mind what happened already in the past,
I'll definitely have to take a look at that. So thank you for the recommendation. And thank you for taking the time today to join me and share the work that you're doing with h pi. I'm definitely excited to see how it goes and see some of the downstream benefits from that. So I appreciate all of your work on that front and I hope you enjoy the rest of your day. Thank you very much and goodbye. Thank you for listening. Don't forget to check out our other show the data engineering podcast at data engineering podcasts calm for the latest on modern data management. And visit the site at Python podcasts calm to subscribe to the show, sign up for the mailing list and read the show notes. And if you've learned something or try it out a project from the show then tell us about it. Email hosts at podcasting a.com with your story. To help other people find the show. Please leave a review on iTunes and tell your friends and co workers
Liked it? Take a second to support Podcast.__init__ on Patreon!
Community Kite Linode Open Source Python
Boundless Notions, LLC.
Copyright 2018. Boundless Notions, LLC.