The Python Podcast.__init__

Share on social media:

[00:00:12] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.  

[00:00:17] Unknown:

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 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new 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 just launched dedicated CPU instances.   And they also have a new object storage service to make storing data for your apps even easier.  

Go to python podcast.com/linode,   that's l I n o d e, 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.   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, Corinium Global Intelligence,   ODSC,   and Data Council.  

Upcoming events include the software architecture conference, the Strata Data Conference, and PyCon US.   Go to python podcast dotcom/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 Macy. And today, I'm interviewing Alex Gronholm about AP scheduler, a library for scheduling tasks in your Python projects. So, Alex, can you start by introducing yourself?  

[00:01:50] Unknown:

Yeah. Sure.   I'm a long time,   developer   doing   hobby projects and commercial projects, for many years. I think my professional career mostly started around, 2, 000   7 or 2005.   I didn't start with Python.   I actually started with PHP and then went on to Java.   And then then I think,   Python was the next language.  

[00:02:16] Unknown:

And do you remember how you first came across Python? I remember 1 of my colleagues  

[00:02:21] Unknown:

mentioning it in passing, but, that didn't spark my interest. It's all it was only after, what, a few years that I was reintroduced to Python.   I don't remember when that was exactly.   I do remember I started using it,   in my work projects   in around 2000   7. I think I think I needed to find   a new tool besides Java, and, then I remembered,   Python, maybe because it was all already gaining a lot of popularity.   I heard a lot of good things about Python, and then I wanted to try it out.   I made my first practical application in, like, a couple hours   after starting to learn it. It was that intuitive.  



[00:03:05] Unknown:

So I fell in love with Python, and I I still am in love with Python, I would say. And given that you have a background in a number of other different languages, do you find that you still use those other languages for some of your different projects, or are you primarily just using Python these days?  

[00:03:21] Unknown:

I'm primarily using Python these days, and, pretty much the only other language I use is easy in a script,   for practical reasons because it's the only 1 you can use on the web right now. Yeah. It's  

[00:03:35] Unknown:

interesting that JavaScript has taken such a hold on the web, but I'm curious to see how things play out once,   web assembly gets to be a bit more mature, and tooling makes it easier for us to be able to actually write Python modules to deploy to the browser. The the thing about WebAssembly is that  

[00:03:53] Unknown:

Python is not a really good fit for WebAssembly,   mostly because WebAssembly currently doesn't have garbage collection, but that yeah. That's a whole another topic.  

[00:04:02] Unknown:

And so   in some of the work that you were doing with Python, apparently, you found the need to be able to schedule different tasks. I'm wondering if you can just give a bit of a background about what the AP schedule project is and some of the primary use cases that it was designed for.  

[00:04:17] Unknown:

Yeah. The primary reason why I, chose to write it is because,   there were very many   options for scheduling task in pie for Python at the time. There was the Celery project, but, that was quite a bit of an overkill for what I had in mind. I was, running this commercial project, a custom ERP software that needed to perform some routine tasks on a schedule. And,   I didn't want to use, the Chrome daemon because it was not really the right right tool for the job. So I figured, this shouldn't be that hard, and, I wrote the cronetrigger   and a couple others and published it as a public project after that. And it turns out that other people were also looking for   a lighter scheduler   because, the problem I usually   get told about Celery is that it's very hard to set up, very heavyweight. So people come to AP scheduler because it runs within your application and, not as a standalone service.  



[00:05:21] Unknown:

Yeah. There are definitely a number of cases where, as you said, Celery is overkill for doing some lightweight projects. And I actually came across AP scheduler a number of years ago   when I was first starting to use Python in my professional work   and was pleased with the simplicity of getting it to run because I just needed to write a simple daemon that would execute periodic tasks and didn't need for the distributed capabilities that Celery brought along. So I was glad to find the the work that you did so I didn't have to do it on my own.   So for somebody who is   going to build something on top of AP scheduler, can you just talk through some of the work flow for integrating it into an application  

[00:06:02] Unknown:

and some of the design considerations that they should be aware of as they're planning out the overall structure of their project? Yeah. This is actually 1 of the pain points of, AP scheduler because, the most common type of application out there is a web application. And, usually, in the web application, you have several processes,   running the web application   as multiple workers to distribute the load, and, AP scheduler was really designed to run-in a single process. So if you want to use API's case in a web app, then you need to be aware of, the fact that, it currently doesn't have   any mechanism to share job stores. It, it says so in the frequent last question section in the documentation, but, yeah, it is a very common problem.  

People want to use it in a web app, but there are some ways to do that.   The first and foremost is to not use a persistent job store, but that may not work for everybody. If a persistent job store is required, then   the only real way to do that with AP scheduler 3, the current release, is to run it in a separate process   and   use some kind of RPC mechanism or maybe a lightweight STP server to schedule   the task. So to build some kind of, remote control interface,   for the web app. There are I recall there are some libraries that actually do that.   I can't remember the names of hand, but they do exist. Yeah. In the documentation,  

[00:07:38] Unknown:

you have a reference implementation using our pie c for a simple command and control   mechanism. And so it's definitely   interesting,   whereas you said, a number of people who are thinking about   task oriented   workflows are probably coming from the web where they're familiar with Celery versus people who might be building some sort of system daemon that just needs to be able to run periodic tasks on a server somewhere. And so there are different constraints and different considerations   in those workloads where for web applications, as you said, it's common for people to scale horizontally across a number of  

[00:08:21] Unknown:

is a which case AP scheduler is a is a perfect solution. In fact, the the the the first use case that I had, my own, just involve 1 process.   So it wasn't a problem,   in that setting. So, regretfully,   APS schedule was never really designed for   horizontal scalability, but it's something that I'm already working on. We can talk about it, at in the end. Yeah. When I was looking through the documentation,  

[00:08:47] Unknown:

there's there's a lot of pluggable capabilities within the library. So it definitely seems that you designed in room for being able to add those capabilities   without locking yourself to that at the outset. And so I think some of the design of how you structured the library   definitely allowed for that eventual progression towards something more sophisticated   while still being able to be simple enough for somebody to get something up and running in a single process and solve their needs in that use case. Yeah. People use a lot of backing data stores, and, I received  

[00:09:21] Unknown:

quite a few,   PRs for adding new data stores. I think at least the ZooKeeper and,   ResyncDB   were completely contributed up by other people. So that that was   a plus. It was really nice to see people interested enough in the project to contribute such ready made modules for AP scheduler.  

[00:09:42] Unknown:

And so can can you talk a bit more about how AP scheduler itself is designed and some of the evolution that it's gone through since you first began working on it? Yeah. The the product is so old that I don't remember the design,  

[00:09:56] Unknown:

operations in the beginning, particularly between, 1 point x and, 2 point x. But, at least 1 aspect that I remember from AP scheduler 3 is that,   before that, AP scheduler was not really designed for a lot of jobs in a back end data source. So AP scheduler 3 contains quite a few optimizations to make it work with thousands of, jobs. Beyond that, I really can't recall. I've been trying to make it more modular,  

[00:10:22] Unknown:

more adaptable along the way, but, I still have ways to go. And in terms of the scheduling algorithms that you've built in, what are some of the challenges that you faced in terms of being able to support the different styles of date based versus chron based versus interval, and then have combinations of those and just some of the learning curve that you've gone through while you have been working on building and evolving the project? I would say that the Kron triggers have it's given me the most trouble.  

[00:10:52] Unknown:

Sometimes I would just stare at the call for half an hour trying to wrap my head around the logic.   There have been some edge cases particularly   around   the daylight saving time. I'll just have to say that DST can go die in a fire, but   it's a fact of life that we still have that. So some people have pointed out problems with the DST handling, and I think I've fixed at least the majority of the issues with that, hopefully. Nobody has complained about it recently, at least. Yeah. Then there are some cases where the user can enter basic Chrome specification   that will actually never trigger, and that can cause an infinite loop causing the scheduler to pretty much freeze or go go to a busy loop that never ends. And, I'm not even sure what the proper solution to that is. Maybe limit it to a certain amount of iterations or whatnot. I'm not really sure, but it's a design challenge. Also, the or trigger is is fairly nice and, doesn't usually give you any trouble, but the and trigger is very problematic, particularly when combined with the interval trigger. You see, the biggest issue with combining these 2 is that the interval   trigger starts for certain second or millisecond,   and then the trigger,   compares the produced   next fire times exactly. So the trouble is that,   usually, the interval trigger and the cron trigger never agree on the on the common fire time. So this also causes the schedule to freeze because this keeps looking for   the the avail   the next available fire time, which is never found. There's a fix coming for that in the next major release, but it has given me a lot of trouble.  

I've answered several Stack Overflow questions regarding this very problem, but people keep encountering this problem. It's regrettable,  

[00:12:49] Unknown:

but this is 1 of the biggest design challenges so that I with the AP scheduler. Yeah. I don't envy you being so involved in a project that is so closely coupled to time and the way that computers deal with it because   as anyone who has ever had to deal with it before, time is 1 of the more challenging aspects of working with computers and getting anything right, and that's why there are so many different conflicting truths about how to handle it properly. Also, the issue of time zones. AP schedule currently requires pipe tt time zones because, particularly with the Kron trigger, you have to have PyTT time zones,  

[00:13:27] Unknown:

for time zones that, do have DST.   So even if you use, like, plus,   0200   time zones   that you currently are using, then to a lot of people, it came as a surprise that the that the schedules can be 1 hour off because they haven't taken into consideration the DST issue. I remember this 1 1 person who complained that their schedule was, 1 hour off. And, when I inquired further,   they told me they were using Eastern Standard Time as their time zone, but it was strong because,   they were actually somewhere, on the eastern US seaboard, and, they should have used the America slash New York time zone because that will take   care of DST   when, you enter the cutoff date date time. But, if you use e it's a standard time, and it, it gives a standard,   a fixed offset, which is, of course, wrong at some point. Daytime handling is really a big can of worms.  



[00:14:29] Unknown:

Absolutely.   And so in terms of the ways that you've used AP scheduler, you said that when you were first building it, it was for an ERP system. I'm assuming at this point that you've moved on to other projects. Yeah. And I'm curious how much of a role AP scheduler has played and some of the other projects that you've been involved with since then. Well, I'm embarrassed to say that I don't really use it in production myself,  

[00:14:53] Unknown:

but I anticipate that I will be using the next major release   in production because I do have a need for a scheduler, at least, for a period of scheduling of projects. But, for a simple use case, it's just a sleep loop is enough. In fact, a lot of people have asked   about APScheduler   for their, use cases. And, when I asked, they just need   to do something on on the fixed period. And, I've told them that if they don't need any sophisticated   event asyncio  

[00:15:30] Unknown:

as a,   introduction   of asyncio   as a,   core primitive in the Python runtime   brought about more interest in AP scheduler because of the fact that there is a greater possibility of actually having the asynchronous   offline tasks collocated with the primary runtime? And has that brought people into using AP scheduler within those types of projects? I wouldn't say that asyncio has had much effect  

[00:15:58] Unknown:

on that, but asyncio support is 1 of the weak points actually of AP scheduler, 1 that is going to be rectified with the next major release. Async support was   pretty much an afterthought   with AP scheduler's design. That is going to totally change with the next major release.   I'll talk about that later. But so far, the asyncio support is not not nearly as good as I would want it to be. So,   I've actually refrained from using it myself.  

[00:16:29] Unknown:

And so given that you aren't using it in production,   what is your motivation for continuing to evolve and support the project after so many years? Well, I don't want to leave people hanging, and,  

[00:16:42] Unknown:

it has been a great learning experience for me. I've learned about modularity   a lot. Plus, it's a very popular project. I think it's, somewhere in the maybe top 50 or may at least in the top 100 of, PyPI's,   most downloaded projects. So, it would be a shame to just leave it without the maintainer.  

[00:17:02] Unknown:

And do you have any strategies as far as making it sustainable, or is it just a nights and weekends project that you work on as you have the time?  

[00:17:11] Unknown:

Pretty much so.   Nobody has volunteered to take over, so I'm just continuing it, when I whenever I have time. Also,   I should mention that,   former cuts of the salary project has expressed interest in,   incorporating   AB Scheduler into salary.   It's interesting.   Celery is, from my viewpoint, is pretty much   a task queue with some minimal scheduling capabilities,   while AB scheduler is probably a scheduler with some minimal task queuing capabilities.   And, in fact, I approached them years ago   trying to get them interested in,   incorporating a biscuit or 2 Celery, but,  

[00:17:52] Unknown:

they didn't express any interest in that at that point at least. Yeah. I've used Celery for a while. And while I was preparing for this conversation, I actually went and looked through their requirements list to see if AP scheduler was used at all because of the fact that they do have some scheduling capacity with their celery beets, and I was a little surprised to see that they didn't actually leverage that. So I think that that could be a a good union of projects   to improve some of the capabilities of Celery because I know that Beats is 1 of their weak points. Mhmm. So I've learned that, Celery  

[00:18:24] Unknown:

5   will also,   come with some major   internal changes, such as better high availability.   And, to accommodate that, they have requested   some changes to AP scheduler, which I am happy to provide.   We can also talk about that,   at the end. And  

[00:18:44] Unknown:

so in terms of some of the other uses of the project and some of the community that's built up around it, what are some of the most interesting or innovative or unexpected ways that you've seen it used, and how has the overall community reception and growth been for you as the maintainer of the project? Well, it has to be very encouraging to hear about all of the all different use cases. People don't usually really give me, the details of their, projects because they are often closed source commercial projects, but  

[00:19:17] Unknown:

I've learned bits and pieces   from here and there. I think the first, interesting   point that was pulled up was when somebody told me they were, scheduling thousands upon thousands of jobs at the time. This prompted their optimization,   for AP schedule 3. But, also,   I remember this 1 use case where, they were trying to set up   a a system that would allow different users to dynamically schedule   jobs for themselves, but to keep   different users separate. I'm not sure, if that product went anywhere because, AP schedule doesn't really accommodate such a use case.   I'd really like to support that, but, it's a very difficult, design issue. Apart from that, I don't I don't really recall any specific product or use cases that, that might have been   noticeable.  



[00:20:11] Unknown:

And as you have   grown and maintained the project, and as people have used it for their own particular   projects,   what are some of the features or capabilities   that have been requested which you've consciously left out or pushed into,   other projects  

[00:20:27] Unknown:

that wrap or take advantage of AP scheduler or integrate with it. The fact is I don't remember. There have been a few a few request that I outright turned down, but,   I can't recall the specifics and, I couldn't   I couldn't easily find them on the bug tracker. But I tried to be as accommodating as possible, but, some of these features were very specific to their use cases.   So I I wanted to keep this maintainable,   and with so many  

[00:20:57] Unknown:

vastly different back ends, it would be very difficult to support these use cases. I'm sorry I can't be any more specific than that. That's fine. For such a long running project, it's entirely expected that different details will fade into the background, and it's impressive that you've kept it going as long as you have.   And,   in terms of some of the   design strategies   or features that might often be overlooked or underappreciated,   what are some of the things that you think users should be more aware of or would be able to benefit from digging deeper into?  

[00:21:30] Unknown:

I think that might be the use of setup tools entry points. You see, AP schedule use have this, setup tools entry points declared for,   different triggers and, job stores and executors. So that makes AP scheduler,   extensible   in such a manner that you can declare these entry points in your own project, and,   you can then use   the, a job, a job store and   so forth,   and use   names of your custom,   triggers or job stores,   directly with AP scheduler. It will just look up the   entry point dynamically,   and then it will just work. Also,   a lot of people seem to have a very   specific,   requirements   for triggers.  

Most of these use cases can be handled with the new   combining triggers. But in other cases,   I have told people to write their own trigger classes.   And   for some very specific use cases, I still recommend that.  

[00:22:39] Unknown:

And have you had people do something like build event based triggers so that it's less time based but still is able to take advantage of the rest of the capabilities of AP scheduler?  

[00:22:50] Unknown:

In such cases, you don't really use triggers, but because triggers   are solely used for calculating the next,   fire time.   So if you want   to build a reactive application that, loan schedules,   tasks for execution right now, then   you don't really want to use triggers for that. You can just use a b schedule or as a test task queue,   but you have to build that, reactive mechanism some other way.  

[00:23:19] Unknown:

And in terms of your experience of building and growing the project and the community around it, what have you found to be some of the most useful or interesting lessons that you've learned in the process?  

[00:23:30] Unknown:

I think, it mostly revolves around modularity   and API design.   API design is a very complex issue,   very difficult   because you have to anticipate a lot of the use cases.   That's the most difficult part   in this.   Yeah. Also, I'd like to mention this 1   issue where a particularly angered angry,   user came to be complaining that all of their jobs   have disappeared.   This was because of,   partly a misuse by the user, but, also   a design problem with AB Scheduler.   They had scheduled,   number of jobs,   and then they were using AB Scheduler from a total different process that didn't have the same code base, and we're trying to gather a list of jobs.   Now you see, when AP scheduler is trying to deserialize,   the jobs from persistent data store,   It tries to look up the job,   and, if the job function isn't found, the job is discarded.  

It was built this way   so as to,   get rid of the jobs that are no longer relevant. But,   in this case,   well, it was quite undesirable,   and,   this user was very   cross with me. Well, I don't   blame them that much. Of course, they were they were misusing the schedule, but they   I don't blame them for not knowing what would happen.   It's regrettable,   and, it's   something I plan to fix in the next major release.  

[00:25:11] Unknown:

And so looking forward to what you have planned for this upcoming release, what are some of the   new capabilities   or   new, evolutions of the project that you're working on currently?  

[00:25:23] Unknown:

The number 1 feature for AP scheduler 4 will be high availability.   Finally, the a adapt ability to   share job stores between different schedulers.   So you can have this web app and the scheduler running in it even when using multiple workers.   The scheduler will know how to   communicate.   Basically, it means that, when the scheduler looks for the next,   schedules to   to run. It will, obtain a lock on the schedules,   and then other scheduler will know not to try to process them.   So it's a partial redesign,   a major redesign, I would say, that, considers   high availability from the ground up.  

That's the that's the biggest feature. As for the rest,   I intend to fix,   some   some of these 1 issues with the triggers.   Right now, the plan is to make all the triggers   stateful.   1 of the biggest reasons for that are the combining triggers because   the way they work right now is is a bit difficult because   when you have multiple triggers inside an end trigger, it doesn't it doesn't keep track of, what kind of run times they have produced.   So if   it can   give you some   unexpected results,   and, that's something I intend to fix with the next release. Also, there will be a threshold   within which the fire times have to fit. So they, they don't need to be exact matches anymore. Yeah. There was also 1   design issue with the   with the cron trigger. I think the weekday numbers didn't really match   the cron specification,   but I couldn't fix that   in 3.x,   because it would have caused   unexpected behavior   for people who have already   worked around this problem.  

Yes. And,   there was a better async, support across the board.   All the job stores will be asynchronous, and,   a booking schedule will be provided, but behind the scenes, it will use async.  

[00:27:49] Unknown:

And in terms of the async capabilities, you mentioned that there is some support for it, but it's not as fleshed out as you would like. And I know that in the past conversation that we had about the Asphalt framework, I think almost 3 years ago at this point, you were using AP scheduler and that where Asphalt is primarily based around asynchronous networking. And so I'm curious   how much of the design and integration   of AP scheduler with the async runtime was driven by your use case of building,   building the asphalt framework and using the AP scheduler within there?  

[00:28:24] Unknown:

Not much, really. These points are very separate.   I want to have some integration at some point, but,   as far as async support goes, in AP scheduler,   I didn't actually plan to go, that deeply into async until I was requested to do so by by of   Celery   because they want   to jump,   both feet into a which both feet into async.   So I figured I could do that too   and,   just provide a synchronous interface for people who don't want to use,   async directly.   This new async support will be centered around my other project called any. Io,   which is a common API   for   doing asyncio,   with asyncio,   curio, and Trio.  

You can use any 1 of these 3 as back end. Anyhow still doesn't support the Twisted because of the some architectural issues with Twisted, but,   I'm hoping that, it's an issue we can overcome at some point with the Twisted People.   So I don't know how to handle Twisted support.   I think that APC 4 will need to have a lot of, prereleases   to sort out the design issues because it's going to be,   it's going to break quite a lot of the interface   for   because it's a it's quite necessary.   Some of the   issues,   with the design,   are such that, you can't really   fix them without breaking stuff.  



[00:30:06] Unknown:

Are there any other aspects of the AP scheduler project   or dealing with task scheduling that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:30:18] Unknown:

I can't think of anything.   Oh 0, yeah. There was 1 1 thing. There's a long standing issue,   with   using entry points that   projects like pi 2 x and, pi installer   have a problem with entry points   because they don't package   the library metadata,   the distinfo directories,   which breaks   the entry points, and that, has been a problem. I'm looking for   an alternate solution,   maybe giving up entry points completely,   but, it's been an issue that a lot of people have encountered.  

[00:30:59] Unknown:

And in terms of contributions   or engagement with the project, is there any particular help that you're looking for or any particular skill sets that would be useful to you? Well, not at this point, but going forward,  

[00:31:12] Unknown:

it would be nice to have people,   contribute more   back ends   to a p scheduler   once, it's in the usable state.  

[00:31:22] Unknown:

Well, for anybody who wants to get in touch with you or follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks.   And this week, I'm going to choose the Data Exchange podcast, which I found recently that is hosted by Ben Lorica, who was formerly of O'Reilly.   So he's moving the work that he had been doing with the O'Reilly data podcast to his own independent 1, and so so far it's been enjoyable. So if you're looking for   a new podcast to listen to, I, recommend taking a look at that 1. And so with that, I'll pass it to you, Alex. Do you have any picks this week?  



[00:31:57] Unknown:

Well, there was this 1 library that I came across called Tenacity.   It's a retrying library.   It's very sophisticated   and   has full support for async too.   It was a really nice find.  

[00:32:12] Unknown:

Alright. I'll definitely take a look at that 1. So thank you for taking the time today to join me and share your experience of building the AP scheduler project. It's 1 that I've taken advantage of in the past, and so I appreciate all of your time and effort on that. And I hope you enjoy the rest of your day. Thank you, and you are welcome.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.   And visit the site of pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.  

And if you've learned something or tried out a project from the show, then tell us about it. Email host at podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.