Transcript: Django Stubs - Nikita Sobolev

Hi, welcome to another episode of Django Chat, a fortnightly podcast on the Django web framework.

I'm Carlton Gibson, joined us by Will Vinson.

Hello, Will.

Hi, Carlton.

Hello, Will.

And this week we've got with us Nikita Soboleth, who's creator of the Django Stubs plugin for

Django.

Hi, Nikita.

Hi.

I'm actually not the creator, but I'm the maintainer.

Okay.

Well, I know you from Django Stubs, but before we get into that, because I want to talk about

typing and you know everything around that in Django perhaps you could introduce yourself and

because you you do lots more so tell us all about you and how you got into Django and things

I really like two things right now in my professional career it is Python and typing

so I try to be involved into to the things as closely as I can I work on my Pi from

time to time and i also contribute to different other libraries like dry python it is very very

type heavy plugins to mypy and to python itself it really adds a lot of new ideas to regular python

you can use things like monads, higher kind of types,

functional composition, stuff like this from functional programming

in your ordinary Python,

and it will also type check your code with MyPyPlugin.

Okay.

So you just used a really scary word there.

You used the word monads.

Yeah.

I love that word.

You know, I dabble in functional programming.

What's a monad when it's on?

I don't know how to say it in English,

but monad is a monoid in the category of endofunctors, I guess.

I said when it was at home.

But actually, I don't use the word monad in my DrivePython tutorials.

I use the 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 a complex one.

Okay, so before we dig in, I want to just push slightly on what you've talked about there.

You talked about functional programs.

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

You know, you can do object-oriented, you can do, you know, there's functional elements 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 dry Python ecosystem that you're working in, part of that is about increasing functional programming that's available.

Yeah, yeah.

And 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 without abstractions and our ideas, and it is really easy.

For example, I use functional programming for my dependency injection.

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

And 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 a function.

You have your regular codes, and then you call a function,

and your dependencies are injected.

Yeah, and when you say injected, you mean passed as a parameter, right?

So this dependency injection, what's that?

Well, 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 perhaps you could say, like, for a listener,

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 my personal thing

that i really really like in this functional approach typed functional approach that you

can express a lot of ideas in your typing annotations not just regular ones like this

function accepts a string that's it but you can express things like this function can rise in

exception and you can specify which exceptions this function works with you can specify that

this function needs some external state for example it needs a database and this it is as

simple as just specifying a return type you just say that this function needs a database and it

will become composed sometime later with the actual application code it will be type checked

and it will be working and this is the very essential of this idea for me is that you can

inject your ideas into your annotations and into your functional functional declarations

that's it for me and is that is that just a purely documentation advantage or is that a

Is that code safety as well?

It is a code safety feature because, as I said,

MyPy can check all these things.

And if you, for example, forget to handle an exception,

MyPy will warn you about it.

The same principle Rust uses.

And it proved to be a really easy and maintainable way

of dealing with problems in the application.

Can I ask you personally,

how did you get into the functional world

and static typing?

Was that just you came from other languages

or what about why Python and work on that?

That's a really interesting story.

My first language was C Sharp.

And then I switched to Java in a year

and they're quite similar.

so it was not a big deal and then i've tried python and i'm still happy with it because

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 ugly id ideas and ed ideas how can you pronounce

so yeah and then maybe like five years ago i fell in love with a programming language called elixir

okay and 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 elixir is a very good programming language it it is really complex inside

but outside it is really really easy for example when you write your codes in

elixir it looks like you write Ruby and Ruby simple no big deal but inside a lot

of interesting things happen. All this Ruby code gets translated into some

Lisp-like language that you can really use and Elixir is not like Ruby-like it

is more like Lisp-like but it is hidden from users and then you realize that you

write sync code but it is actually working as asynchronously and that's

just a boomer familiar and and 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 then I started to communicate a lot of functional

community here in Russia and they turn to be great folks and I really enjoyed

functional conferences ideas and people so I started to learn new functional

languages like Haskell F 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 good parts from both of them.

And that was my initial motivation for DrivePython.

And I think it worked pretty well.

So I like what you said about async because I wanted to ask you on your personal site,

you have a post called how async should have been with a lot of code examples.

And I assume that comes from, you know, it's basically functional.

But I wondered if there's anything you wanted to add to that.

We're going to link to that.

That was a really interesting post to read.

Thanks for asking because it is really a piece that I'm really proud of

because this was really hard to achieve in Python.

And the core idea of this post is that you can switch your IELTS tag

based on your needs.

and it is not something functional programming are not aware of.

For example, in languages like Haskell or Scala,

you can switch your I.O. when you run your program.

You don't have to specify what kind of I.O. synchronous or asynchronous is used.

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

That's a wild idea.

And can I ask how does this relate to the Sans I.O. movement there is in Python?

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

Yeah, it is kind of related, but I think the core idea of Sans I.O. is that you can change your implementation.

You cannot change, is this function a sync or not?

You can just change some implementation details.

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

Okay, because you, I mean, there's that influential post

about what color is your function.

So you've got, and one of the issues with async code

is that once you 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 root.

Your whole program ends up being async,

So you end up with these kind of two worlds.

I want to ask you a question.

How do you, what do you think about the current state of two worlds in Python?

What do you think about syncing and passing words?

That's a good question.

I made a joke tweet the other week about something like,

oh, I'm starting to come back to the idea that threads are the way forward.

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 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 more carefully.

And my kind of thought is that at the moment we don't have enough warning signs saying

hey, only step over this fence.

if you need to, I think we should have more signs saying,

hey, you know what, a threaded synchronous worker

is perfectly acceptable for 99% of use cases

and likely your use case is in there,

so consider before you come over here.

But if you're going to come over here, welcome.

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.

So that's my answer to your question.

What makes you ask?

Because that's an interesting question.

Because Django right now is in the position

where a lot of new competitors arise, like...

Fast API or whatever.

Fast API.

And quite a lot of them offer both worlds.

Fast API, you can use async workers and async functions,

and you can use sync functions, and both are fine.

But in Django, things are not async right now.

No, it's still under development.

So, I mean, with Django 3, we had the ASCII handler,

and then 3.1, we've got async views,

but they're kind of constrained by the thread sensitivity of the ORM.

And so in Django 3.2, the throughput is quite limited

because essentially your worker needs to be single-threaded

because it needs to make sure that the ORM calls are all done in the right thread.

From Django 4.0, there will be per-request thread sensitivity,

per-thread context.

So that should mean that we can have one thread worker per request

and we should get some decent throughput increases.

But this is still a progressive movement.

And then the next step will be making the ORM async compatible.

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

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

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

So your 90% case is 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 view because you need higher throughput for some particular endpoint or something, you don't want to have to change web framework just to do that.

And so 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 rustle go or you know something else well elixir yeah or

elixir yeah 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

it comes with and adding async is like yeah it's that we don't want to have to change web framework

just to add an async view you know that's why what do you think nikita if you were in charge

of django in all respects what would you do i actually had this conversation with several

python developers and we were joking about my political campaign for the next jungle

elections uh my are you are you gonna run no no no it was just joking but

there were realistic jokes about ideas i have

i asked core developers of django about adding types to django itself several times and i still

think that it is a good idea because i see that some people fork my django steps project

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 but adding this kind of stuff to django itself will help a lot of developers get

this benefits from having type hints embedded in your application and this is

something I would highly prioritize if you ask me so and the second point that

Django offers a lot of ways to do some business logic things like create new

query sets 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 re-educate a lot of developers who come to work for me just want to be

re-educated about business logic in Django it is something that's a lot of

people struggle with and I guess that 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 for the developers for example if you have business logic

put it here structure it like this do a dependency injection in this case switch

to some typed approach if your code is large enough

and stuff like this.

There's two, well, that's the two, yeah.

Yeah.

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

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 like a method

that you're not just creating an object

and calling save on it

and forgetting to run the other logic

that goes with that save call.

Oh, maybe you put it in save,

but then how do you save the model

without creating that logic?

And so you learn these things the hard way, right?

You do it wrong 50 times

and then you come up with a pattern

that, oh, that works for me,

and years later.

Is that not Will's job, though,

to you know document the patterns and you know guides guides and books and yeah i just listened

to smarter people like you to talk and then i rewrite it for beginners no but basically i guess

the great but no it's true but how do you how do you how do you know how do you know to do that

without having the pain of doing it wrong 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 I ran out of space but if there is a trove of best

ways to do it I would add it it is not not about just managers it is about how

you write write your fat models or slim models and it's how about you write your

use and what you do in this we use and stuff like this yeah right now there is no architectural

consensus in django community and that's yeah problem i'm talking about okay well there's i

mean there's even a post on the django forum i added i think a year ago about where do you put

the logic in your django project apps and it's there's a lot of answers i think generally people

would say 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 and that's where a domain driven design comes in because

a lot of people are starting to understand that it is not something like complex and

something that is out of their understanding it is some simple exercise that's that you do to

write better codes and to structure it better and to name things better and a lot of people

ask me like how can you combine these two things the main driven design and Django I usually tell

them that it is not related to a framework of choice you can do it in any framework in any

code ecosystem you want but I think that is it is something Django should also address for example

How can you structure your general applications?

How can you structure your logic inside these applications?

Where should you put your boundaries between these applications?

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

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

The question I've started asking guests is, how do you, so you run an agency, which we'll talk about, how do you like to structure your Django projects and apps?

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

I start with business context, and I spend some time asking different companies what contexts do they have for this application.

you can call it bounded context you can have it you can call it subdomain it doesn't really matter

at this point but 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 stuff from

different contexts it might be it might have some exceptions of course because you can have some

utility domains you can have some right shared domains it depends but most of the time

there should be isolated and then i structure my application regularly views models stuff like this

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 string method that's it and my views is just calling some

business logic function and all my business logic lives in a special folder called logic and then

i start to structure this logic folder and it really depends on what we do here sometimes it

is simple it is just like three or four files with different names for example this file

is about some subcontext for example about some employees and the second one

is some warehouses for example and stuff like this and I put everything inside

but then I use very specific technique to separate these files

to be more readable, more maintainable, and all of this.

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

And I have a very strict linter enabled,

which can tell me when it is time to separate my module into several modules.

And that's how I iterate my architecture.

That's really interesting. I guess it goes without saying you're a function-based views

person rather than a class-based views. Yeah. Just had to check.

Carlton, what were you going to say?

Yeah. I mean, I kind of totally agree. It's massively difficult to know how to

organize your application, but I'm wondering how much of it is a kind of documentation

question like you know 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

uh that's a really hard question for me because i really love documentation and

i spend quite a lot of time writing it both for open source projects and closed source projects

but i try to distance from closed source project and spend most of my time on open source but

there 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 a documentation problem architecture problem or

problem but without this groundwork on documentation and clear business context you

cannot have this separation clearly defined.

But I'm just wondering what we might add to a Django.

So, I mean, the criticism is,

not criticism, but the comment,

the thing to improve in Django is

the structuring of,

or the advice around structuring domain logic.

And obviously for 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?

Maybe we can formulate this as some advanced documentation,

because right now documentation is great.

I always say that Django's docs are perfect for beginners,

and it is really easy to learn Django from its documentation,

and that's a good thing, and I think it should stay this way.

But on the other hand, there are different problems

when senior developers try to find their answers

in this documentation that is written

for not senior people, let's say it like this.

And there is a clear conflict here

because when a person wants to know

how to structure a code and their logic,

it is something very opinionated

and it is something

that you cannot

just give to everybody

you have to struggle as

someone said

to learn the wrong ways before you learn

the correct ones

and maybe it should

be a complete new project

documentation project

for some seasoned developers

I mean it's one thing I think

perhaps missing is like really advanced

books

in the jungle 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

i was cite um a tom christie post from about 10 years ago it's like well but okay that's 10 years

old is there nothing new well yes there's a few one there's that one where so-and-so said something

and then so and so replied and yeah but that's all kind of esoteric knowledge that you've you

got absorb from time in the ecosystem it's not like oh if i need advanced you know django modeling

where do i go it's hard to write advanced stuff too i mean of my books the advanced one is the

hardest to update i've got way more feedback on it because i think it becomes a bit more opinionated

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 going to 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 maybe uh some jungle developers

can push their jungle way views on other communities what do you think about that

what do you mean i think everyone should write everything i mean but how do you push it i mean

And, 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 not really an overarching theory of business logic.

It's just this particular case.

I think people can agree on that.

But if someone came in and said, this is the advanced way to do something, I feel like there would be pushback around it.

That doesn't mean, 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 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 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 but maybe that's because nobody's documented

it so um dry python uh started as a project to solve this django architectural problem

because my co-worker and a friend

and ex-Jungle core developer

Artyom Malyshev

Proofit44

404

he started his project

called Dry Python Stories

to solve this architectural problem

to create a single way

to express the business logic.

Then it grew in a different route.

And right now it is more like functional programming stuff.

And it's not like about Django architecture anymore.

But this was really connected to this problem some time ago.

Interesting.

Well, let's cut back to the other 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, not much goes on, but, you know, the day-to-day 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 types.

because, you know, Adam Johnson, he's a current technical board member.

He may stand, he's likely to stand again.

He's been writing a lot of posts on typing, on his blogs,

or perhaps he'd be keen.

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 long discussion on the draft of a DEP,

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 system.

And then two was this other point that you talked about was that the different typers and needing to, you know, needing to serve not just MyPy, but, you know, three or four different typing systems, which aren't necessarily all compatible.

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

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

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 yeah I will start from there from the end of the question

it is really hard to maintain stubs because you have to track all the changes in recent

Django versions and apply the same changes to two code bases and they live

in different repositories and maintained by other people so it is really hard.

One more problem is that for some reason current stub distribution is not really

version dependent so you can have for example Django 2.2 and you can have

stubs for Django 3 and 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 mismatch between Django and stubs we cannot maintain stubs for

different Django versions because

this is a project run by a community

I have a lot of

pull requests with

bug fixes, new features

and everything but I am

the only person right now

who maintains Django stops from day to day

so

my time is quite limited so

sorry

you needn't apologize, you do a fantastic job

I mean in Django

you're talking to one of the few people who can

relate to that, Carlton, not me

Like Django Stubs is a phenomenal project and you've done a phenomenal thing. And the, you know, the way it works is just, you know, it's truly awe-inspiring. It's like, wow, that's really impressive. So don't apologize for that, you know.

Yeah, I want to highlight the community work on it because it is really amazing.

This is one of the most contributed projects in my experience.

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

So that's the first thing.

It is really hard to maintain stops separated from the main project.

The second point is that it is a good thing to add stops to the code base itself,

because when you do that, you can detect bugs easier in the application itself.

You can run mypy on Django, and it will find a lot of, maybe some bugs,

maybe some false positives, and we can work from there.

one more thing is that when you have stubs and types inside your

application you you start to think differently about your code for example there are quite a

few techniques that are really hard to type in django and they can be done differently and

it is something to consider when making technical decisions is that if this thing

it's 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 you

don't think about this this way because Python is dynamic language and a lot of

people assume that a lot of dynamic behavior is a good thing but then they

struggle with it and there is no way back for example uh i will not give any examples right

now because let me just cut let me just cut in there because the dynamic the dynamic dynamism

is the is the sort of thing 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 the one of the one of the great things

about python is that you sketch out your application and you 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 want 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 on 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 kind of an aesthetic point but the other

one being that historically are the types that we accept are quite loose we accept you know well

it's meant to be a request but it could be an any because you know as long as it looks like a request

it's going to work um is there going to be a backwards compatibility issue with you know

starting to we you know we start typing it we go 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 going to want a request the cool thing here is that we

don't force developers to actually follow these annotations we can just

we can just work with the developers who want to do that and they will respect our annotations and

to what MyPy will say to them.

And other developers can still use dynamic behaviors

and not use MyPy.

That's the goal of optional static typing.

That's the beauty of it.

So I'm imagining that I've got a genuine use case

where I want to make use of duck typing.

I can just not type check that bit.

I can type ignore that.

Yeah.

It is as easy as writing a Nokia comment.

Yeah.

That's it.

You can ignore the whole file, for example,

if you do some crazy stuff in there.

So that's fine too.

And you can also type only your exterior.

And this is fine as well.

You can use some typed exterior and dynamic interior or vice versa.

You can type only parts you need.

And this is something that is way cooler than just having dynamic typing.

Because when you're limited to some instrument, you just have to live with it.

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

That's the beauty of current Python.

Okay. And you think inlining type annotations in Django

is a realistic and doable thing at this point?

I don't think so.

Because there is no one to push this idea

and there is no community need for it to be inside the Django itself.

So I guess it is going to stay this way.

okay but you think that's okay so but what's the selling point 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

he just said that carlton i think right i can repeat myself what do i mean what do i mean like

on the one hand you've made the case on the other you like 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 there is no community need in having uh these projects uh in the same place

community is quite happy with what they have

right now because

it works and it works for

like 95%

and when it does not work you can put a type

comment, type ignore and it will

work

but I think

it is not more about

having some

external typing, it is more about

some architectural

decisions and more about

some

correctness in the Django itself

so that's why I think

it will be a good idea to merge

these two projects at some point but

I'm not

pushing it at any means

Okay, interesting, thank you, super

Wow

That's two really good

I had two things that are non-typing

Are there more typing things?

No, that's cool

Well I just wanted to ask about

WeMakeServices and DryLabs

so this is your consultancy and then i guess dry labs is you teach 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 um one year ago i decided to like quit my own business because

I've decided to contribute all my time to open source projects and right now I'm doing exactly

that but dry labs is so I can say for sure that it is quite uncertain that quite I'm quite certain

that i will not go into web development paid web development anymore so i'm done thanks

but i really like to teach it is something i enjoy and it does not bother me at all

i can even say that it helped me to be a happy person so dry labs is a good thing but

i just don't sell a lot of consultancy and it just works from time to time and i'm happy with

things are right now and if you want to have some advanced typing consultancy 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 and i had one more topic to ask was about uh um the janga stabs project and um

whether you'd look for more contributors a couple of summers ago you did the google summer of code

um for the mic by plug-in there which went really well casper built that um would you i mean you're

open to you were open to contributors open to doing google summer code again type thing if

yeah yeah it was great uh i had a lot of uh pleasant moments uh during google summer of code

and cosper did a really great job uh so his contributions are like

the re in the real heart of the project it's my pipe plugin so thanks a lot for giving this chance

And 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.

A lot of people contribute things that they find in types that are typed incorrectly,

that are missing, that can be done better.

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

That's it.

Just like Carlton, right?

Yeah, I just kick, merge, merge, merge, merge, merge, but mostly it's...

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 can't, you

know, I can't give your PR the time it needs to click the button because I need to think

about, I mean, how do you manage that kind of ongoing time commitment, I guess, and emotional

commitment it is?

I don't know.

fair enough you just keep going yeah well what else is 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 be on top of typing stuff in python and can they

sponsor you on github have you signed up for that since you're doing open source uh sorry uh i'm i'm

not yeah github sponsors no i'm not on github sponsors because it is not available in russia

yet but uh you can sponsor sponsor dry python organization and you can sponsor sponsor we

make services organization which one do you like best that's a good thing and since i'm doing my

open source all the time it really helps but that's a whole another discussion about

why people should sponsor some people on the internet

doing something they want.

Well, I'm really happy to meet you.

I've heard Carlton speak of you for a long time, actually,

probably related to that Google Summer of Code project,

but he's such a huge fan of typing and your work,

so it's very nice to finally meet you.

Thanks a lot for having me.

It was a really big deal for me to speak on Django Chat.

I listened to some episodes from time to time

and I really enjoyed it.

So thanks for coming on.

It's really nice.

I wanted to get you on

because I wanted you to make the case

and we see how it evolves over time.

And of course, thanks a lot for both of you

for your Django contributions.

And that's a really great job.

And I really, really love Django

and it is my go-to framework.

that's my gratitude to you

so but what

anyways Carlton

can you read us out

brilliant well okay

thank you again Nikita

with

thank you for listening

with

chat Django

and Django chat

or Django chat

and chat Django on Twitter

that's it

join us next time

bye bye

bye bye