Transcript: Django Stubs - Nikita Sobolev

I'm Carlton Gibson, joined us every by Will Vincent.

Hello, Will.

Hello, Will.

Hi, Nikita.

Hi.

Perhaps you could introduce yourself and um because you you you do lots more.

So tell us all about you and how you got into Django and things.

So I try to be involved into two things uh as closely as I can.

Uh I work on my py from time to time, and I also contribute to different other uh libraries like uh DryPython.

It is very, very uh type-heavy plugins uh to MyPy and to Python itself.

It really adds a lot of new ideas to regular Python.

You can use uh things like monads, higher kind of types, uh functional composition, uh and stuff like this from functional programming in your ordinary Python, and it will also type check your code with MyPy plugin.

So okay.

I use word container because it is really simple and it kind of looks like a container.

It's not a specific term, so it can mean anything by a container.

And that's what we do.

And so it is really easy to explain these new ideas to Python developers using friendly language, not uh complex one.

You you talked about functional programming.

So, you know, Python's it's kind of uh multi-paradigm.

You know, you can do object-oriented, you can do power, and it you know, there's there's um functional elements out of the that come out of the box, but it's not like programming in, I don't know, Haskell or Elm or other languages.

So the DryPython uh ecosystem that you're working in, yeah, that's that's part of that is about increasing functional programming that's available.

And um it also showcases that functional programming is not scary and it is really helpful and pragmatic.

You can solve real life problems with functional programming, with our abstractions and our ideas, and it is really easy.

For example, I use um functional programming for my dependency injunction.

I also uh provide examples with Django code, so it's quite relevant.

And um it is really easy because what you do in regular dependency injection is that you create some kind of containers, resolvers, and you have a lot of annotations and stuff like this.

With functional programming, you just call it function.

You have your regular uh codes and then you call a function and your dependencies are injected.

So this dependency injection word it always is what's that?

Well it's like well, you know, say you've got an object and it needs, I don't know, the database, you'd pass in the database, or if it needs the cache, you'd pass in the cache.

So it perhaps you could um perhaps you could say like for uh a listener like I I I go along, I do my Django in a normal in a normal way.

What would I get moving to a more functional style?

What what kind of benefits of a of a functional approach?

But you can express things like this function can write an exception, and you can specify which exceptions this function works with.

Uh, you can specify that this function needs some external state.

For example, it needs a database, and is it is as simple as just specifying a return type.

You just say that this function needs a database, and it will be composed sometime later with your actual application code, it would be type checked and it will be working.

And um, this is the very essential of this idea for me is that you can inject your ideas into your annotations and into your function functional declarations.

That's it

for me.

And if you, for example, forget to handle an exception, uh myPy will warn you about it.

The same um this this that same principle uh Rust uses.

And uh it proved to be a really easy and maintainable way of dealing with uh problems uh in your application.

Like did was that just you came from other languages, or what about what why Python and add that and you know work on that?

Uh my first language was C sharp.

Uh and then I switched to Java like in a year, and they're quite similar, so it was not a big deal.

And then I've tried Python, and uh I'm still happy with it because um Java 11 years ago, it is not the same Java we have right now, and this switch was kind of escaped from a lot of boilerplate code, XML, uh ugly IDS and ED IDES.

How can you pronounce this?

IDEs.

We have to think about it too.

Uh so yeah.

Okay.

And uh it is kind of similar to Python because it has a very similar syntax.

It is based on Ruby, and Ruby and Python are kind of similar, so it will be familiar for a lot of Python developers.

And uh Elixir is a very good programming language, it um it is really complex inside, but outside it is really really easy.

For example, um when you write uh your code in Elixir, it looks like you write Ruby, and Ruby is simple, no big deal.

But uh inside a lot of interesting things happen.

Uh all this Ruby code gets translated into uh some Lisp-like language that you can really use, and Elixir is not like uh Ruby-like, it is more like Lisp-like, but it is hidden from users.

And then you realize that you write uh sync code, but it is actually working as asynchronously, and that's just a boomer familiar.

And uh it also hides a lot of functional things away from you, and it looks like you are writing regular code, but it is functional.

And uh then I started to communicate a lot with the functional community here in Russian, and they turned to be great folks, and uh I really enjoyed functional conferences, uh ideas, and uh people.

So I started to learn new functional languages like Haskell and Sharp and stuff like this, and then I realized that all these languages do not solve a lot of problems Python does.

So I thought that it is a good idea to have a mix of both worlds and take uh good parts from both of them, and that was my initial initial motivation for Drive Python, and I think it worked pretty well.

Um, but I wondered if there's anything you wanted to add to that.

We're gonna link to that.

And the core idea of this uh post is that you can switch your IELTS stack uh based on your needs, and it is not something functional programming are not aware of.

Uh for example, in languages like Haskell you can or Scala, you can switch your I.O.

when you run your program.

You don't have to uh specify what kind of I.O.

synchronous synchronous or asynchronous is used.

You just specify it when you run your program and it works.

How does this relate to this the SANS IO um movement there is in in Python?

Because I I think in in the Python HTTP world people are interested in that.

Yeah.

Uh you you you cannot change uh is it function uh is this function async or not?

You can just change some implementation details.

It is important as well, but uh my post was about the next step.

So you've got um the and one of the issues with async code is that once you've declare one function as async, well then the calling function needs to be async, and then the calling function needs to be async and all the way up to the to the root and your whole program ends up being async, so you end up with these kind of um two worlds.

Uh, how do you um what do you think about the current state of uh two worlds in Python?

What do you think about sync and async works?

I made a joke tweet the other week about something like, oh, I'm trying to come back to the idea that threads are the you know the way forward in that.

Um I see a lot of people jumping onto the async bandwagon for use cases where it's perhaps not the complexity of it isn't justified.

And then that that they they struggle because it is more complex, and you do have to think through the calling structure of your program more clearly, and you do have to plan things in advance um more carefully.

And my kind of thought is that at the moment we don't have enough warning signs saying, hey, only to only only step over this this fence if you know if you need to.

Um I think we should have more signs saying, hey, you know what?

A threaded a threaded synchronous worker is perfectly acceptable for 99% of your of use cases and likely your use cases in there.

So consider before you come over here.

But if you're gonna come over here, welcome.

Um and and that's my worry at the moment, is async is very exciting and very new and very, oh, isn't this the way forward?

But I'm not convinced it is for a lot of use cases.

Um so to that's my answer to your question.

What what makes you ask?

Like, because that's an interesting question.

Uh fast fast API you can use async uh workers and async functions, and you can use sync functions and both are fine.

But in Django, things are not um async right now.

So I mean with um Django um three we had the ASCII um the ASCII handler, and then 3.1 we've got async um views, but um they're kind of constrained by um the the thread sensitivity of the ORM.

And so in Django 3.2 um the throughput is quite limited because essentially your your worker needs to be single-threaded because it it handles it needs to make sure that the ORM calls are all done in the right thread.

From Django 4.0 there will be um per request thread sensitivity per per thread context.

So that should mean that we've we can have one thread worker per per request, and it we should get some decent throughput increases, but this is still a um a progressive um progressive movement, and then the the next step will be making the ORM async compatible.

And it at that point then you start to think, yeah, we're we're um we should be more or less competitive.

But like it Django's goal here isn't to be the fastest async web framework.

Right?

Django's goal is to um is to offer you a kind of batteries-included solution.

So your 90% case is you know, just use Whiskey, just use the threaded workers that you've got, and that will cover your use case.

But if you need to step out for an async through an async view, because you need higher viewpoint throughput for some particular endpoint or something, you don't want to have to change web framework just to do that.

And so if we're if Django can have a nice solution there, then that's a success.

That's that's that's the win story.

And then there will always be specialist frameworks beyond that that go, you know, and then there'll be specialist language.

Like there comes a point that why are you even using Python?

Why aren't you using Rust or Go or you know something else?

Well Elixir.

I mean, why aren't you using Phoenix?

And you know.

Um so that that's my kind of thought on it is that Django is mature and stable and reliable, and it comes with all the things that um it comes with.

And adding async is like, yeah, it's that we don't you don't want to have to change web framework just to add an async view, you know.

That's why.

If you were in charge of Django in all respects, what would you do?

Uh my

No, no, no.

Uh I asked uh core developers of Django about adding types to Django itself several times, and I still think that it is a good idea because uh I see that some people fork my uh Django steps project uh just to make them compatible with different type checkers because we are focused on MyPy and we have a lot of boilerplate code that is required only for MyPy to work.

There are some issues with MyPy, so it's fine.

Um but adding this kind of stuff to Django itself will help a lot of developers get this um benefits uh from having type hints embedded in your application.

And this is something I would highly prioritize if if you ask me.

So uh and the second point uh is that Django offers a lot of uh ways to do some business logic things like uh create uh new queriesets for some specific tasks, create new managers for some specific tasks, and Django's approach is not something I really like because I have to uh re-educate a lot of developers

who come to work for me or who just uh want to be re-educated about business logic in Django.

It is something that a lot of people struggle with.

And I guess uh that we we as a Django community need some go-to solutions to common problems that are not embedded into Django itself and that are just suggested uh for the developers.

For example, if you have some business logic, put it here, structure it like this, um, do a dependency injection in this case, um, switch to some typed approach if your code is uh large enough and stuff like this.

That's yeah.

Okay, so let's let's which one do you want to talk about first?

I'd um let's talk with the business logic first.

I think that's a good point because you kind of have to learn to write a manager method that encapsulates your business, your object creation logic, so that you know it might be a query set method, but you like a lot a method that you're not just creating an object and calling save on it and forgetting to run you know the the the other logic that goes with that save call.

And may oh, maybe you put it in save, but then well, how do you save the model without creating that logic running that logic?

Ah it's and so you learn these things the hard way, right?

You you you do it wrong 50 times and then you come with a pattern that, oh, that works for me.

And you know, years later.

Um, is that not Will's job though, to you know, document the the patterns and you know guides, guides and books?

No, but uh basically

Right?

Because if you ask if you ask the community, it's like well it depends a bit on what your use case is, right?

Like Carlton, you have use cases.

I mean, I don't generally get into model managers at all, actually, even in the professionals book, because um I've ran out of space.

But if there is a trove of best ways to do it, I would add it.

Yeah.

Um right now there is no architectural consensus in Django community, and that's uh the problem I'm talking about.

Okay.

I think generally people would say you know, fat models and managers a little bit, but it yeah, there isn't a consensus.

I would agree with that beyond, you know, maybe pull it, pull it down as far as you can.

You don't want it in your templates, your views probably not so much, but how exactly do you models managers, that's where it gets a little squishy from what I see.

It is some simple exercise that's uh that you do to write better codes and to structure it better and to name things better.

And uh a lot of people ask me like how can you combine these two things, domain-driven design and Django?

I usually uh tell them that uh it is not related to your framework of choice, you can do it in any framework, in any code ecosystem you want.

But uh I think that is it is something Django should also address.

For example, how can you uh structure your uh application, Django applications?

How can you structure your logic inside these applications?

Uh, where should you put your boundaries between these applications?

And how can you check that uh these boundaries are not violated and they are respected?

So these kind of things I'm really thinking about lately.

Because everyone does it a little bit differently, but it you just just you personally, how do you like to do it?

You can call it bounded context, you can have it, you can call it subdomain, it it doesn't really matter at this point.

But uh in the end you will have some list of things that you need to implement.

For example, shop, accountants, marketing, stuff like this.

And I try to transfer these contexts as Django apps, uh separate separated Django apps, and sometimes I even forbid to import uh stuff from different contexts.

It might be it might have some exceptions, of course, because you can have some uh utility domains, you can have some shared domains, it depends, but uh most of the time they should be isolated.

And then I uh structure my application regularly, views, models, stuff like this.

Uh I keep all my views and models as simple as possible.

They do not have any business logic.

My model is like just fields and maybe as uh string method, that's it.

And uh my views is just calling some business logic function, and all my business logic lives in a special folder called logic, and then uh I start to structure this logic folder, and it really depends on what we do here.

Sometimes it is simple, it is uh just like three or four files uh with different names.

For example, this file is about some subcontext, uh, for example, about some employees, and uh the second one is uh some warehouses, for example, and stuff like this.

And I put everything inside, but then I use very specific technique uh to separate these files uh to be more readable, more maintainable, and all of this.

I call it uh complexity waterfall or complexity overflow, uh if you wish.

And uh I have a very strict linter uh enabled which can tell me uh when it is time to separate my uh module into several modules, and that's how I iterate my architecture.

I guess it goes without saying you're a function-based views person rather than a class-based views.

Yeah.

Carlton, what were you gonna say?

It's um massively difficult to know how to organize your application.

But I'm wondering how much of it is um a kind of documentation question, like you know, a an a sort of advanced guide versus you know what kind of um kind of code component, code structures might we add to the framework to enforce these kind of patterns.

I mean, it might be as a third-party package because you know, as you say, there's no consensus, but is it um a code problem or is it a documentation problem or a you know an explanation problem?

But uh there are a lot of techniques that I use to document my projects, and then when I know that my project is documented, I can tell whether this is uh documentation problem, architecture problem, or code problem.

But without this groundwork uh on documentation and uh clear business context, you cannot have this um separation clearly defined.

So I mean the criticism is or not criticism, but the comment the thing to improve in Django is the structuring of or the advice around structuring domain logic.

Um and obviously for it in my given application, I need to think about what I'm trying to build, but then what's the general stuff that the framework can deliver?

I always say that jungle's docs are perfect for beginners, and it is really easy to learn Jungle from its documentation, and that's a good thing, and I think it should stay this way.

But on the other hand, uh there are different problems when uh senior developers uh try to find their answers in this documentation that is written for not senior people, let's say it like this.

And uh there is a clear conflict here because when a person wants to know how to structure a code and their logic, uh it is something very opinionated uh and it is something uh that you cannot just give to everybody.

You have to struggle, as uh someone said, to learn the wrong ways before you learn uh correct ones.

And maybe it should be a complete new project, uh documentation project for some seasoned developers.

You know, there's lots of um there's been lots of books.

I mean Will Will's books are sort of the only current ones really, but there's lots of introductory material, and then there's some middle material, and then there's like and then there's blog posts of you know, from th I was cite um a Tom Christie post from about ten years ago.

It's like, well, but okay, that's ten years old.

Is there nothing newer?

Well, yes, there's a few one.

There's that one where so and so said something and then so and so replied, and uh yeah, but that's all kind of esoteric knowledge that you've you've got absorb from from time and the ecosystem.

It's not like, oh, if I need advanced, you know, Django modeling, where do I go?

I mean, of my books, the advanced one is the hardest to update.

I've got a way more feedback on it because I think it becomes a little a bit more opinionated in a in a real sense.

For beginners, I can just say, so function-based views versus class-based views, I can just sort of say we're gonna do one and a beginner will go along with me, but when it's these more advanced topics, it's harder to just wave a wand and say this is how to do it, even if there was consensus in the community around advanced techniques.

I think that's part of the issue.

I find it's much more subjective as it becomes more advanced.

I mean, I would love it to be less subjective.

I sort of, if there was agreement, I would just do it how the community wants and focus on other things, but I don't know that that's there.

Djangoe views on uh other community.

What do you think about that?

Oh what's it all?

I mean, but how do you push it?

I mean, the you know, I think you had said, you know, maybe there should be an advanced docs section.

I mean, one thing I think that works about the Django docs is it's very specific.

There's no over there's not really an overarching theory of business logic.

It's just this particular case.

I think people can agree on that, but if you if someone came in and said this is the advanced way to do something, I feel like there would be pushback around it.

Um that doesn't mean people, you know, a group can't just go off and say, This is our opinion on these advanced techniques.

That would be fantastic.

I just my sense is with the Django Docs, there's not as much of that.

So if if it's beyond a specific use case, it might be harder to get it through, but I don't know.

Don't know until you try.

I just think it's hard to put a lot of work into something that won't be accept necessarily accepted.

So maybe just saying having you know having a third-party package of advanced Django docs.

Um I don't know.

I'd love to see it.

I guess I just I'm not aware that there is a consensus, um, though I wish that there were.

Well, there you are.

So um

Um 404.

Then it grew uh in a different in a different route and uh right now it is more like functional programming stuff and uh it is not like about jenger architecture anymore, but this was uh really connected to this problem some time ago.

Well, let's cut back to the other dumb topic because Nikita, I mean, there's no reason why you shouldn't, you know, be a teeny bit more involved in the day-to-day, you know, what you know, not much goes on, but you know, the day-to-day that that's on the framework, and then come in and stand for the technical board and get elected to the technical board, and then make the case for why we

should have

He's been writing a lot of posts on typing on his blogs about C Bikine.

I mean, it came up what like a cycle ago.

And the technical board at the time said, after long discussion on there was a long discussion on GitHub, there was a draw, long discussion on the draft of a depth with a Django enhancement proposal, lots of just lots of discussion.

And then the technical board, I think they had a couple of main reasons.

One was the maturity of the typing um system, and then um two was this other point that you taught you talked about was that the the different typers and needing to, you know, needing to serve not just my pie, but you know, three or four different typing systems which aren't necessarily all compatible.

So, I mean, clearly you're you're a fan.

So what would be the you know, I'm a I'm a I'm a a jobbing Django developer.

Why, why should I adopt types?

Like what's the benefit for me?

And then how would we bring it in?

Like, would it what would that look like to actually bring types into Django?

And why can't they just live in stubs?

Because wasn't the idea that stubs files were equivalent?

Uh it is really hard to maintain stubs because uh you have to track all the changes in recent Django versions and apply uh the same changes to two code bases, and they live in different repositories and maintained by other people, so it is really hard.

Uh, one more problem is that uh for some reason uh current stub distribution uh is not really version dependent.

So you can have, for example, Django 2.2 and you can have stubs for Django 3.

And uh that's a big problem.

So when you run your type checking, myPy will tell that everything is fine.

You can call this method with these parameters, it's fine, but in runtime it will not work because you have a version with matchup between Django and stops.

We cannot maintain stops for different Django versions because uh this is a project run by a community.

I have a lot of uh pull requests with uh bug fixes, new features, and everything, but I am on the only person right now who maintains journal stops from day to day.

So uh my time is quite limited, so sorry.

I mean, and Django's

It's like wow, that's really impressive.

So don't don't apologize for the you know.

Uh, this is one of the most uh contributed projects uh in my experience.

It has like around 200 contributors, and so that's a big number.

Um so that's the first thing.

Uh it is really hard to maintain stops uh separated from the main project.

Uh the second uh point is that it is a good thing to add uh stops to the code base itself, because when you do that, uh you can detect bugs easier in the application itself.

You can run MyPy on Django, it will find a lot of maybe some bugs, maybe some false positives, and uh we can work from there.

Uh and uh one more thing is that when you have stubs and types inside your application, uh you you start to think differently about your code.

Uh for example, there are quite a few techniques that are really hard to type in Django, and uh they can be done differently, and it is something to consider when uh making technical decisions is that if this thing is hard to type or is it something simple to type?

And it can be a choosing factor between two different solutions.

But when you don't have this context, uh you don't think about this this way because Python is uh dynamic language, and a lot of people assume that a lot of dynamic behavior is a good thing, but then uh they struggle with it and there is no way back.

For example, uh I I will not give any examples right now because let

So, you know, typing brings any number of benefits, and it's you know, it is good when Wi-Fi goes, Oh, you need this here, and that's that, and you're like, oh brilliant, thank you.

And um but the contrast is um this kind of idea of that that one of the one of the great things about Python is that you sketch out your application and you know, you just knock open a file and you know you import a few things and you write a little function, and you and all of a sudden you've got this script and it's always 30 lines and it always does what you wanted.

It took you about an hour to write.

And that's whereas if you have to suddenly start, you know, you don't have to start typing in this context, but that kind of um ability to sketch your application in without the the sort of overhead of other languages, the boilerplate of other languages, is felt to be threatened and under threat.

So that's that that's kind of an aesthetic point.

But the the other one being that historically our the types that we accept are quite loose.

We accept, you know, well, it's meant to be a a request, but it could be an any because you know, as long as it looks like a request, it's gonna work.

Um is there gonna be a backwards compatibility issue with you know, starting to we you know, we start typing it, we go, well, do you know what this is or any, which isn't very pretty.

Um, should we tighten the behavior?

What are we to do then?

Are we to are we to tighten the behavior?

Are we to say, look, do you know what for the last 16 years this has taken pretty much anything in here, but from now on it's gonna want uh a request?

We can just uh we can just work with uh the developers who want to do that and they will respect uh our annotations and do what will what my pie will say to them.

And uh other developers can still use dynamic behaviors and not use my pie.

That's the goal of optional static typing, and that's the beauty of it.

I can just not not type check that bit, I can type ignore that.

Yeah.

Yeah, that's it.

And you can also type only your exterior, and this is fine as well.

You can use some typed uh exterior and dynamic interior, or vice versa, you can type only parts you need.

And uh this is something that is way cooler than just having dynamic typing, because when you're limited to some instrument, you uh just you just have to live with it.

But when you have a choice, you can uh use different types and different type systems depending on your task.

That's the beauty of a current Python.

And you think you think you know inlining type annotations in Django is a realistic and doable thing at this point?

Uh because there is no one to push this idea, uh and uh there is no community need uh for it to be in inside the Django itself.

So I guess it is going to stay this way.

Okay.

Like you know, I'm a fan, I like the types, I like typing, I like to use it, you know, and I I kind of see all number of places where ah, that would be nice if this was typed.

But what's the what's the USP?

What's the you know, why should we do it?

Why like

I I can repeat myself.

What do I mean?

Like on the one hand, you've made the case, on the other, you like you you don't think it'll happen because there's no community need.

I don't quite that's the that's the question.

What do you mean by there's no community need?

Uh community is quite happy with uh what they have right now because uh it works and it works for like 95%.

And when it does not work, you can put a type comment, uh type ignore, and it will work.

So um, but I think it is not more about um having some external typing, it is more about some architectural decisions and more about some uh correctness in the Django itself.

So that's why I think it will be a good idea to merge these projects at some point, but I'm not pushing it at any means.

Thank you.

Super.

Um wow, that's two really

If are there more typing things?

That's that's

So this is your consultancy, and then I guess dry labs is you teach, you you educate people.

Um, so I'll put it to you.

What do you want to say about both those since that's your day-to-day, right?

Is yeah, uh one

year ago I decided to uh like quit my own business because uh

Um but uh dry labs is so I can say for sure that it

is quite uncertain that uh quite I'm quite certain that I will not go into

uh web development, uh paid way development anymore, so I'm done.

Thanks.

Um I can even say that it helped me to be a happy person, so dry labs is a good thing, but uh I just don't uh sell a lot of uh consultancy and it just works from time to time and uh I'm happy with things are right now and uh if you want to have some advanced typing consultancy uh and some

advanced typing tutorials from me or from my team, you're more than welcome to contact me and we will figure things out.

A couple of summers ago you did the Google Summer of Code um for the MyPi plugin there, which went really well.

Kasper built that.

Um would you I mean you open to you were open to contributors, open to doing

Google Summer

Uh I had a lot of uh pleasant moments uh during Google Summer of Code.

Uh and uh Kasper did a really great job.

So thanks a lot for giving this chance.

And uh I'm more than welcome any contributors because it is a community project in the real sense of this world, in the real sense of this word.

Uh a lot of people contribute uh things that they find uh in types that are typed incorrectly, that are missing, uh, that can be done better.

So I just have to accept their contributions and merge them.

That's it.

That's what you do Carlton just too much.

But mostly it's uh I mean Nikita, do you have this thing?

I sometimes have this thing where I'm just like I haven't got the energy right now.

I have to just pause.

I have to pause.

I don't know.

Well, what else?

Is there anything I know we're sort of up on time.

Is there anything we haven't asked you that or you want to mention while we have a couple thousand people listening?

Follow me on GitHub and you'll uh you'll be on top of uh typing stuff in Python.

Have you signed up for that since you're doing open source?

Uh sorry, uh I'm I I'm not yeah oh GitHub sponsors.

yet, but uh you can sponsor uh DryPython organization and uh uh you can sponsor WeMake Services Organization.

Which one do you like best?

That's a good thing.

And since I'm doing my open source uh all the time, it really helps.

Uh but that's a whole another discussion about why people should sponsor some people on the internet doing some something they want.

I've heard Carlton speak of you for a long time, actually, probably related to that Google Summer of Code project, but he's he's such a huge fan of typing and and your work.

So it's very nice to finally meet you.

Thanks a lot for having me.

I listened from some episodes from time to time and I really enjoyed.

It's really nice.

I wanted to get you on because I wanted you to make the case and you know um we see how the you know how it evolves over time.

And of course, thanks a lot for both of you to uh for your jungle contributions.

And that's that's a really great job.

And uh I

That's my gratitude to you.

Brilliant.

Thank you again, Nikita.

Um with uh thank you for listening with uh Chat Django and uh Django chat.

Or Django chat and chat Django on Twitter.

That's it.

Join us next time.

Bye bye.

Bye bye.