Nikita is an open-source developer who maintains the Django-stubs package bringing type stubs to Django. We discuss why static typing is so powerful, the benefits of functional programming, and best practices for organizing logic within a Django project.
This podcast does not have any ads or sponsors. To support the show, please consider visiting LearnDjango.com, Button, or Django News.
Carlton Gibson 0:06
Hi. Welcome to another episode of Django chat fortnightly podcast on the Django web framework. I'm Carlton Gibson joined by Will Vincent. Hello Will!
Will Vincent 0:12
Hi, Carlton.
Carlton Gibson 0:13
Hello, Will, and this week we've got with us Nikita Sobolev, who's creator of the django stubs plugin for Django. Hi, Nikita.
Nikita Sobolev 0:21
Hi. I'm actually not the creator, but I'm the maintainer.
Carlton Gibson 0:25
Okay. Well, I know you from Django, Django stubs. But before we get into that, I want to talk about typing and you know, everything around that in Django, perhaps you could introduce yourself, and because you do lots more, so tell us all about who you are and how you got into Django. And thanks.
Nikita Sobolev 0:41
I really like two things right now, in my professional career is Python and typing. So I tried to be involved into to the things as close 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 mine pi. 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 tie check your code with my PI plugin. So
Carlton Gibson 1:37
okay, so you just use really scary word. They're used word mon ads, what that word, you know, I dabble in functional programming. But you know, what's a monad? When,
Nikita Sobolev 1:47
when it's, I don't know how to say it in English. But more than is a monoidal. category of endo from endo functors, I guess.
Carlton Gibson 1:56
I said when it was.
Nikita Sobolev 2:00
But actually, I don't use word mon at my dry Python tutorials, I use word container because it is really simple. And it kind of looks like a container. It's not a specific term. So we can mean anything by a container. And that's what we do. And it is really easy to explain these new ideas to Python developers using friendly language not complex one.
Carlton Gibson 2:26
Okay, so before we dig in, I want to just push slightly on what you've talked about, you talked about functional product. So you know, pythons. It's kind of multi paradigm. You know, you can do object oriented, you can do any, you know, this, this functional elements out of the come out of the box, but it's not like programming it. I know, Haskell or Elmo. Other language. So the dry Python ecosystem that you're working in? Yeah, that's, that's part of that is about increasing functional programming that's available. Yeah.
Nikita Sobolev 2:57
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 with our abstractions and our ideas. And it is really easy. For example, I use functional programming for my dependency injection, I also provide examples with Jango 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 I injected
Carlton Gibson 3:45
Yeah. And when you say injected, you mean passed as a parameter, right? So yeah, this dependency injection, where it is what's that was like, Well, you know, say you've got an object and it needs, I don't know, the database, you pass in the database, or if it needs the cache, you'd pass in the cache. So it perhaps you could publish, you could say, like, for a list node, like I go along, I do my Django normal in a normal way, what would I get moving to a more functional style kind of benefits of a of a functional approach.
Nikita Sobolev 4:17
My personal thing that I really, really like in this functional approach, typed functional approach is 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 raise an 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 is as simple as just specifying the return type. You just say that these 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 that you can inject your ideas into your annotations and into your function, function declaration declarations less.
Carlton Gibson 5:21
And is that is that just a purely documentation advantage? Or is that a is a code safety as well.
Nikita Sobolev 5:30
It is called safety future because, as I said, my PI can check all these things. And if you, for example, forget to handle an exception, my PI will warn you about it the same. This, this is that same principle, rust uses. And it proved to be really easy and maintainable way of dealing with problems in your application.
Will Vincent 5:58
Can I ask you, you personally? How did you get into this, you know, the functional world or in static typing? Like did was that just you came from other languages? Or what about why Python and add that and you know, work on that?
Nikita Sobolev 6:14
That's a really interesting story. My first language was C sharp. 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 I'm still happy with it. Because Java 11 years ago, which is not the same Java we have right now. And this switch was kind of escaped from a lot of boilerplate code, XML aguaje It ideas, eg ions, he he is, how can you pronounce the idea?
Will Vincent 6:55
We have to think about it too.
Nikita Sobolev 6:58
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 is really complex, inside, but outside, it is really, really easy. For example, when you write your code 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 least like but it is hidden from users. And then you realize that your rights sync code, but it is actually working as a synchronously. And that's just the boomer formula. And it also hides a lot of functional things await from you. And it looks like you're writing regular code, but it is functional. And then I started to communicate a lot with functional community here and Russian. And they tend 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 this languages did 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's was my initial initial motivation for dry Python. And I think it's worked pretty well.
Will Vincent 9:17
And so I like what you said about async. Because I wanted to ask you and 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 want to add to that. We're going to link to that that was a really interesting post to read.
Nikita Sobolev 9:37
Thanks for asking because it was 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 the IO stack based on your needs and it is not something functional programming are not aware of, for example, in languages like Haskell, you can or Scala, you can switch your IO, when you run your program. You don't have to specify what kind of IO synchronous, synchronous or asynchronous is used. You just specified when you're on your program. And it works.
Will Vincent 10:22
That's a, that's a wild idea.
Carlton Gibson 10:25
And can I ask how this does this relate? How does this relate to this? The sands IO movement there is in in Python, because I think in the Python HTTP world, people are interested in
Nikita Sobolev 10:38
Yeah, it is kind of related. But I think the core idea of Sanza yo, yo, that you can change your implementation. Yeah, it cannot change. Is it function? Is this function a sync or not? You can just change some implementation details is important as well. But my posts were about the next step.
Carlton Gibson 11:00
Okay. Because you, I mean, there's that influential posts about what color is your function, so you've got that, 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, to the root, your whole program ends up being async. So you end up with these kind of two worlds,
Nikita Sobolev 11:24
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 async?
Carlton Gibson 11:36
That's a good question. I made a joke tweet the other week about something like I'm saying, to come back to the idea, that thread said, you know, the way forward and 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 they, they struggle, because it is more complex. And you do have to think through the calling structure of your 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 sign saying, hey, only to only only step over this, this fence, if you know if you need to, I think we should have more more science, hey, you know what? A thread it's 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 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 quit. What makes you ask like, because that's an interesting question.
Nikita Sobolev 12:49
Because Django right now, it is in the position where a lot of new competitors arise like fast IPO, whatever flies that faster bi, and quite a lot of them offer both world's world's first first API, you can use async workers and async functions. And you can use sync functions, and both are fine. By the Django. Things are not sync right now. No,
Carlton Gibson 13:23
it's still under development. So I mean, with Django, three, we had the ASCII, the ASCII handler, and then 3.1, we've got async views, but they're kind of constrained by the the thread sensitivity of the LRM. And so in in Django 3.2, the throughput is quite limited, because essentially, your worker needs to be single threaded, because 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 per request thread sensitivity at a very high context. So that should mean that we can have one thread worker per, per request, and we should get some decent throughput increases, but this is still a progressive, progressive movement. And then the next step will be making the LRM async compatible and at that point, then you start to think Yeah, we were we should be more or less competitive, but like it. Django is goal here isn't to be the fastest async web framework at Django. His goal is to is to offer you a kind of batteries included solution. So you're 90% cases, 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 viewport 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 wind story. And then there will always be specialist frameworks beyond that, that go, you know, and then there's be specialist language like, there comes a point. Why are you even using Python? Why aren't you using rust or go or you know, something else?
Will Vincent 15:17
Well, elixir?
Carlton Gibson 15:18
Yeah, or Alexa? Yeah. I mean, why aren't using Phoenix and you know. 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 didn't you don't want to have to change web framework just to add an async view, you know, that's why,
Will Vincent 15:42
what do you think, Nikita? If you were in charge of Django, in all respects, what would you do?
Nikita Sobolev 15:47
I actually had this conversation with several Python developers. And we were joking about my political campaign for the next Jungen elections. My
Will Vincent 16:01
thought, are you are you going to run? No, no,
Nikita Sobolev 16:03
no, it was just joking. But there were realistic jokes about ideas I have. I asked the core developers of Jenga belts adding types, to Django itself several times. And I still think that it is a good idea, because I see that some people for my Jenga Steps project, just to make them compatible with different type checkers, because we are focused on my PI. And we have a lot of boilerplate code that is required only for my PI to work. There are some issues with my pi. So that'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 the 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 creates new, curious ads for some specific tasks, create new managers for some specific tasks. And Django approach is not something I really like, because I have to re educate a lot of developers who come to work for me, who just want to be re educated about business logic, in general, it is something that a lot of people struggle with. And I guess that's, 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 some business logic, put here structured like this, do a dependency injection, in this case, switch to some types approach, if your cord is large enough and stuff stuff like this
Carlton Gibson 18:17
to us? And then that's, that's the two Yes. Yeah. Okay, so let's this, which one do you want to talk about? First, let's start 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 lot a method that you're not just creating an object and calling save on it and forgetting to run, you know, 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? And so you learn these things the hard way, right? You do it wrong 50 times, and then you come with a pattern that, that works for me. And, you know, years later, is that not Will's job, though, to you know, document that the patterns and, you know, guide guides and books and
Will Vincent 19:12
yeah, I just listened to smarter people like you to talk and then I rewrite it for beginners. Basically, I guess, I know 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 cases 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
Nikita Sobolev 19:49
up. It is not about just managers is about how you write write your fat models or slim models. It is how about you write your view And what do you do in this? We use stuff like this. Right now, there is no architectural consensus in Django community. That's your problem I'm talking about. Okay.
Will Vincent 20:15
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 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,
Nikita Sobolev 20:49
that's where 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 the understanding, it is some simple exercises that you do to write better code and to structured better and to name things better. And a lot of people asked me, like, how can you combine these two things, the main room design and Django? I usually tell them that 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 application Django applications? How can you structure your logic inside this applications? Where should you put your boundaries between these applications? And how can you check that these boundaries are not violated and they're respected? So this kind of things I'm really thinking about lately.
Will Vincent 22:11
The question I've 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 you're just just you personally, how do you like to do it?
Nikita Sobolev 22:24
I start with the 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 sub domain, 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 tried to transfer these contexts as Django apps, separate separating 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 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 s string method. That's it. And my views is just calling some business logic function. And all my business logic leaves 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 sub context, 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 of flow, if we 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.
Will Vincent 24:59
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 the check. Carlton, are you gonna say?
Carlton Gibson 25:14
Yeah, I mean, I, I kind of totally agree it's massively difficult to know how to organize your application by 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 code component code structures, might we add to the framework to enforce these kinds 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 a code problem? Or is it a documentation problem? Or, you know, an explanation problem?
Nikita Sobolev 25:49
That's a really hard question for me, because I really love documentation. And I spend quite a lot of time writing in both for open source projects and closed source projects. But I tried to distance from a closed source project and spend most of my time on open source. But there, there are a lot of techniques that are used to document my projects. And then when I know that my project is documented, I can tell whether this is documentation problem, architecture problem or call problem. But without this groundwork, on documentation, and clear reasons contexts, he cannot have this separation, clear and defined.
Carlton Gibson 26:40
But I'm just wondering what we might add to Django. So that I mean, the criticism is not criticism. But the comment, the thing to improve in Django is the structuring of 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?
Nikita Sobolev 27:02
Maybe we can formulate this as some advanced documentation, because right now, your communication is great. I always say that jungles looking ducks 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 codes 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 to communication projects. For some seasoned developers.
Carlton Gibson 28:19
That means one thing I think that's missing is like really advanced books. In the Django, you know, there's lots of there's been lots of books and mean, will wills books that 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 light, and then there's blog posts of, you know, from I was site, Tom Christie post from about 10 years ago. It's like, Well, 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 someone's I replied, and, but that's all kind of esoteric knowledge that you've got absorb from time in the ecosystem. It's not like, Oh, if I need advanced, you know, Django modeling, where do I go?
Will Vincent 29:07
It's hard to write advanced stuff, too. I mean, of my books that 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 of 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.
Nikita Sobolev 29:56
Maybe some Django developers can push the John GUI views on other community. What do you think about that?
Carlton Gibson 30:07
Oh, yeah. What's your mean?
Will Vincent 30:10
I think everyone should write everything. I mean, but how do you push it? I mean, you know, I think you had said, you know, maybe there should be an advanced Doc's section. I mean, one thing I think that works about the Django Doc's 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 will 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 of the Django Doc's, 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 accepted, necessarily accepted. So maybe just saying, having, you know, having a third party package of advanced Django Doc's? I don't know, I'd love to see it. I guess I just I'm not aware that there is a consensus, though I wish that there were, well, there you go. Maybe that's because nobody's documented it. So
Nikita Sobolev 31:20
Dr. Items started as a project to solve this Django architectural problem. Because my coworker, coworker, and friend, and ex Django, core developer, or Jamal chef proof, it's 44 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 different, different routes. And right now, there's more like functional programming stuff. And it's not like about Jenga architecture anymore. But this was really connected to this problem. And some time ago.
Carlton Gibson 32:19
Interesting. 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, 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 tech current technical member, he may stand eat lightly to stand again, he's been writing a lot of posts on typing on his blogs, or perhaps he became, 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, that was a long discussion on the draft of adapt 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 system. And then, two was this other point that you taught, you talked about was the different typers and needing to, you know, needing to serve not just my PI, 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 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?
Nikita Sobolev 33:53
Yeah. I will start from there. But from the ends of the question, it is really hard to maintain stops, because you have to track all the changes in recent Django versions, and apply the same changes to two code bases. And they leave in different repositories and maintained by other people. So it is really hard. One more problem is that for some reason, current stop. Distribution is not really version dependent. So you can have, for example, Django 2.2. And you can have stubs for Django, three. And that's a big problem. So when you're around your type checking, my PI will tell that everything is fine. You can call this method these parameters, it's fine. But in runtime, it will not work because you have a version mismatch between Django stops. We cannot maintain stops for different language versions because this is perfect. drawn by community, I have a lot of pull requests with bug fixes new features, and everything. But I'm the only person right now who maintains German stops from day to day. So my time is quite limited. So sorry.
Carlton Gibson 35:19
Apologize, you do a fantastic job. I mean, Django,
Will Vincent 35:22
you're talking to like the one one of the few people who can relate to that. And Carlton,
Carlton Gibson 35:27
like Django subs is a phenomenal project, and you've done phenomenal thing. And the, you know, the way it works is just, you know, it's truly orange boring. It's like, wow, that's really impressive. So don't don't apologize for it. Yeah,
Nikita Sobolev 35:43
I want to highlight the coming into work on it, because it is really amazing. This is one of the most conservative projects, in my experience, which has like, maybe 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, code base itself. Because when you do that, you can detect bugs easier in the application itself, you can run my PI on Django, and it will find a lot of maybe some bugs, maybe some false positives, and we can work from there. And 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 is something to consider when making technical decisions is that it 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, you don't think about this this way, because Python is a dynamic language. And a lot of people assume that a lot of dynamic behavior is a good thing. But man, they struggle with it. And there is no way back, for example. I will not give any examples right now. Because
Carlton Gibson 37:45
let me just cut just cut in there. Because the dynamic the dynamic dynamism is that 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 stat and you're like, all off. Brilliant, thank you. And but the contrast is 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 know, you just knock open a file, and 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 in this context. But that kind of ability to sketch your application in. Without the this or the overhead of other languages, the boilerplate of other languages, is felt to be threatened and under threat. So that is 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 gonna work. It's going to be a backwards compatibility issue with, you know, starting to we, you know, we start typing it, we go away, do you know what this is already, which isn't very pretty. Should we tighten the behavior? What are we to do that? Are we too? 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 a request.
Nikita Sobolev 39:25
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 do what we will, what my PI will say to them, and other developers can to use dynamic behaviors and not use my pi. That's the have optional static typing. And that's the beauty of it. So,
Carlton Gibson 40:03
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, not type check that bit. I can type ignore that.
Nikita Sobolev 40:13
Yeah. It is as easy as writing an old Nokia comments. Yeah, that's it, we're going to ignore the whole file. For example, if you do some crazy stuff in there, so that's fine, too. And you can also type on the exterior. And this is fine as well, you can use some typed exterior and dynamic interior, or vice versa, you can type on the parts you need. And this is something that is way cooler than just having dynamic typing. Because when you're limited to some instruments, you just, 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.
Carlton Gibson 41:06
And you think you think, you know, inlining type annotations in Django? Is a realistic and doable thing at this point?
Nikita Sobolev 41:14
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 Django itself. So my guess is going to stay this way.
Carlton Gibson 41:35
Okay. You think that's okay, so 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 can see all number of places where it would be nice if this was taped. But what's the what's the USP? What's the, you know, why should we do? Why? Like?
Will Vincent 42:03
He just said that, Carlton, right,
Nikita Sobolev 42:05
I can repeat myself.
Carlton Gibson 42:08
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 and that's the that's the question. What do you mean by there's no community need,
Nikita Sobolev 42:19
there is no community need in having these projects. 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 doesn't work in prototype, comments, type ignore, and it will work. So 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 good idea to merge these two projects at some point, but I'm not pushing it at any means.
Carlton Gibson 43:07
Okay, interesting. Thank you. Super. Um, wow, that's two really
Will Vincent 43:12
good. I had two things that are non typing if they're more typing. That's cool. That's, that's why I just wanted to ask about we make services and dry laps, oh, this is your consultancy. And then I guess dry Labs is you teach you educate people. So I put it to you, what do you want to say about both those since that's your day to day, right is?
Nikita Sobolev 43:38
One year ago, I decided to, like quit my own business, because I 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 by developments anymore. So I'm done. Thanks. But I really like to teach. It is something I enjoy and it doesn't 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 at 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 come Stop me and we will figure things out.
Carlton Gibson 45:02
And I have one more topic to ask was about the Django stabs project and whether you'd look for more contributors. So a couple of summers ago, you did the Google Summer of Code for the my PI plug in now, which went really well Casper built that, which I mean, you open to you open to contributors open to doing gas on record, again, type thing if Yeah, application
Nikita Sobolev 45:25
great. I had a lot of pleasant moments during Google Summer of Code. And Casper did a really great job. So his contributions, like the, in the real heart of the project, it's my 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 the world, in the real sense of this word. A lot of people contributes things that they find in types that are typed incorrectly that are missing, that can be done better. I just have to accept their contributions. And that's it.
Will Vincent 46:18
Just like Carlton, right, that's,
Carlton Gibson 46:21
yeah, yeah. But mostly it's. I mean, Nikita, do you have this? See, I sometimes have this thing where I'm just 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 you a PR the time it needs to, to click the button, because I need to think I mean, how do you manage that kind of ongoing? time commitment? I guess, emotional commitment is, I don't know. Fair enough. You just keep going. Yep.
Will Vincent 46:53
Well, what else is anything? I know, we're sort of up on time. Is there anything we haven't asked you that? Are you want to mention while we have a couple 1000? People listening?
Nikita Sobolev 47:01
Follow me on GitHub, and you'll be on top of typing stuff in Python?
Will Vincent 47:07
And can they sponsor you on GitHub? Have you signed up for that? Since you're doing open source?
Nikita Sobolev 47:12
Sorry, I'm, I'm not GitHub sponsors. Now, I'm not on GitHub sponsors, because it is not available in Russia yet. But you can support a sponsor, try Python organization, and you can sports 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 some something they want.
Will Vincent 47:51
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, he's such a huge fan of, of typing and your works. It's very nice to finally meet you.
Nikita Sobolev 48:04
Thanks a lot for having me. It was really a big deal for me to speak on Jenga chat. I Wiesen, from some episodes from time to time, and I really enjoyed it.
Carlton Gibson 48:17
So no, thanks for coming out. It's really nice. I wanted to get you on because I wanted you to make the case. And, you know, we see how the, you know how it evolves over time.
Nikita Sobolev 48:27
And of course, thanks a lot for both of you, too, for your Junga contributions. And that's, 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. Oh,
Carlton Gibson 48:45
super well.
Will Vincent 48:46
Anyways, Carlton, can you read us out pretty well. Okay.
Carlton Gibson 48:48
Thank you again, Nikita. With Thank you for listening with chat Django and Django chat or Django chat and chatting on Twitter. That's it. Join us next time. Bye bye